Home / Blogs

Running DNSBLs in an IPv6 World

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

Filed Under


A possible aggressive form of spam blocking Phil Howard  –  May 27, 2012 4:27 AM

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 27, 2012 4:47 AM

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.

Comment Title:

  Notify me of follow-up comments

We encourage you to post comments and engage in discussions that advance this post through relevant opinion, anecdotes, links and data. If you see a comment that you believe is irrelevant or inappropriate, you can report it using the link at the end of each comment. Views expressed in the comments do not represent those of CircleID. For more information on our comment policy, see Codes of Conduct.

CircleID Newsletter The Weekly Wrap

More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Co-designer of the TCP/IP Protocols & the Architecture of the Internet



Threat Intelligence

Sponsored byWhoisXML API

Domain Names

Sponsored byVerisign

IPv4 Markets

Sponsored byIPv4.Global


Sponsored byVerisign

New TLDs

Sponsored byRadix

Brand Protection

Sponsored byCSC