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


2012
Months
May

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


Subscribe to this blog


RSS feed


Home :: Email


25 May 2012

Running DNSBLs in an IPv6 world Email

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.


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

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


What if a small office got a /64 (which seems reasonable) and ran a mail server, that sends only legitimate mail, as well as a web server. And then the web server got compromised and starts spewing out spam. Your scheme, as I understand it, would add the full /64 to a blacklist. This may be a price we'd have to pay, but it sounds like a sub-optimal solution to me.

I don't think it's possible to run IPv6 blacklists to the level of single addresses. Perhaps we have to say that IPv4 was ideal for IPv4-blacklisting -- enough addresses to stop senders from changing addresses frequently and not too many to list them individually -- I'd much rather see domain-based filtering play a more prominent place. Making DKIM signatures 'mandatory' for mail sent over IPv6 for instance.

Regarding your final comment, I agree there is no need for email going IPv6 for the foreseeable future. But it may well be that IPv6 will gain enough momentum and that email will go IPv6 anyway. We'd better be prepared.

(by Martijn 26 May 2012 09:00)


small offices and such
I can't have a lot of sympathy for the small office scenario. If you want people to accept your traffic, keep your traffic clean. Yes, it's extra work to secure your web server, but on today's Internet, dealing with bad guys comes with the job.

(by John Levine 26 May 2012 15:47)


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
Spam trends update for Sep-Nov 2023
55 days ago

A keen grasp of the obvious
Italian Apple Cake
553 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.