On Thu, Dec 9, 2010 at 4:14 AM, John Levine <johnl(_at_)taugh(_dot_)com> wrote:
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.
This is not a nice-to-have, but I consider it a MUST. For a DNSxL
operator, it must be possible to punch holes in larger ranges (IIRC
the Spamhaus PBL requires such holes).
There are multiple ways to achieve this, eg through a "hierarchy of
granularities". Possibly, it can be something like the following
(using IPv4 terms for brevity):
Lookup a.b.c.d/32 in zone dnsxl.example:
1) _granularity.dnsxl.example => 16 (may have long TTL)
2) b.a._granularity.dnsxl.example => 24 (may have long TTL)
3) c.b.a._granularity.dnsxl.example => 32 (may have long TTL)
4) d.c.b.a.dnsxl.example => result (TTL depending on type of data, eg
short for blacklist, long for whitelist)
A default granularity can be specified in the protocol (/32 for IPv4,
possibly /64 for IPv6?), which would remain backwards compatible, but
does only allow "byte-aligned" network mask lookups. An alternative
would be to specify the network mask in the query for the granularity,
eg as the left-most label:
Lookup a.b.c.d/32 in zone dnsxl.example:
1) 0._granularity.dnsxl.example => 16 (may have long TTL)
2) 16.b.a._granularity.dnsxl.example => 22 (may have long TTL)
3) 22.c.b.a._granularity.dnsxl.example => 32 (may have long TTL)
4) d.c.b.a.dnsxl.example => result (TTL depending on type of data, eg
short for blacklist, long for whitelist)
(Noting that a.b.c/22 is not in all cases the correct super-net for a.b.c.d/32)
The DNSxL operator can automatically create a "granularity tree" (of
either type) which will result in the least amount of lookups based on
his own policy and/or actually available data. It could even be fully
automated by an intelligent DNS server.
A typical IPv4-/32-only DNSxL could also specify
0._granularity.dnsxl.example => 32.
Should IPv4 and IPv6 be handled in a unified way (ie, IPv4 translated
into IPv6 net space), or have dedicated namespaces for specifying
granularity ("v4._granularity.dnsxl.example" and "v6....")?
Minimizing the number of lookups is not only in the interest of the
DNS cache operators, but also in the DNSxL operators own interest,
because it will also keep the load on the authoritative nameservers at
an acceptable level (or, along the same lines, the number of lookups
on private mirrors).
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg