[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Asrg] draft-irtf-asrg-bcp-blacklists-00

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@scconsult.com





_______________________________________________

Asrg mailing list

Asrg@ietf.org

https://www1.ietf.org/mailman/listinfo/asrg