On Sat, Dec 11, 2010 at 4:10 PM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
sense to list individual /128s. The protocol must support such varying
granularity, also within a single zone.
Quite right, but of course it must also cache well.
Could you show the sequence of queries for an address that is in the BL,
and one that's not in the BL, and a rough estimate of the cache behavior,
like I've done for the _granularity hack?
Starting at 0/0, walk down the _granularity sub-zone. At each step,
you'll get one of three responses (note that I'm not firm on IPv6
bitmask calculation, please correct where necessary):
* "Next Granularity is /X": Query the next granularity level at /X.
* "Everything below is granularity /X": Everything below this point is
granularity /X.
* NXDOMAIN in _granularity sub-zone would indicate that no data is
available in the "data sub-zone".
"Walking down": Query format is (masklen).(reverse
nibble-format)._granularity.(zone), starting at
0.0._granularity.dnsxl.example. If the response at 0/0 is "next
granularity is /64", the application will query
64.8.7.6.5.4.3.2.1._granularity.dnsxl.example. If the response at 0/0
is "everything below is granularity /64", the application will not
query the _granularity sub-zone any further, but directly
8.7.6.5.4.3.2.1.dnsxl.example (no masklen as the left-most nibble, ie
no change on the data zone required).
In many real-world scenarios granularities can be expected to be
somewhere around /48, /56, /64 and /128; it is safe to assume that two
to three lookups in the _granularity sub-zone would be required until
a "everything below is granularity /X"-response is reached, eg "0/0 >
/48 > /64 > /128". One step could be omitted by specifying a
meaningful minimum granularity (/32? /48?).
Two examples:
A list may chose to globally specify "everything below 0/0 is
granularity /64", which would be one additional lookup.
Another list may chose to specify at 0/0 that "next granularity is
/64"; this would result in one additional lookup at the /64
granularity, which may result in either an NXDOMAIN or a "next
granularity is /128"-response. This answer would be cached for the
whole /64, ie subsequent IPs from the same net would be answered from
cache.
I believe that the _granularity sub-zones would need to be present for
every DNSxL sub-zone, ie _granularity.foo.dnsxl.example,
_granularity.bar.dnsxl.example.
How to encode the "everything below is granularity /X" and "next
granularity is /X"? A records with values defined/to be reserved for
that purpose? TXT records?
The "granularity tree" can be created automatically from the zone data
(it is actually a kind of index into the zone data).
What happens if a resolver enumerates all /128 in a whole /64? There
is nothing an intermediary resolver / cache or an authoritative server
can do than to rate-limit a "dumb" resolver. The above draft (or a
useful / corrected variation thereof) will allow an "intelligent"
resolver to limit the number of requests without globally limiting
lookups to an arbitrary limit.
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg