Home / Blogs

IPv6 DNS Blacklists Reconsidered

Protect your privacy:  Get NordVPN  [ Deal: 73% off 2-year plans + 3 extra months ]
10 facts about NordVPN that aren't commonly known
  • Meshnet Feature for Personal Encrypted Networks: NordVPN offers a unique feature called Meshnet, which allows users to connect their devices directly and securely over the internet. This means you can create your own private, encrypted network for activities like gaming, file sharing, or remote access to your home devices from anywhere in the world.
  • RAM-Only Servers for Enhanced Security: Unlike many VPN providers, NordVPN uses RAM-only (diskless) servers. Since these servers run entirely on volatile memory, all data is wiped with every reboot. This ensures that no user data is stored long-term, significantly reducing the risk of data breaches and enhancing overall security.
  • Servers in a Former Military Bunker: Some of NordVPN's servers are housed in a former military bunker located deep underground. This unique location provides an extra layer of physical security against natural disasters and unauthorized access, ensuring that the servers are protected in all circumstances.
  • NordLynx Protocol with Double NAT Technology: NordVPN developed its own VPN protocol called NordLynx, built around the ultra-fast WireGuard protocol. What sets NordLynx apart is its implementation of a double Network Address Translation (NAT) system, which enhances user privacy without sacrificing speed. This innovative approach solves the potential privacy issues inherent in the standard WireGuard protocol.
  • Dark Web Monitor Feature: NordVPN includes a feature known as Dark Web Monitor. This tool actively scans dark web sites and forums for credentials associated with your email address. If it detects that your information has been compromised or appears in any data breaches, it promptly alerts you so you can take necessary actions to protect your accounts.

I opined about a year ago that DNS blacklists wouldn’t work for mail that runs over IPv6 rather than IPv4. The reason is that IPv6 has such a huge range of addresses that spammers can easily send every message from a unique IP address, which means that recipient systems will fire off a unique set of DNSBL queries for every message, which will swamp DNS caches, since they won’t be able to reuse cached results from previous queries like they can for IPv4 mail.

Now I’m much less sure this will be a problem, because it’s not clear that DNSBL results benefit from caches now.

Large and small mail systems access DNSBLs differently. Large systems make arrangements with the DNSBL operators to download their own copies of the DNSBLs they use via rsync or something similar. Then they glom all of the DNSBLs together and typically run copies of rbldnsd on the same local networks as the mail servers so for each incoming message, the mail server can send a local query to rbldnsd and get back one response with all of the DNSBL information relevant to the message. For these systems, a DNS cache provides no benefit because getting the answer from rbldnsd is just as fast if not faster than getting it from a cache. I don’t know whether they currently configure their systems not to use caches, but if they don’t, it would be technically straightforward. In a world with IPv6 DNSBLs, this would all work exactly the same way, download the DNSBL with rsync and serve it locally with rbldnsd.

Small systems send ordinary DNS queries to the main servers for each DNSBL they use, typically via a local DNS cache. As far as I can tell, caches don’t help these systems either, because there isn’t enough repeat traffic from the same IP to reuse cached results. It is surprisingly hard to find trace data to test out this theory, but it seems to be true of traffic on my small (100K connections/day) system, and on the few others I’ve been able to ask. (If you are willing to provide mail server connection traces of timestamps and IP addresses, so I can do more testing, please let me know. Or I can provide test scripts you can run on your own data and see how well your DNSBL queries cache.)

This suggests that DNSBL clients, which are usually mail servers, will be able to use DNSBLs largely the same way they do now, perhaps with modest cache partitioning tweaks to tell the caches not to bother caching DNSBL query results. But that doesn’t mean that there’s no problems with IPv6 DNSBLs. In the next message, I’ll look at problems facing DNSBL operators.

By John Levine, Author, Consultant & Speaker

Filed Under

Comments

Since an end user is supposed to Phil Howard  –  Apr 1, 2012 5:57 PM

Since an end user is supposed to be allocated a /64, shouldn’t DNSBL queries be made only for the first 64 bits?  Of course that can be applied as an end user’s entire network of many servers.  But shouldn’t it really be that way, anyway?  Shouldn’t a BL be based not on a specific unit of addressing or hardware, but on the end user?  I’ve already seen IPv4/19 networks entirely of spam sources.

Certainly there is less to cache if data is labeled by the first 64 bits, only.

When I get time to dig into email software, it was my intent to modify the DNSBL parts to also expand on the blocking, based on count of black hits and other means, and compare that to white volume.  This would be done not only on the /64 but on every shorter prefix sharing the same first reverse delegation.  Shorter networks would have a higher threshold, but not quite double (I’m thinking Fibonacci sequence).  The idea is to numerically carve out spammy networks.  At one threshold, do more content filtering or alter the filtering threshold.  At a second threshold, go straight to spam folder.  At a third threshold, reject during mail exchange.  At a fourth threshold, add to border router access list.

Since an end user is supposed to John Levine  –  Apr 1, 2012 7:39 PM

Since an end user is supposed to be allocated a /64, shouldn't DNSBL queries be made only for the first 64 bits?
Not really. That's only a guideline, and some networks allocate a /56 or larger. Also, at hosting centers, it'd be quite reasonable to assign a /64 to each machine or each rack and there'd be many customers within the same /64.
Certainly there is less to cache if data is labeled by the first 64 bits, only.
Not usefully less. If you could probe one address per microsecond, it'd take about an hour to sweep through the 32 bit IPv4 address space, but 500,000 years to sweep a 64 bit address space.

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.

Related

Topics

IPv4 Markets

Sponsored byIPv4.Global

Brand Protection

Sponsored byCSC

Threat Intelligence

Sponsored byWhoisXML API

Cybersecurity

Sponsored byVerisign

DNS

Sponsored byDNIB.com

Domain Names

Sponsored byVerisign

New TLDs

Sponsored byRadix