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

At 11:40 AM +0100 5/4/04, Matt Sergeant wrote:

[...]
> >   2.10. Shutdowns MUST Be Done in a Graceful Fashion.
> > I suggest a specific result code be codified to represent [urgent 
> > action needed by admin, e.g. this list has shut down, etc.]
> We tried to avoid codifying a specific shutdown procedure. We would 
> hope to see that appear in an RFC, rather than in a BCP. If that 
> happens we could reference said RFC.
Do you mean a descendant of 
http://www.ietf.org/internet-drafts/draft-irtf-asrg-dnsbl-00.txt or 
some additional RFC?
Outlines for orderly shutdown of DNSBL's have been composed and 
posted publicly in 3 waves over the past 3 years (unfortunately in 
the first 2 cases, AFTER operators have listed the entire net to 
drive away users) and it is not a complicated matter or really a very 
controversial issue, it's just quite specific. It boils down to a 
method for shutting down any zone: add a long-TTL NS record for the 
zone into the parent zone with a RHS of either "." or a name in the 
parent zone with a long-TTL A record with a RHS of either '.' or to 
an address in 127/8 other than 127.0.0.1.
The only reason that orderly shutdown has ever been an issue is that 
the most noisily terminated DNSBL's have been run by people who sadly 
have been clueless about DNS. There's no need for a complex dance of 
special entries in-zone alerting users to the death of a DNSBL, 
giving way to eventually just going dead or listing the entire net.
> >   3. Special Rules for Blacklists Listing Insecure Machines.
> > See the SPEWS FAQ for why this is a bad idea.
> >   3.1. No Automated Probes [Scanning or Probes? - inconsistent]. 
> > Scanning in response to an attempt to email a system for the first 
> > time seems reasonable to me.
> And yet there is a lot of disagreement about this (see multiple 
> discussions about RR doing this).
There are huge disagreements over when security probes without 
explicit permission might be acceptable. It is surprising to me that 
there is not already an RFC of some sort covering that, as it is an 
issue that extends far beyond the issue of spam.
> > In general, it seems like the authors don't have much respect for 
> > the tireless *volunteer* BL maintainers and need to spend more time 
> > thinking about things from the POV of the BL maintainers.
> On the contrary, the authors have thought about this a great deal, 
> and have discussed the issues here with blocklist maintainers to try 
> and reach a reasonable level for the BCP that is both achievable, 
> and also a high enough bar that the BCP is actually useful. If we 
> set the rules so flexible that anything is possible then there would 
> be little point in publishing it.
Do you consider technical best practices relevant to this BCP or not?

I ask because it seems that the draft is focused on policy best 
practices, and while that is useful it is not the low-hanging fruit. 
A few tips for those well-meaning but not always technically adept 
volunteers would be good, and facilitate things like orderly 
shutdown. For example:
MUST have NS records for the base zone and any sub-zone that 
represents a discrete list (this facilitates scalability and hence 
attack resistance of a list, as well as making orderly shutdown more 
orderly)
MUST NOT make the availability of documentation of the list dependant 
on continued operation of DNS for the list's zone. (This keeps the 
documentation of a list out of the line of fire of attacks and allows 
for the continued existence of something like a web page saying "It's 
dead!" even after an orderly shutdown)
SHOULD NOT have any records in the DNSBL zone other than DNSBL 
entries (again, this assists in orderly shutdown, because it makes 
the zone used fo0r the list disposable)
MAY list loopback, RFC1918, LINK-LOCAL, class D/E, and any other 
permanently reserved or special-use IPv4 addresses and MUST publicly 
document  any such listings. (It is a rare month when no one 
expresses shock in public that some address with purely local meaning 
is in some DNSBL. It has been suggested that some reserved address be 
used as a test for whether a list is alive. )

Those may be slightly debatable on strength, but it seems to me that 
if there is going to be a formal codification and documentation of 
DNSBL practice, it would be a good thing to at least alert people 
referring to the documents to some of the technical pitfalls hit by 
prior operators and how to avoid them.


--
Bill Cole                                  
bill(_at_)scconsult(_dot_)com

_______________________________________________
Asrg mailing list
Asrg(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/asrg