RRL probably not useful for DNS IP blacklists,

[Vernon Schryver]

> From: Noel Butler <noel.butler at ausics.net>

> you clearly have a bias set-in-concrete mindset about rbldnsd, maybe you
> and its author hate each others guts, I dunno, dont care,  our decision
> is based on real world live usages, tests, and experiences, for over ten
> years of using rbldnsd and twenty with bind, so Vernon I suggest the
> only person here who is "hand wringing" as you put it, is yourself,
> whatever your problem is, get over it.

To see who else has been wringing their hands for years about IPv6
spam, consider the obvious https://www.google.com/search?q=dnsbl+ipv6+spam
Notice the reference to "a B-tree data structure" in
http://www.spamhaus.org/organization/statement/012/spamhaus-ipv6-blocklists-strategy-statement

The problem is since essentially very IPv6 host has at least 281474976710656
and often 18446744073709551616 IPv6 addresses available, a spammer can
use a unique IPv6 address with every mail message.  No DNSBL can contain
2^64 IPv6 /128 address to cover a single PC in a botnet, not to mention
the 2^72 or 2^80 IPv6 addresses of a lawful spammer with its own IPv6
allocation.

The obvious solution is to put wildcards into your IPv6 DNSBL, which
works fine for the authorities for your IPv6 DNSBL.
But what happens at most SMTP servers (mail receivers) that use local,
recursive DNS resolvers that cache DNSBL data from authorities?  Every
spam SMTP transaction will involve a unique SMTP client IPv6 address
that the recursive DNS resolver will fetch from the DNSBL authority
and cache locally.  That is fine for the first few thousand or maybe
million SMTP transactions.  If you run a small mail+DNS system that
sees only 100K mail transactions per day, you can stop reading.

If you run a system that handles millions or billions of SMTP transactions
per day, and you recall that even NXDOMAIN no-entry DNSBL results
must be cached, you'll probably do one of:
  1. give up on DNSBLs.
  2. make all of your recursive DNS servers for your SMTP servers
     authoritative for your chosen DNSBLs.
  3. try to change the DNS protocol to include something like
      wildcards on the wire instead of only as abbreviations in
      zone files, such as John Levine's B-tree proposal.

You can't do #2 with simple rbldnsd configurations, because your
SMTP servers require full featured recursive DNS servers that support
wildcards, MX RRs, DNSSEC, etc.  You might use forwarding for
the DNSBL zones, but it's going to be fragile and complicated.

Even if you already didn't know practically impossible it it is to
make even tiny changes to the DNS protocol, the fact the I-D for DNS
B-trees expired 2.5 years ago ought to be a clue that #3 is not a
real alternative.

My solution is #2 but with real DNS servers with local copies of
DNSBLs maintained with IXFR.  There are obvious problems with that,
starting with the tree of authorities for those IXFRs, but I think
it's better than #1 and not as completely and utterly hopeless as #3.


Vernon Schryver    vjs at rhyolite.com