"Response code" as used here does not necessarily have to be carried
in the rcode bits of the DNS packet. For example, a lookup could
return an A record with a TTL of zero and an address of 0.0.x.y; this
allows for 65536 different response codes without touching the DNS
infrastructure at all.
Let's back up for a few milliseconds and consider what the goal is
here. A hostile or inept mail sender can hop to a new IP within their
subnet on every message, which would provoke vast numbers of different
DNSBL lookups that would fill up DNS caches with useless entries,
forcing out the useful ones. My goal is to improve the cache behavior
for clients that know how to check the granularity, preferably without
making things worse for clients that don't.
If you start encoding response codes in the A records, you'll break
lookups for older clients, and I don't see any advantage compared to
my hack.
The lookup for the _granularity record will be cached well on systems
like mine that don't keep state between SMTP sessions and have to
check it on each session. It's followed by the lookup for the
truncated reversed IP, which will also cache well, whether or not
there's a record, since it's the same lookup for all addreses within a
grain, and modern caches remember NXDOMAIN responses, too.
It would be nice to have variable granularity, i.e. CIDR ranges, but I
don't see any cache-able way to do that simpler than what DNSSEC does.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg