ietf-asrg
[Top] [All Lists]

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