* 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).
If you're running a DNSBL or DNSWL, you have to be prepared for all of
the mail servers in the world to query your DNS servers. I don't
think it's a good idea to design something on the assumption that
spammers will be cooperative.
Caches may have optimized methods to efficiently store A responses.
I have never seen one that does. It's true, TXT records are bigger
than A records, but each TXT record in my design stores the info that
would otherwise have needed dozens to quintillions (if they're CIDR
ranges) of A records.
* No attempt to be compatible with existing DNSBLs.
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.)
The DNS has the large practical advantage of existing, of being known
to work, and having firewalls and stuff already configured to allow it
through. To the best of my knowledge, hypothetical alternatives are,
well, hypothetical.
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.
I assume that if we do this, we'll have to provide client libraries.
This is less complex than DKIM, so I don't see that as unreasonable.
The search process is pretty simple.
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")?
You're right, it's just listed or not, with the X bit giving you two
flavors of listing. If it were important to have a type for each
listing, it would be easy enough to add a byte or two of type to each
record.
* 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.
I've been giving this further thought and I think I have some reasonable
update strategies. Basically, do what B-Trees do to update, and install
temporary CNAMES when the node names change to limit client breakage.
R's,
John
_______________________________________________
Asrg mailing list
Asrg(_at_)irtf(_dot_)org
http://www.irtf.org/mailman/listinfo/asrg