Close this search box.

The Effectiveness of DNSBLs in an IPv6 world

It is certain that the future of the Internet communication belongs to the Internet Protocol version 6, or IPv6. Even though some people might think it is new, it’s been around for quite a while; the first document describing basics of IPv6 (RFC 2460) was published in 1998. The protocol has evolved since, and it now comes as a standard on all modern operating systems. People in the IT industry had different opinions regarding IPv6’s adoption. Some predicted that it will never be adopted and will fade away, while some IPv6 activists made their websites available over IPv6 more than a year ago. 

According to the Global IPv6 Deployment Progress Report, IPv6 adoption is on the move. It is slow – only about 11,000 websites from the Alexa top 1 million list are using direct IPv6 address and about the same amount is capable of sending email over IPv6, – but it is happening.

Today, when moving to IPv6 is no longer a question, just a matter of time, various Internet security vendors have started working on compliance with IPv6. The most common and, probably, the cheapest way of dealing with malicious servers is various DNS-based reputation services, a.k.a DNSBL’s. DNSBL stands for DNS-based Blackhole list, or Block list, or Blacklist – a list of IP addresses published through the Internet Domain Name Service (DNS). There are many various implementations of DNSBL: there are black lists, white lists, yellow lists, and a few more. DNSBL’s are most often used to list IP addresses of spamming computers. One of the advantages of DNSBL is the ease of implementation. Most mail servers support DNSBL queries and there are quite a few free DNSBL’s out there. In order to provide fast and efficient service, DNS relies on caching mechanisms that allow for a distributed architecture.

So, what’s going to change for DNSBL’s in the IPv6 world? I think, that most of them will either cease to exist or will move away from the traditional DNS structure, and this is why: The IPv6 address space is huge!

In theory, a computer can change its IPv6 address with every email it sends out, and not run out of IPv6 addresses in years. So adding individual IPv6 addresses to a DNSBL as we know it today becomes impractical, if not technically impossible. DNS caches both positive and negative responses (negative caching) and DNS servers will run out of resources sooner than they will cache all available IPv6 addresses. An alternative is to use very low or zero TTL which, in turn, may overload DNSBL servers causing disruption of service.

Still, there are organizations that are working on, or already providing IPv6 reputation services. Let’s see how they deal with the aforementioned challenges.

One way of dealing with the vast amount of IPv6 addresses is to minimize the scope. Assuming that ISPs assign a /64 address space to each computer, a provider could work with this much lower resolution and add 64 bit blocks to its DNSBL. However, by using this method, one compromises the accuracy of detection. There is a higher potential of increased False Negatives as well as False Positives (since legitimate or malicious addresses might be inadvertently grouped together).

Another option is to develop a proprietary protocol that addresses the challenges, but the problem here is that this will be limited to the customer base of the product vendor, and no matter how great the product is, it may never become a standard, such as DNSBL today.

One other approach to dealing with IPv6 is whitelisting. At first glance, it makes sense – why bother with undecillions of potential bad IPv6 addresses, when we can keep a list of “good guys” and drop connections from all the rest. Well, who said that all the guys joining the whitelist are good? Will there be some kind of a verification process, or will it be a “free to join” list that will allow spammers to register as well as legitimate senders? For example, as one IPv6 Mailserver Whitelist states: “… there are NO technical restrictions, and there is not even a judgment of the IPs registered. Once you are registered, and receive at least a lookup once yearly, the IP will never be automatically removed from the whitelist.”

Spammers are generally very aware of such potential loopholes, and I am sure they will find a way to use something like this to their advantage.

So, what’s the answer? I think it is too early to say for sure. Personally, I believe that the solution should include all of the above, that is to be able to block individual IPv6 address as well as various ranges when it makes sense, to be able to whitelist verified legitimate senders, to be capable of storing information about all active computers using IPv6, and to provide multiple ways of integration with standard or proprietary systems.

Of course Commtouch’s GlobalView Mail Reputation utilizing the new Commtouch Detection Engine version 8 can do all of the above. As I mentioned earlier, it is too early to judge any IPv6 oriented system, but I believe that Commtouch technology has all the right ingredients to do it right. It is flexible and adaptive, and it has a long and proven record of great performance.

That being said, everything remains just a speculation before we’ll see any substantial use of IPv6 out in the wild, which may take a while. All approaches to IPv6 reputation have the right to be and prove themselves and the brave people behind the new approaches and technologies have my sincere respect for doing what they think is right before everybody else.