About This Document

This document outlines Spamhaus' strategy with respect to Spamhaus' IP blocklists and their future in an IPv6 enabled world. This is an evolving strategy - as more information is obtained we expect to see modifications and new ideas rolled into the way IPv6 blocklists will function.

Spamhaus has a defence in depth approach to IPv6 but this document focuses exclusively on IPv6 blocklists. Spamhaus' full strategy for filtering mail in IPv6 - covering IP and domain blocklists, new reputation lists, domain whitelists and DKIM - will be detailed in a separate comprehensive strategy document.

Since there is as yet very little IPv6 mail, Spamhaus has a forward looking two stage plan for implementing IPv6 DNSBLs. Initially, for ease of implementation, we will support the legacy query method described in RFC 5782. Later we will move toward a more robust and sophisticated DNS-based method of publishing blocklists as we and everyone else gain experience with IPv6 mail.


Considerations include:

• The entire IPv6 address space will not be allocated all at once. We are not going to move from a world with 2^32 IP addresses to 2^128 addresses overnight.
  
  
• The vast majority of SMTP traffic will continue to be carried over IPv4 for the foreseeable future. Anyone who wants to exchange mail with the existing SMTP world will need to maintain IPv4 addresses for its servers, either directly or via a relay. Even as fresh IPv4 address space runs out, we anticipate that networks will be able to rent or buy the small amount needed to support e-mail. Hence we have time to address the significant new challenges that IPv6 mail will present.
  
  
• IPv6 presents significant new challenges for mail systems compared to IPv4. Most importantly, the vast size of the IPv6 space means that approaches that work in IPv4 do not necessarily scale to IPv6. For example, a sender could easily do "spread spectrum" spamming, using a different IP address for every message. Thus a major issue with current DNS based blocklist querying is the memory cache size of DNS resolvers in comparison to the vast numbers of IP addresses spammers will be able to use in IPv6. Although we think we understand the likely issues, neither we nor anyone really knows how both legitimate mail and spam will use IPv6.
  
  
• We expect that unforeseen scalability issues can be addressed incrementally as they start to make themselves apparent. Current traffic in the nascent world of IPv6 email today is of little use to predict what will happen when people start "using it for real".

Spamhaus is taking a two-tier approach to serving DNSBLs in IPv6:


The Short Term Plan

To assist large ISP and carrier users of the Spamhaus Datafeed (who we foresee as the first to run implementations of IPv6 mail servers) we will provide blocklist data zones for use in blocking and filtering on IPv6-enabled mail servers in legacy RFC 5782 format. The ability to host the blocklists locally will allow for querying methods that will not cause DNS resolver cache issues.

The Long Term Strategy

To provide a robust and efficient long term solution Spamhaus is developing a new DNS query mechanism based on a B-tree data structure adapted from proved database technology. This mechanism is designed to handle DNS queries without overloading DNS caches - an almost- certain problem as IPv6 usage grows. Currently under development, the new B-tree query system may be available for experimental use towards the end of this year.

The need to transition to a better design for handling DNS queries is brought about by a problem with existing DNS caches under IPv6, caused by the vast size of IPv6 addresses and the ease with which spammers can send each spam message from a different IP address - very quickly filling up DNS caches as mail programs make a DNSBL query for each address.

The B-tree solution to this DNS cache problem is outlined by John Levine at http://tools.ietf.org/id/draft-levine-iprangepub-02.txt



This strategy affects Spamhaus IPv6 Users in the following ways:


Spamhaus Datafeed Rsync Customers

Assuming a query server, such as an IPv6-enabled rbldnsd server, is on the same LAN as the client, using a low TTL for the zones should solve the potential DNS cache problem. Once the B-tree solution (described above in 'The Long Term Strategy') is available, Datafeed users will be able to implement it locally if desired as software is upgraded. The data provided to Spamhaus Datafeed rsync customers will be in a form analogous to IPv4 blocklists, e.g., 2001:DB8:abc:123::/64.


Spamhaus Datafeed Query Customers

Query customers will continue to query the dedicated Spamhaus Query servers as they do now. When Spamhaus IPv6 zones become available, they will be served in legacy RFC 5782 format using a low (possibly even 0) TTL As not caching DNS queries can slow email processing, as soon as the new B-tree solution is available, all Datafeed Query customers will be transitioned to the B-tree query mechanism as their software is upgraded to support it.


Spamhaus Free Public Query Users

The Spamhaus Free Public service will use the more DNS cache-friendly B-tree solution as soon as it becomes widely available. It is possible that we may in the interim serve IPv6 zones in legacy RFC 5782 format on the free public mirrors, using a low (possibly even 0) TTL. However the increased loads on our free public infrastructure caused by using a low TTL means that usage limits may be lowered and will have to be policed more strictly. Once the more efficient B-tree solution is widely available the Spamhaus Free Public service will then only be available to software capable of using the B-tree solution.



Technical Aspects:


Which blocklists will be available in IPv6?

At this time Spamhaus expects to produce IPv6 analogs for the Spamhaus Blocklist (SBL), the eXploits Blocklist (XBL) and the Policy Blocklist (PBL).


IPv6 Blocklist minimum range

Based on how we view the specifications for allocation of IPv6 addresses, all Spamhaus blocklists will list IPv6 ranges no smaller than a /64.


Querying IPv6 blocklists

IPv4 blocklists are queried by prepending the reversed decimal quad address to the zone to be queried. Legacy queries for IPv6 blocklists will use a similar model; the fully expanded IPv6 address is reversed by hex digit and prepended to the zone to be queried. For example, to query the address 2001:DB8:abc:123::42 the IPv6 address would be expanded, reversed and prepended to the zone to be queried, to give an example query of:
2.4.0.0.0.0.0.0.0.0.0.0.0.0.0.0.3.2.1.0.c.b.a.0.8.b.d.0.1.0.0.2.zen.spamhaus.org


Returned result

The result returned from an IPv6 legacy query will be A and TXT records results, the same as with Spamhaus' existing IPv4 blocklists. (Note that the numeric value will continue to be in an A record, not AAAA.)

To minimize conversion effort, the newer B-tree query system will return numeric and string values similar to the legacy values.