Re: [Asrg] draft-irtf-asrg-bcp-blacklists-00
2004-05-04 21:43:29
At 1:14 PM -0400 5/4/04, Chris Lewis wrote:
Matt Sergeant wrote:
On 4 May 2004, at 14:25, Bill Cole wrote:
Do you consider technical best practices relevant to this BCP or not?
I'd like input from Chris on this question as I had not really
considered technical best practices.
Technical best practises are best suited for John Levine's DNSBL
RFC. Most of the things you'd want to be there should be elevated to
RFC "MUST"s or "SHOULD"s, because that is what DNSBL "client"
implementations need to program to.
I've always considered our BCP to be a "policy" BCP, not a technical
one. An operational guide.
That being said, John Levine and I debated whether "DNSBL shutdown"
should be documented in his RFC or our BCP. I _personally_ would
have preferred it being in the RFC. However, the "implementations"
of high-volume DNSBL shutdown we've seen heretofore have all been,
um, "suboptimal" ;-) [+], and I as yet haven't seen a "reasonable"
one yet (at least one that I understood. I know someone who has
commented at length on "how to do this right", perhaps I can get a
detailed explanation.
Well, I'm pretty sure that you've seen me and at least one other
(probably more respected) DNS geek say approximately the same thing
that I posted this morning, on the same day back when RFG was
complaining about people continuing to query his dead lists. Others
posted very similar (i.e. effectively identical) suggestions in
response to RFG directly then. I'd very much appreciate some clue as
to why it is suboptimal or unclear.
Just to repeat for clarity, in excruciating detail:
If a DNSBL had, when operating, entries of the form
1.0.0.127.dnsbl.example.com and the operator wishes to shut down the
DNSBL, retaining the functionality of example.com as a working domain
and minimizing queries from people who have not gotten the message
yet about the shutdown, one of three sets of records should be added
to the example.com zone (assuming BIND-like syntax and an $ORIGIN of
example.com):
Set 1:
dnsbl 604800 IN NS .
Set 2:
dnsbl 604800 IN NS deadend
deadend 604800 IN A .
Set 3:
dnsbl 604800 IN NS deadend
deadend 604800 IN A 127.255.255.255
The three options break down pretty easily. #1 is simplest but I'm
not sure that it is technically proper. #2 is probably technically
proper, but the '.' RHS may be confusing for some people (or even
resolvers) who see it. #3 seems to me the wisest choice, because it
does not depend on a resolver understanding the '.' RHS and is likely
to look clearly abnormal to any human likely to examine query
results. Steve Atkins seems to like the '.' but it seems too cute to
me.
The effect of all of these, assuming sane resolver function, is that
any resolver trying to query any of the now-dead DNSBL's records will
be directed to ask the question of a nameserver that cannot exist.
The long TTL (a week, which is the default maximum in BIND 9 and so
is about as long as is useful) means that resolvers will query the
nameserver for example.com, be told to ask the bogus nameserver for
any DNSBL records, and cache that referral for a week.
I personally prefer option #3 because it adds a bit of a twist that I
think is useful. Most common (many? all?) IP implementations will not
by default understand that an address in 127/8 other than the
standard loopback of 127.0.0.1 is bogus, and so will query that
address as if it were a normal IP address of a real nameserver. That
means that queries against the DNSBL will each take the amount of
time it takes the requester's resolver to time out on a query. This
means that the people who continue to use the DNSBL after its demise
will likely notice a problem, and on investigation will be able to
discern that the list is dead, yet they will not be subject to the
severe problems that come from the sadly customary practice of
listing the whole world to get the attention of users who have not
yet given up.
I talked to Yakov and John about this and they both suggested we
leave this undefined in this draft rather than expend time trying to
invent a wholly new procedure.
It has to be done at some point, unless these drafts are intended to
end their lives as drafts.
[+] In some cases I can't say that I blame them... But it would be
nice to have a suggested method so that BL operators don't find
themselves in a bind later. As one possible example: _don't_ use a
BL domain name you wouldn't mind deregistering later.
I don't think that's necessary, and it's really rude to the
registry-level nameservers.
I think the rule along those lines should be that a DNSBL should be
logically severable in all ways at a domain element boundary (aka: a
dot) which is also a DNS zone cut (i.e. there are NS records for
the severable domain name) and which is disposable in the event that
the DNSBL is shut down. In short: a DNSBL should be within a DNS
equivalent of an airplane 'comfort bag.' It should not be used to
carry anything else that you might ever want to keep.
I wrote the MUST's and SHOULD's a bit back in the thread.
--
Bill Cole
bill(_at_)scconsult(_dot_)com
_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg
|
|