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, Networks, Spam, Whois


Don't miss a thing – get the Weekly Wrap delivered to your inbox.


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

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 9:47 PM PDT

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

Explore Topics

Dig Deeper


Sponsored by Verisign

Mobile Internet

Sponsored by Afilias Mobile & Web Services

IP Addressing

Sponsored by Avenue4 LLC

DNS Security

Sponsored by Afilias

Promoted Posts

Buying or Selling IPv4 Addresses?

Watch this video to discover how ACCELR/8, a transformative IPv4 trading platform developed by industry veterans Marc Lindsey and Janine Goodman, enables organizations to buy or sell IPv4 blocks as small as /20s. more»

Industry Updates – Sponsored Posts

Avenue4 Helps IPv4 Sellers and Buyers Gain Market Access, Overcome Complexities

Introduction to ACCELR/8 - Fast Lane to the IPv4 Market

Avenue4 Launches ACCELR/8, Transforming the IPv4 Market with Automated Order-Driven Trading

Attacks Decrease by 23 Precent in 1st Quarter While Peak Attack Sizes Increase: DDoS Trends Report

Government Guidance for Email Authentication Has Arrived in USA and UK

ValiMail Raises $12M for Its Email Authentication Service

Verisign Releases Q2 2016 DDoS Trends Report - Layer 7 DDoS Attacks a Growing Trend

Port25 Announces Release of PowerMTA V4.5r5

New Case Study: Jobtome.com Replaces 30 Postfix Servers with a Single PowerMTA

Verisign Q1 2016 DDoS Trends: Attack Activity Increases 111 Percent Year Over Year

Mobile Web Intelligence Report: Bots and Crawlers May Represent up to 50% of Web Traffic

An Update on Port25 and the Future of PowerMTA - One Year Later​

Encrypting Inbound and Outbound Email Connections with PowerMTA

V12 Group Sustains Customer Satisfaction by Deploying PowerMTA for Launchpad Platform

PowerMTA Now Offers Scheduled Delivery Control

Dyn Weighs In On Whois

Data Volumes and Network Stress to Be Top IoT Concerns

DKIM for ESPs: The Struggle of Living Up to the Ideal

Reactivation Campaign: Shared vs. Dedicated IPs

To Where are Bounce Messages Sent?