Here's a rough draft of a new, improved idea I have to do DNSBLs and DNSWLs
for IPv6. (It should work for v4, too, if anyone cares.)
A couple of quick questions while reading through the proposal (may be
out of order, since I went through it in non-linear mode):
* Doesn't assume senders will be well behaved. In particular, bad guys
may use a new IP for every message, hopping around within each /64 (or
whatever) in which a zombie lives, and there will be many zombies active
at the same time.
This may be less severe in practice, since a mailserver will have some
rate limiting (limited by bandwidth, CPU, I/O etc).
* Must work well with existing DNS servers and caches. The number of
different queries should be limited, both to limit cache-server
traffic and the number of cache entries it uses. I assume that
client-cache queries are cheap, cache-server queries are much more
expensive.
Caches may have optimized methods to efficiently store A responses.
Moving to a TXT based protocol (and requiring them to be cached) may
render such optimisations moot. Is this a relevant thought? (I only
implemented auth DNS servers in the past, never a cache/resolver...)
* No attempt to be compatible with existing DNSBLs. I expect it will
mostly be served from something like rbldnsd, although it would also
be possible to have an external program create the zone files and
serve them from something like BIND.
If the protocol is to be changed in incompatible ways anyway, does it
still need to be DNS? (Although I'm not sure what viable alternatives
would be.)
1. Make the root blob the current blob and fetch it.
2. Look inside the current blob for a CIDR entry that contains your
target IP address. If you find it, stop, the BL contains the IP.
3. If your IP is lower than the first entry in the current blob, or
higher than the last entry, stop, the BL does not contain the IP.
4. If this is a leaf blob, stop, the BL does not contain the IP.
5. Find the entry in the current blob that is just below your IP. Use
the address in that entry as the name of new blob, fetch that blob,
and make it the current one.
6. Go to step 2.
The "beauty" of current DNSxL is the ease of implementation for the
application consuming the data (filters etc). Some pseudo-code for a
client implementation would make it easier to adopt.
X S S S S S S S
Address
X is reserved for now, perhaps allowing multiple kinds of entries.
As far as I see, responses can only be "listed/not listed"? Or could
the X above be used for more granular responses ("listed for reason
X", "trust level X")?
* Update management. I think that you set the TTL to something
reasonable, 15 minutes or an hour or whatever, and whenever you
change the data, you leave the old entries around for one or two
TTLs, perhaps changing their TTLs to something smaller to discourage
caches from keeping stale data.
This may be very different depending on the update frequency. Current
blacklists have TTLs in minutes (seconds?), a whitelist may have TTLs
in multiple hours (or even days, although this has other drawbacks)
for their data.
* Compatibility stuff, e.g., fake A and TXT record values to pass back
to clients that expect them, probably stored in _arecord and
_txtrecord, perhaps with a $ in the _txtrecord that expands to the
current IP.
Best practice should be to keep old and new protocols in different
(sub-) zones.
-- Matthias
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg