> From: Noel Butler <noel.but...@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 v...@rhyolite.com _______________________________________________ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
