On Sat, Nov 27, 2010 at 10:47 PM, John R. Levine <johnl(_at_)iecc(_dot_)com>
wrote:
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?
how about response codes to queries at the wrong grain size that
trigger client retries with fewer (or more) bits to get meaningful
responses? The client would cache the appropriate grain sizes for
whatever range it was querying in, and even Just Guessing it will take
on average fewer than two tries, instead of always two tries as with a
new kind of record. The EGRANULARITY message would include the correct
grain size in seven (of the 32 available) bits assigned to that
purpose. Or just three bits if we're splitting at octets.
An entirely new convention using both address and length, encoded in
something other than decimal octet expansion might be good too,
although it wouldn't delegate as gracefully as the multi-level current
practice does, if RBL operators actually delegate ranges to different
servers (I doubt they do. Hey, RBL operators, do you?)
This method -- meaningful answer only in response to question at
correct granularity, granularity correction message otherwise -- would
also work for ipv4 ranges, such as the dynamically allocated public
ranges that can be queried for with the RBLs that specialize in that.
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg