In this installment of the Infoblox IPv6 Center of Excellence (COE) blog series, we will examine why organizations should make their public authoritative nameservers communicate using both IPv4 and IPv6. This has been the advice of experienced network architects for many years, but others may not be aware of why this would be an advantageous configuration.
Start your IPv6 Deployment at the Internet Edge
The recommendation to dual-stack nameservers is related to the general guidance for enterprises to begin their IPv6 deployment at their Internet perimeter. The concept is that the Internet edge is where an enterprise connects to the Internet, and is, therefore, the logical place to start connecting to the IPv6 Internet. Once an organization has obtained their global IPv6 address allocation from their Regional Internet Registry (RIR), the next step is to contact their upstream Internet providers and start to advertise this allocated prefix to the Internet. Once they have IPv6 Internet connectivity, the next step would be to configure IPv6 on the perimeter firewall and onto the DMZ networks where public-facing servers are connected. This has been the standard IPv6 deployment guidance for enterprises for many years.
This advice is also consistent with IETF RFC 7381 “Enterprise IPv6 Deployment Guidelines”. This RFC advises enterprises to perform a phased approach, starting with a preparation and assessment phase to get all your ducks in a row. The next phase is to progress to the external environment, establishing connectivity to the IPv6 Internet.
The U.S. federal government has published several mandates for departments and agencies to adopt IPv6. The Federal CIO’s guidance to government enterprises was to start at the Internet edge and IPv6-enable their web servers, e-mail servers, and nameservers. The plan was to have these steps completed by September 2012. While some organizations didn’t meet that date, there has been a significant percentage of federal perimeter Internet services that are now IPv6-enabled.
Dual-Protocol Nameservers
The root nameservers make up the root DNS zone and answer requests for Top Level Domain (TLD) authoritative nameservers. Today, ALL root nameservers are IPv6-enabled. IANA’s list of root name servers shows their IPv6 addresses. Each DNS resolver uses the named.root file to provide them the anycast addresses of the current root nameservers. The latest version of the named.root file was published a few weeks ago on July 9, 2018 and now there are IPv6 anycast addresses for each root nameserver. If your nameservers are not configured to automatically keep this information up to date, then you should manually verify it. (Although, most nameservers automatically update this named.root file as it is changed, it may still be a good idea to periodically check that this procedure is taking place.)
When it comes to Top Level Domains (TLDs), there is also an extremely high percentage of IPv6 support in Internet nameservers. Many of these TLD nameservers use IPv6 glue records along with NS records to delegate name resolutions to authoritative nameservers. Evidence of this is documented in the Hurricane Electric (HE.net) Global IPv6 Deployment Progress Report, by Mike Leber. He reports the “Percentage of TLDs with IPv6 nameservers: 98.4%” and the “Percentage of TLDs that have nameservers with IPv6 glue in the root zone: 98.2%”. The reason that this isn’t higher is that there are some obscure country codes and lesser-known and infrequently-used TLDs that haven’t yet deployed IPv6. This is probably due to a lack of IPv6 knowledge and experience on the part of the people who maintain those nameservers.
IPv6 Internet Usage and DNS Usage
Now, six years since World IPv6 Launch, much of the core of the Internet is running IPv6. Virtually all Internet Exchanges are using IPv6 and all large Tier 1 and Tier 2 service providers are using IPv6 in their core networks. Many of the large content providers are using IPv6. But many enterprises haven’t yet adopted the protocol, even at their Internet perimeters. However, that is where many enterprises have their public-facing authoritative nameservers. Enterprises will want their nameservers accessible by the “whole Internet” using both IPv4 and IPv6 for maximum reachability.
IPv6 Internet connectivity has been shown by Facebook, Apple, and Google to be faster in some situations. You will want to take advantage of that performance benefit. The same would be true for authoritative nameservers. This leads to the conclusion that and enterprise’s authoritative nameservers on their Internet perimeter could perform faster using IPv6.
Recent research published by Geoff Huston, APNIC’s Chief Scientist, found that up to 35% of the Internet DNS traffic was using IPv6 transport. In his paper titled “IPv6 in the DNS”, he found that Google, AT&T and Comcast’s DNS resolvers handle the highest percentage of resolutions and account for almost 50% of the total number of IPv6 DNS queries. He concluded by saying “The DNS is well on the path of transition and perhaps further along this path than all the other elements of the Internet’s infrastructure.” Therefore, if these core Internet DNS resolvers are using IPv6 in a significant way, then your organization’s authoritative DNS resolvers should also use IPv6.
How DNS Nameservers Work
The behavior of Internet DNS resolution is documented in the early IETF RFCs, RFC 1034 and RFC 1035. When it comes to IPv6 usage with DNS, we might be curious to understand how this behavior changes when two IP versions are in use. We are familiar with the process a DNS resolver performs during its recursive traversal of the Internet nameservers to find the authoritative nameserver for a given domain and how it first queries the root nameservers. It asks those root nameservers about the Top-Level Domain (e.g., .com, .net, .org, etc.) nameservers. The resolver will then obtain the Name Server (NS) records for the domain’s authoritative nameserver. We are also familiar with how a single FQDN can have both an A record for its IPv4 address and a AAAA (pronounced “quad A”) record for its IPv6 address.
The next question is what happens if there are multiple NS records using multiple protocols? Does it sort them? Is it based on response time? How does it choose? Who has the wisdom to answer such questions? This sounds like a job for “Ask Mr. DNS”!
If we open up our well-worn copy of DNS and BIND (5th edition) by Cricket Liu and Paul Albitz, we find in Chapter 2 a section titled “Choosing Between Authoritative Nameservers” that describes the process.
Nameservers use a method of calculating authoritative nameserver response time using Round Trip Time (RTT) calculated based on the observed latency of previous queries. Resolvers favor the nameservers with the fastest/lowest RTT. This paper titled “Authority Server Selection of DNS Caching Resolvers” by Yingdi Yu and Lixia Zhang of UCLA and Duane Wessels and Matt Larson of Verisign, goes into the mathematics for the RTT calculation.
It stands to reason, that if IPv6 can offer a performance advantage on the Internet, and your authoritative nameservers use IPv6, then IPv6 may be used more frequently because it would have a potentially lower average RTT.
In addition to making your nameservers connect to the Internet using IPv6 and allowing them to respond to IPv6 queries, you should also make sure that if you have IPv4 glue records defined for your NS records, that you also specify IPv6 glue records as well.
Another behavior of dual-protocol DNS that is helpful to understand is how DNS queries use IPv4 and IPv6. Many years ago, there were problems with early DNS resolvers that didn’t understand IPv6 answers and would fail in curious ways. There was some known misbehavior of DNS authoritative servers when they were queried for AAAA resource records. Such behavior can block IPv4 communication that should actually be available, causing a significant delay in name resolution, or even cause a denial of service. This situation led to the publication of IETF RFC 4074, “Common Misbehavior Against DNS Queries for IPv6 Addresses,” which required queries be separated into individual IPv4 and IPv6 queries that were then sent simultaneously. The thinking was that if the IPv6 query failed, at least the IPv4 query would succeed and there wouldn’t be a loss of connectivity. Now that there is so much IPv6 support on the Internet and this problem has long been solved, there are proposals to change the behavior to treat IPv4 and IPv6 fairly to achieve greater DNS performance.
Summary
Most enterprise organizations take DNS for granted and fail to recognize how important it is to every application they use. The reality is, every application that an enterprise uses relies upon stable, accurate, available and high-performance DNS infrastructure. Poor quality DNS infrastructure can have a dramatic impact on end-user experience (UX) and can have catastrophic results for businesses it if is not made to function reliably and fast. As enterprises strive to achieve high-performance and resilient IT infrastructure, they should strive to create the best possible DNS infrastructure and network connectivity. Using both IPv4 and IPv6 for your nameservers is strongly recommended and is a task that is on the critical path to IPv6 deployment. Whether an enterprise is using their own on-premises DNS servers or a cloud-based DNS service, organizations should be making their DNS infrastructure dual-protocol. Enterprises are encouraged to make their external nameservers use both protocols today, but eventually, enterprises will add IPv6 to their internal networks and their internal nameservers will use both IP versions.
Scott Hogg (@ScottHogg) is CTO of HexaBuild.io, an IPv6 consulting and training company. Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF) and authored the Cisco Press book on IPv6 Security. Follow HexaBuild on Twitter and LinkedIn.
