On Sun, Nov 28, 2010 at 4:59 PM, Seth <sethb(_at_)panix(_dot_)com> wrote:
My way, it never asks for granularity. When it asks for X, it gets a
return code that says "the surrounding /Y is listed" (Y in binary).
It can then cache one entry for the /Y, just as if granularity were
previously given as /Y; this requires no extra lookups, and allows
granularity to be specified by the DNSBL on a per-entry basis.
IMO, this is a requirement: specify granularity on a per-entry basis.
On first glance, this could be done through something like
_64.4.4.4.4.3.3.3.3.2.2.2.2.1.1.1.dnsbl.example
The first token is interpreted as the IPv6 netmask if preceded by "_",
with "_128" implicit if omitted; if four "data tokens" are present, an
IPv4 address is assumed, with an implicit "_32" IPv4 mask of omitted.
Alternatively, require a 2002::/16 IPv6 address for IPv4 range lookups.
A DNSxL would still be free to return a "the surrounding /Y is listed" response.
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg