You are missing something. It is an attempt at fixing the limitation
of having a single granularity for a whole zone, which is not
sufficient.
I'm sorry if this sounds rude, but both of you pretty clearly aren't
getting the DNS cache problem.
Every query from an end system goes to a local DNS cache. If the
cache already has the answer for that exact query, the cache returns
it, otherwise it goes to the authoritative server. When the
authoritative answer comes back, it's saved in the cache, usually
kicking out some other older entry. If the answer is NXDOMAIN or
NODATA, that negative answer is also cached, and takes up a cache
entry.
To make DNSBLs work reasonably with caches, the end systems have to
repeat the identical queries. That's the point of my _granularity
hack: the end system first asks for _granularity, then for the address
truncated to the granularity. The queries for all addresses in a
grain will be identical, so the cache will be able to answer all of
them after the first query for any address in that grain.
Your schemes send a series of different queries for each address. All
of those queries will hit the cache, and will displace other cache
entries. Since most MTAs share the same cache for DNSBL queries and
everything else, the effect is that the cache will fill up with
useless DNSBL entries, forcing the cache to go back to the
authoritative servers for everything. This would be a big problem;
DNS caches normally handle the vast majority of queries themselves and
the extra traffic would be a killer.
RFC 2308 describes negative caching and has some helpful examples of
the way that DNS caches work.
DNSSEC adds the new possibility for caches to be smarter, and to know
that a single cache entry can cover a range of queries. This is what
you need to do DNSBL CIDR ranges, so any other CIDR hack has to have
no worse cache behavior than DNSSEC to be plausible.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg