The transition to IPv6 is top of mind for most service providers. Even in places where there are still IPv4 addresses to be had surveys we’ve run suggest v6 is solidly on the priority list. That’s not to say everyone has the same strategy. Depending where you are in the world transition options are different—in places such as APAC where exhaustion is at hand one of the many NAT alternatives will likely be deployed since getting a significant allocation of addresses is not going to happen and other alternatives for obtaining addresses will prove expensive. Ditto the European region, who is next on the list to find the IPv4 shelves bare.

Fortunately the doom and gloom predictions about the imminent demise of the Internet if we don’t move to IPv6 now have died down. That’s not to say there isn’t still a sense of urgency, but pragmatism reigns, and technology and operational experience continue to work their magic. Initial dismissiveness of NAT has yielded to a realization that with proper equipment, design, and best practices it can be made to work. In fact it’s likely it will be made to work well.

So there’s no doubt some cycles must be expended finalizing decisions on transition mechanisms. Fortunately there are some things, the DNS for instance, in the network that doesn’t change as much with IPv6. It has been possible to resolve IPv6 queries for many years now on every major DNS platform (transition technologies that leverage the DNS, like DNS64, have also emerged although aren’t yet widely deployed—lets save that topic for another post). Because on the surface it does not appear to be a system that will be impacted by the transition, “it just works”, it’s tempting to take it off the priority list.

In fact a very strong case can be made that the DNS is a logical place to start the IPv6 transition. With budget money available for IPv6 why risk any issues with the DNS, the foundation of the network? Growth in DNS traffic remains very high and that won’t change with IPv6. Browser behaviors have been evolving in an effort to strike the right balance between bias toward v6 (sending AAAA queries first) and ensuring a good user experience—with implications for increasing query volumes even further. Attacks on the DNS won’t stop during or after the transition, and exploits that use the DNS won’t go away either. DDoS attacks have occurred over IPv6 and exploits on IPv6 are already being catalogued—attackers are agnostic about network access.

As is always the case in networking a little due diligence can pay big dividends, a few basic questions come to mind:

• How long has it been since your DNS has been resized?
• What is the average processor utilization of your servers?
• What’s the current performance (queries per second) and latency?
• What’s the trend?
• Have floods of queries ever brought down your DNS?
• How often is it attacked?
• How much DNS traffic is bot related (and perhaps more importantly what are the implications of that traffic on your network—but that’s a separate topic!).
• How difficult is it for you to gather this kind of DNS data?

Getting the DNS right ensures the network is stable, resilient, and ready to deliver the ultimate end user experience during and after the transition to IPv6. The question to ask is not whether the DNS supports IPv6—it does, but how well the DNS you have will support IPv6 and the next wave of devices, applications, and security exposures. Given the massive investments that will be made for the IPv6 transition it cannot be overlooked. No one wants to be the person that says “we just assumed that part of the network would be fine because it always worked before.”

Learn More: IPv6 – Beyond Business Continuity Join Nominum on May 30 for a webinar. DNS and DHCP are critical elements of IPv6 network design. IPv6 creates a unique opportunity to design a new network architecture that increases efficiency and enables competitive differentiation. Moderated by Craig Sprosts, Nominum’s GM of Fixed Broadband Solutions, this webinar will feature Ted Lemon, Nominum’s Principal DHCP architect and co-chair of the IETF DHCP working group.