On 1/18/2011 7:51 PM, John Leslie wrote:
Chris Lewis<clewis(_at_)nortel(_dot_)com> wrote:
I'm, however, hesitant in doing so. My reasoning is as follows:
a) If IPv6 DNSBLs are impractical as some suggest, no useful ones will
exist, the issue is moot, and no disclaimers are necessary.
Not a helpful argument. It supposes this document being read much
later than it's being issued (which could be true, but isn't our main
intent).
I don't see how _when_ the document is being read is relevant. If they
read it in the future when IPv6's are known to be impractical, they'll
know it's moot. If they read it now, and IPv6 DNSBLs turn out to be
impractical, they'll run into the reality wall that proves it's moot.
We don't _know_ IPv6 DNSBLs are impossible. And frankly I don't think
they are, unless you presuppose that listing /128s are the only way.
Listing only /32s isn't true in IPv4 land, there is no reason to believe
that that would change in IPv6. In fact, the contrary it will almost
certainly become necessary for any DNSBL to be "profitable".
Let me cut to the chase here:
I can see a relatively easy way to maintain the usefulness of even
(present) /32-listing style DNSBLs in an IPv6 world (eg: either fixed or
adjustable granularity to match or roughly match real/likely end-user
allocation sizes) with only complexity being to deal with the cache
blow-up problem. And I don't see any of that which would force IPv6
DNSBLs implemented that way violating any of the MUSTs or SHOULDs. Some
of that may obviously be impacted by IPv6 DNSBL standardization efforts,
or I may be wrong about some of the MUSTage/SHOULDage, but there's
nothing to stop the issuance of a new BCP around IPv6 specifically that
deals with that.
Better to have general guidance in place that will probably work for the
most part and might need a bit of later tweakage, than to throw up our
hands and provide no guidance at all.
b) If IPv6 DNSBLs are practical, then most of the policies are entirely
IPvX neutral (and are in fact extensible to non-DNSBLs at that), and a
disclaimer of that type would unnecessarily deprecate the useful
policies that _should_ still apply to IPv6.
This is false.
You're going to have to explain a bit more than that.
c) If IPv6 DNSBLs are practical, but some of the policies don't make
technical sense, again the issue is moot, and no disclaimers are
necessary. Eg: rescan intervals: there's nothing that implies that
rescans are necessary. Hence, comments about rescanning of IPv6 entries
being impractical or impossible doesn't invalidate a "minimum rescan
interval" policy. If you can't rescan, then, the minimum rescan
interval policy is moot - by not rescanning at all, you still meet the BCP.
We don't even know what "rescan" will mean in an IPv6 world -- it's
just too darn premature. I asked for a statement that IPv6 DNSBLs are
"a work in progress" and that this document "cannot make recommendations
specific to IPv6" -- both inarguably true.
There aren't any recommendations specific to IPv6, all of the examples
are specific to IPv4, so is the statement even necessary? I don't
object to the statement _except_ for the reason given in (b) above where
you didn't elaborate beyond "this is false".
[Can I say that I don't like discussion by bare assertion? ;-)]
"rescan" is used within the document in a very specific context - that
of probing systems for security faults. It could only be used in the
same context in IPv6. If /128 hopping is truly going to be as
ubiquitous as people may think, the form of probing inferred by the
context will be impossibly expensive. Hence, specifying a minimum
interval is moot. They'll either know that ahead of time, or find out
quickly enough. In terms you use later - "it'll be unprofitable".
And we see plenty of evidence _within_ this RG that folks are thinking
s/4/6/ is an adequate heuristic -- which is inarguably false.
And DNSBLs constructed in that basis would, even I would assume, just
about useless and probably wouldn't live long enough for the BCP to matter.
We don't have to make policy for the unworkable.
(But it is very suggestive that
there is essentially nothing keeping a compromised IPv6 host from using
a different /128 for every connection it makes...)
Not really suggestive. Postulate Doug's scenario. Every compromised
host spits out a spam on a different /128 every time. DNSBLs confounded
by this will be entirely "unprofitable" and they won't exist for long.
Most of the policy is technology/query format neutral - and those that
aren't will either be implementable in some sort of IPv6 analogue (which
is up to a format specification for IPv6 DNSBLs), or not implementable
at all.
There are DNSBLs that do not charge for access and do not charge for
manual actions.
For the most part, they don't _do_ manual actions.
I have significant background in this area. I assure you, except for
the toy ones, even the free ones do manual action, and some fairly
extensively.
[Oddly enough, it's the commercial ventures that seem to do the least.
Many of the commercial ventures make even SORBS look impossibly
responsive. Steve might yell about C&C warnings, but I think he'd have
to admit it's true ;-)]
In fact, there's only one DNSBL that I know of that still imposes
financial costs surrounding delistings. It ain't SORBS...
Michelle _herself_ suggested "MUST NOT".
And I disagree with Michelle -- though that's really not the point.
Chances are, the "offending" DNSBL will abandon that business model
soon, quite regardless of what we write here. The practice is being
abandoned because it's an unprofitable business model.
Actually, that's not why Michelle abandoned it. She was always
uncomfortable with it, and said so, but thought it necessary due to
technical implementation limitations and the avoidance of gaming. When
the implementation changed that calculation changed, and the perceived
necessity went away.
Even so, most disagreed with her necessity calculation including
virtually all of the DNSBL admin community I know (and I know rather a
lot of it).
Thus increasing the FP rate and impairing the accuracy for everyone else.
"Everyone" ???
Yes, everyone. A, say, ISP's broad refusal to deal with a DNSBL's false
positives because of orthogonal perceptions of extortion, blackmail or
protection racket worsens the false positive rate of that DNSBL. This
can only be untrue if you assume that every DNSBL is perfect.
Unfortunately, they aren't.
Not to mention the harm to the reputation of the mechanism as a whole.
(That sounds like a null set to me...)
I think it's provably not a null set ;-)
A strong statement that this isn't acceptable behaviour can do nothing
but good.
I don't mind a strong statement (though I don't expect it to have any
effect) -- I mind MUSTard which makes us look foolish.
H'mm - beginning of parenthetical comment - see below.
Specifically, consider:
"
" Therefore, negative-connotation DNSBLs MUST not charge fees or
" require donations for delisting or "faster handling", and it is
" RECOMMENDED that such DNSBLs that do charge fees or require donations
" not be used.
(Why is there a need to RECOMMEND not using what we declare to be a
null set?)
It's demonstrably not a null set.
You're letting your emotions rule here. There's a perfectly reasonable
business model I call "Vouching Service" where human judgment is needed
to verify that an event or practice which violated the rules has been
sufficiently rectified to again vouch for the offending whatever.
This sort of service _really_should_not_ be prohibited.
You're right, it shouldn't. And it isn't.
But to say
there may be no charge involved comes arbitrarily close to prohibiting
it. :^(
I disagree with that through existence proofs ;-)
A strong "SHOULD NOT charge" is appropriate.
We could probably even get away with a "MUST NOT use" such DNSBLs
in that paragraph, although personally I'd prefer "SHOULD NOT charge"
and "SHOULD NOT use".
The goal of the BCP is to strongly encourage the best practises on the
DNSBL admin side, but at the same time recognize that receivers can do
anything they feel like as long as they know what they're doing.
"MUST" in 2119-speak isn't "strongly encourage". Surely you can find
words (such as "strongly" and "encourage") to say what you mean.
Parenthetical comment (from "H'mmm"):
Lemme think a bit more/experiment on using non-RFC 2119 language for
this and I'll get back to y'all.
If we say "MUST NOT charge", we should be talking about future
practices, not past ones.
Right.
I feel pretty strongly about Vouching Services being a useful tool.
Me too, but that doesn't necessitate charging for repair of involuntary
inclusion in negative connotation DNSBLs.
We have to very much keep in mind some of the wording from the BCP
surrounding negative connotation DNSBLs and the fundamental difference
between DNSBL and more traditional potentially negative vouching
services we know of. Namely, the human factor.
When a restaurant reviewer says someone's restaurant sucks, the
restaurant goer has to make a conscious choice to accept/reject that
advice for that restaurant.
In contrast, a DNSBL can literally make the site disappear for all of
their users, and the user wouldn't necessarily know it then or ever. If
the DNSBL does "repair" of that unasked for negative vouch for profit,
it becomes more an extra-judicial fine with little if any oversight.
Imagine if you will restaurant reviewers charging restaurants for a
re-review of bad vouches. Just how well do you think that would be
received by _anyone_? Even more so with DNSBLs.
In Section 3.4, the "MUST NOT list the entire Internet" is a bit
strong as well. While I think you have given plenty of suggested
alternatives to this, folks _do_ paint themselves into corners where
such a doomsday-weapon becomes needed. (Listing the entire Internet
_does_ mean they're outside the specification we're writing; but it
comes across as an attempt to control a behavior we can't control.
Perhaps we could suggest alternatives, not use the MUSTard, and say
that listing the entire Internet puts a DNSBL list out of conformance
with this set of practices.)
Isn't that exactly what the section means?
To whom ??
Seriously, it bothers me how often a reviewer notes a point of
confusion, and the response amounts to "What kind of fool could ever
be confused by that?" and not a single word of the document changes.
I assure you it wasn't intended that way. The problem is that I don't
see suggestions that aren't already implemented.
Without a "MUST NOT", how can we say that doing so puts someone out of
compliance?
Alternatives are given, etc.
Is it intra-document pointers I'm missing? Is it just unclear? What?
Another set of eyeballs looking at a document is a Good Thing (TM).
Absolutely.
A good Document Editor welcomes the opportunity to reduce confusion,
even at the expense of adding words to a document.
I'm just a bit confused as to which words.
Besides, heretofore, any DNSBL utilizing such a doomsday weapon was
heralding their own doom - compliance becomes moot.
Quite true -- so why do we need any MUSTard here?
Unlike most other "standardization" (or whatever) efforts, DNSBLs are
sometimes a highly charged emotional/political issue. As such, it is of
significant value to reduce the FUDage:
- Demonstrating to DNSBL users and others that such behaviour is out of
bounds.
- Demonstrating that a bit of fore-thought in DNSBL setup from the
beginning obviates the possibility of being painted into a corner where
such may become necessary.
[The howzzat is below]
We have to really really _really_ discourage the practise so that
receivers will know that listing-world is something they should not
need to worry about.
Is "Pollyanna" your middle name?
I'm Canadian. Does that answer your question? ;-)
and some of the provisioning recommendations are about making sure
that list-the-world scenarios are not necessary.
Howzzat?
Virtually all list-the-world scenarios come about because of name server
blowout/overload due to DNSBL shutdown and an attempt to keep the base
domain useful for other purposes in future. Listing the world is an
attempt to get everybody still using the DNSBL to stop using it and
thereby shed DNS load.
If the DNSBL is implemented using the recommendations in the BCP, you
can mitigate load/avoid server blowout _without_ listing the world and
_still_ communicate (in a non-destructive manner) a fairly obvious
signal that the users should stop using it.
The other scenario is if the domain simply expires, someone else picks
it up, and promptly gets blown out by NS queries and fumbles along far
enough to learn about DNS wildcarding and letting fly.
This too has happened.
At least domain owners can be pointed to this document as a means by
which they can do the same rather than barging around blowing up random
mail servers.
[I should point out that this section of previous drafts of this
document have already proven valuable in real-world occurrences of
_both_ scenarios.]
Whatever, we should make sure that language about testing for
list-the-entire-Internet SHOULD be done is found within this Section.
It's the next section ... isn't that enough?
A forward-reference would be plenty.
Sorry, should have asked that instead. Okay.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg