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:

Comments

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

Topics

Industry Updates – Sponsored Posts

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

New Nixu Solution Slashes Cloud Application Delivery Times from Weeks to Milliseconds

Top-Level Domain Survey Findings Not Surprising, But Still Concerning

Domain Name Registrations Pass 233 Million in the First Quarter Of 2012

Nominum selected as 2012 AlwaysOn Global 250 Top Private Company

Nominum Releases New Version of Carrier-Grade DHCP Software for Telecom Providers

Nominum Survey of World's Leading ISPs Shows Nearly 60% of ISPs Plan to Roll-Out IPv6 by End of 2012

Nominum Launches Comprehensive Suite of DNS-Based Security Solutions for Russian Service Providers

Nominum Sets New Record for Network Speed and Efficiency

Implementing a Cyber-Security Code of Conduct: Real-Life Lessons From Australia (Webinar)

Nominum and Nixu Software to Deliver Centralized DNS and DHCP Management Solution

DNS on Defense, DNS on Offense

Managing Outbound Spam: A New DNS-based Approach For Stopping Abuse (Webinar)

Nixu NameSurfer 7.2 Strikes Rich at Dojo

Sponsored Topics

Verisign

Security

Sponsored by
Verisign
Afilias

DNS Security

Sponsored by
Afilias
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
dotMobi

Mobile

Sponsored by
dotMobi