[Asrg] Implementing IPv6 DNSBLs

I have been pondering the swamp which is IPv6 DNS blacklists and 
whitelists.
My DNSBL RFC describes v6 DNSBLs as a straightforward analogy to v4 
DNSBLs.  For IPv6, take the address as a 16 digit hex number, reverse the 
digits as is done for ip6.arpa rDNS, and looks that up, e.g., if the 
address is 1111:2222:3333:4444:5555:6666:7777:8888 you look up 
8.8.8.8.7.7.7.7.6.6.6.6.5.5.5.5.4.4.4.4.3.3.3.3.2.2.2.2.1.1.1.dnsbl.example.
While that is OK as far as it goes, I'm worried about performance problems 
due to blowing out DNS caches.  The usual allocation for a single 
broadband customer would be a /64, which includes 2^64 addresses.  That is 
enough that a sender on a single host could easily use a different address 
for every message he ever sent.  That would mean that for each message 
each client would fetch a new set of DNSBL entries, thereby both drowning 
the DNSBL servers, and blowing out the caches which would be filled with 
useless DNSBL lookups that would never be reused.  DNS wildcards don't 
help here, since the cache doesn't know that an answer was expanded from a 
wild card (but see below.)
This same problem affects rDNS lookups, so I'm trying to figure out what 
ISPs are planning to do about them.  In the meantime, here are some DNSBL 
related thoughts.
Paul Vixie is working on a way to distribute lists of naughty domain or IP 
names as DNS zones, using IXFR and NOTIFY.  He claims he's tried it with a 
3 million entry zone at high update rates, and it works OK, but that still 
means that the central server needs to know all the clients to notify.
If a zone is signed with DNSSEC (which I admit would be quite a leap for 
something like rbldnsd), caches can do a lot of the wildcard expansion. 
That is, if the answer to a query was expanded from a wildcard, the DNSSEC 
stuff that comes along with it tells the cache what the wildcard was and 
what the range of names it covers.  That's enough for a cache to handle 
subsequent queries matched by the wildcard itself.  The DNSSEC specs say 
it would be "prudent" for the cache not to do that, but the arguments for 
the alleged prudence seem to me to be pretty weak.
Someone suggested that you could use DNAMEs to cover ranges of names, with 
16 DNAMES (1-F) at each level pointing at a common main entry.  This 
shrinks the 2^64 entries in a /64 to 256 DNAMES, but I haven't done any 
modelling to figure out whether that's really likely to help, e.g., if 
there's less than 256 queries to a given /64 before the TTL on the DNAMEs 
starts to time out, you haven't saved anything.
Finally, I was thinking about ways to make backward compatible changes to 
IPv6 DNSBLs to make them more cache friendly.  It occurs to me that in 
many cases, you know administratively what the granularity of the DNSBL 
is.  For example assume a hypothetical DNSBL lists at /64 or coarser, so 
you know all of the results in a given /64 are the same.  If you could 
publish the granularity for clients to use, they could truncate the query 
name to the granularity, e.g the query for 
1111:2222:3333:4444:5555:6666:7777:8888 would just use the the 
1111:2222:3333:4444 part of the address, so you'd look up 
4.4.4.4.3.3.3.3.2.2.2.2.1.1.1.dnsbl.example.
For backwards compatibility, longer names would still have to work but 
that's not hard to do.  I'd suggest publishing the granularity like this:
_granularity.dnsbl.example IN TXT "64"

That is, it's a TXT record at the reserved name _granularity.  If there's 
no record there, you fall back to full length queries.  If there's a 
record but it contains something other than a two or three digit number, 
you stop because it's not a DNSBL.  I'd require the granularity to be at 
least 20, so there are at least five components in the reversed address, 
to avoid confusion with four-component IPv4 reversed addresses.
My suggestion would be to do the granularity hack, which is basically 
free, and think about encouraging caches to do DNSSEC based wildcard 
expansion.  What do you think?
Regards,
John Levine, johnl(_at_)iecc(_dot_)com, Primary Perpetrator of "The Internet for 
Dummies",
Please consider the environment before reading this e-mail. http://jl.ly
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg