Internet and e-mail policy and practice
including Notes on Internet E-mail


2012
Months
Mar

Click the comments link on any story to see comments or add your own.


Subscribe to this blog


RSS feed


Home :: Email


31 Mar 2012

IPv6 DNS blacklists reconsidered Email

I opined about a year ago that DNS blacklists wouldn't work for mail that runs over IPv6 rather than IPv4. The reason is that IPv6 has such a huge range of addresses that spammers can easily send every message from a unique IP address, which means that recipient systems will fire off a unique set of DNSBL queries for every message, which will swamp DNS caches, since they won't be able to reuse cached results from previous queries like they can for IPv4 mail.

Now I'm much less sure this will be a problem, because it's not clear that DNSBL results benefit from caches now.

Large and small mail systems access DNSBLs differently. Large systems make arrangements with the DNSBL operators to download their own copies of the DNSBLs they use via rsync or something similar. Then they glom all of the DNSBLs together and typically run copies of rbldnsd on the same local networks as the mail servers so for each incoming message, the mail server can send a local query to rbldnsd and get back one response with all of the DNSBL information relevant to the message. For these systems, a DNS cache provides no benefit because getting the answer from rbldnsd is just as fast if not faster than getting it from a cache. I don't know whether they currently configure their systems not to use caches, but if they don't, it would be technically straightforward. In a world with IPv6 DNSBLs, this would all work exactly the same way, download the DNSBL with rsync and serve it locally with rbldnsd.

Small systems send ordinary DNS queries to the main servers for each DNSBL they use, typically via a local DNS cache. As far as I can tell, caches don't help these systems either, because there isn't enough repeat traffic from the same IP to reuse cached results. It is surprisingly hard to find trace data to test out this theory, but it seems to be true of traffic on my small (100K connections/day) system, and on the few others I've been able to ask. (If you are willing to provide mail server connection traces of timestamps and IP addresses, so I can do more testing, please let me know. Or I can provide test scripts you can run on your own data and see how well your DNSBL queries cache.)

This suggests that DNSBL clients, which are usually mail servers, will be able to use DNSBLs largely the same way they do now, perhaps with modest cache partitioning tweaks to tell the caches not to bother caching DNSBL query results. But that doesn't mean that there's no problems with IPv6 DNSBLs. In the next message, I'll look at problems facing DNSBL operators.


posted at: 16:01 :: permanent link to this entry :: 2 comments
posted at: 16:01 :: permanent link to this entry :: 2 comments

comments...        (Jump to the end to add your own comment)


If the DNSBL for IPv6 limits itself to /64 networks, and usually the query uses the IP in reverse order. Instead of doing the query for the full /128, the email server could query using the first 64 relevant bits. This would improve caching against spammers changing the IP.

(by Franck Martin 01 Apr 2012 00:11)


Re: Franck
You'd still have well over two quintillion possible /64s to check and to potentially store in your blacklist. That's a lot and I wonder if it works in practise.

Moreover, storing /64s is far from ideal. Think of a small company, which owns a /64 and uses one IP for its mail server. That machine only sends legitimate email, but then another machine gets compromised and starts sending lots of spam. Block the /64 or not? (Assume the second machine is the web server, which does need to send the odd email, so that "block TCP25 outbound" isn't possible.)

(by Martijn 02 Apr 2012 03:07)


Add your comment...

Note: all comments require an email address to send a confirmation to verify that it was posted by a person and not a spambot. The comment won't be visible until you click the link in the confirmation. Unless you check the box below, which almost nobody does, your email won't be displayed, and I won't use it for other purposes.

 
Name:
Email: you@wherever (required, for confirmation)
Title: (optional)
Comments:
Show my Email address
Save my Name and Email for next time

Topics


My other sites

Who is this guy?

Airline ticket info

Taughannock Networks

Other blogs

CAUCE
Remembering JD Falk - 10 years later
385 days ago

A keen grasp of the obvious
Italian Apple Cake
85 days ago

Related sites

Coalition Against Unsolicited Commercial E-mail

Network Abuse Clearinghouse



© 2005-2020 John R. Levine.
CAN SPAM address harvesting notice: the operator of this website will not give, sell, or otherwise transfer addresses maintained by this website to any other party for the purposes of initiating, or enabling others to initiate, electronic mail messages.