Home / Blogs

Running DNSBLs in an IPv6 World

John Levine

DNS blacklists for IPv4 addresses are now nearly 15 years old, and DNSBL operators have gathered a great deal of expertise running them. Over the next decade or two mail will probably move to IPv6. How will running IPv6 DNSBLs differ from IPv4? There aren't any significant IPv6 DNSBLs yet since there isn't significant unwanted IPv6 mail traffic yet (or significant wanted traffic, for that matter), but we can make some extrapolations from the IPv4 experience. Existing IPv4 DNSBLs tend to fall into three categories, exemplified by the Spamhaus SBL, PBL, and XBL.

The PBL (Policy Block List) includes ranges of addresses that shouldn't be sending mail directly, either because they're retail customers who are supposed to use their providers' mail servers, or they're assigned to equipment that should send no mail at all. Each entry is a range of addresses. List maintenance is manual; network managers can and often do add ranges of their own addresses, and Spamhaus adds ranges that they've determined are appropriate. In some cases, it's possible to de-list an individual address to poke a hole in a PBL range and allow mail out.

The SBL is managed manually, and lists ranges of IP addresses that based on historical evidence are likely to send predominantly or entirely spam. Some SBL entries are single IP addresses, while others list entire networks that are controlled by criminals.

The XBL lists individual IP addresses of hosts that have been observed sending 'bot spam or other mechanical indications that they are likely to send spam but no legitimate mail. Listings are added automatically, and are removed automatically some time after the IP stops sending spam. It's usually possible to remove an entry manually, although not an unlimited number of times.

How do these map into a world of IPv6 mail?

All three kinds of lists still make sense, but it's much less clear how large a range of addresses each entry should be. In general, the high 64 bits of a 128 IPv6 address are the network number, and the low 64 bits are the host number within that network, but network operators have a great deal of latitude how they assign addresses. A cable ISP would probably assign a /64 to each user, but they might assign a /56 to a business customer that has more than a single LAN in its office. On the other hand, a hosting company might assign a /64 to a data center, to a rack in a data center, to a single server, or maybe to a blade on the server.

The SBL style lists are relatively straightforward, the range to list is chosen manually in IPv4, and it'll be chosen manually in IPv6. But granularity matters for the other two styles.

When a piece of spam triggers an entry in a botnet list, just listing the individual IP isn't likely to be very effective, since in the bot can use a different address on the same network for each message. (On IPv4 networks, hosts generally get an address via DHCP from the router, on IPv6 they just get the nework part from the router, and make up their own low bits, so they don't have to ask anyone to make up new low bits.) This means that in the common case that a bot is on a home or small office network, a botnet list would want to list the network, which might be a /64, or if it's in a hosting center, whatever range of addresses is allocated to the compromised server.

For policy lists like the PBL, the range to list is set by the network manager, but it's often possible for individuals to ask to delist their own IPs. It's an open question whether an IPv6 delist should be just for a single IP (since that's all a mail server needs), or the whole LAN.

At this point, there is no reliable way to look inside a network and see what the suballocation sizes are. There's some work going on, both a son-of-WHOIS project which could let networks publish the info along with the rest of the WHOIS info for the IP block and (unlike the current WHOIS mess) other people could query it mechanically. I've also talked to a few people at the IETF who say it's not out of the question to provide it through tweaks to existing protocols, but that would be some way out.

With information about suballocation sizes, it should be possible to manage IPv6 DNSBLs as effectively as IPv4 ones, but there's still the issue of whether it's practical to use existing methords to query them. Fortunately for the e-mail world, it will be many years before there is any v6 mail that can't be handled just as well via v4, so we have time to figure all these things out.

By John Levine, Author, Consultant & Speaker. More blog posts from John Levine can also be read here.

Related topics: Email, IPv6, Spam, Whois

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:


A possible aggressive form of spam blocking Phil Howard  –  May 26, 2012 8:27 PM PST

A possible aggressive form of spam blocking can be based on common levels of reverse DNS delegation.  This should still work fine in IPv6.  If spam is detected by other means from some address, look up its chain of rDNS delegation to determine the network size.  Well, you won't know the size per se, but you will know the rDNS delegation.  Next you can probe around for like delegations to detect the network size, or just do it as more spam comes in.

To reduce the aggressiveness level, add a whitelist reputation for these rDNS delegations, primarily for the ISP delegation.

By associating reputations with rDNS, it encourages ISPs to do the delegation to the next level so spammer customers can be more isolated and recognized.  It's effectively identifying networks without the need to identify them specifically.

rDNS John Levine  –  May 26, 2012 8:47 PM PST

That doesn't impress me as very workable.  A cable ISP may well give every residential user a /64, they are unlikely to individually delegate the rDNS to each customer.

To post comments, please login or create an account.

Related Blogs

Related News


Industry Updates – Sponsored Posts

To Where are Bounce Messages Sent?

An Open Source Perspective on Commercial MTAs

Five Essential PowerMTA Configuration Tips

What's New With Port25's PowerMTA v4.5

New Feature in PowerMTA v4.5: IP Based Rate Limiting

Case Study: Emergency Response Systems Rely on Timely Messaging Through PowerMTA

Port25 Announces Next Major Release of Its Email Delivery Solution, PowerMTA

Case Study: How PowerMTA Transparent Deliverability Metrics Paves Way for Email Service Provider

Case Study: MailChimp Achieves Efficient Execution and Reliability with PowerMTA

Case Study: Emma Swaps Its SMTP Infrastructure for PowerMTA to Handle Growing Mail Volume

Case Study: Email Service Provider GetResponse Scales with PowerMTA

Case Study: How PowerMTA Helped Forfront With Its Growing Message Volume

Hybrid Cloud Proves Clouds Are Worthy of Email Infrastructure

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Non-English "IDN Email" Addresses Are Finally Working!

Dyn Adds Chris Griffiths As New VP of Labs

A Look Inside Dyn's 1.2 Billion Monthly Email Delivery Statistics

Dyn to Host Email Analytics Webinar With Ongage

Dyn Adds Claudia Santoro, Dave Connors and Andrew Sullivan to Technical Team

Dyn Receives $38M Investment from North Bridge

Sponsored Topics