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.\u00a0 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.<\/p>\n
The recommendation to dual-stack nameservers is related to the general guidance for enterprises to\u00a0begin their IPv6 deployment at their Internet perimeter<\/a>.\u00a0 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.\u00a0 Once an organization has obtained their global IPv6 address allocation from their\u00a0Regional Internet Registry (RIR),<\/a>\u00a0the next step is to contact their upstream Internet providers and start to advertise this allocated prefix to the Internet.\u00a0 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.\u00a0 This has been the\u00a0standard IPv6 deployment guidance for enterprises<\/a>\u00a0for many years.<\/p>\n This advice is also consistent with IETF RFC 7381 \u201cEnterprise IPv6 Deployment Guidelines<\/a>\u201d.\u00a0 This RFC advises enterprises to perform a phased approach, starting with a\u00a0preparation and assessment phase<\/a>\u00a0to get all your\u00a0ducks in a row<\/a>.\u00a0 The next phase is to\u00a0progress to the external environment<\/a>, establishing connectivity to the IPv6 Internet.<\/p>\n The U.S. federal government has published several mandates for departments and agencies to adopt IPv6.\u00a0 The\u00a0Federal CIO\u2019s guidance to government enterprises<\/a>\u00a0was to start at the Internet edge and IPv6-enable their web servers, e-mail servers, and nameservers.\u00a0 The plan was to have these steps completed by September 2012. While some organizations didn\u2019t meet that date, there has been a\u00a0significant percentage of federal perimeter Internet services that are now IPv6-enabled<\/a>.<\/p>\n The root nameservers make up the root DNS zone and answer requests for Top Level Domain (TLD) authoritative nameservers.\u00a0 Today, ALL root nameservers are IPv6-enabled.\u00a0\u00a0IANA\u2019s list of root name servers<\/a>\u00a0shows their IPv6 addresses.\u00a0 Each DNS resolver uses the named.root file to provide them the anycast addresses of the current root nameservers.\u00a0 The\u00a0latest version of the named.root file<\/a>\u00a0was published a few weeks ago on July 9, 2018 and now there are IPv6 anycast addresses for each root nameserver.\u00a0 If your nameservers are not configured to automatically keep this information up to date, then you should\u00a0manually verify it.\u00a0 (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.)<\/p>\n When it comes to\u00a0Top Level Domains<\/a>\u00a0(TLDs), there is also an extremely high percentage of IPv6 support in Internet nameservers.\u00a0 Many of these TLD nameservers use IPv6 glue records along with NS records to delegate name resolutions to authoritative nameservers.\u00a0 Evidence of this is documented in the Hurricane Electric (HE.net)\u00a0Global IPv6 Deployment Progress Report<\/a>, by Mike Leber.\u00a0 He reports the \u201cPercentage of TLDs with IPv6 nameservers: 98.4%\u201d and the \u201cPercentage of TLDs that have nameservers with IPv6 glue in the root zone: 98.2%\u201d.\u00a0 The reason that this isn\u2019t higher is that there are some obscure country codes and lesser-known and infrequently-used TLDs that haven\u2019t yet deployed IPv6.\u00a0 This is probably due to a\u00a0lack of IPv6 knowledge<\/a>\u00a0and experience on the part of the people who maintain those nameservers.<\/p>\n Now,\u00a0six years since World IPv6 Launch<\/a>, much of the core of the Internet is running IPv6.\u00a0 Virtually all Internet Exchanges are using IPv6 and all large\u00a0Tier 1<\/a>\u00a0and Tier 2 service providers are using IPv6 in their core networks.\u00a0 Many of the large content providers are using IPv6. \u00a0But many enterprises haven\u2019t yet adopted the protocol, even at their Internet perimeters.\u00a0 However, that is where many enterprises have their public-facing authoritative nameservers.\u00a0 Enterprises will want their nameservers accessible by the \u201cwhole Internet\u201d using both IPv4 and IPv6 for maximum reachability.<\/p>\n IPv6 Internet connectivity has been shown by\u00a0Facebook<\/a>,\u00a0Apple<\/a>, and\u00a0Google<\/a>\u00a0to be faster in some situations.\u00a0 You will want to take advantage of\u00a0that performance benefit<\/a>.\u00a0 The same would be true for authoritative nameservers.\u00a0 This leads to the conclusion that and enterprise\u2019s authoritative nameservers on their Internet perimeter could perform faster using IPv6.<\/p>\n Recent research published by Geoff Huston, APNIC\u2019s Chief Scientist,\u00a0found that up to 35% of the Internet DNS traffic was using IPv6 transport<\/a>.\u00a0 In his paper titled \u201cIPv6 in the DNS<\/a>\u201d, he found that Google, AT&T and Comcast\u2019s DNS resolvers handle the highest percentage of resolutions and account for almost 50% of the total number of IPv6 DNS queries.\u00a0 He concluded by saying \u201cThe DNS is well on the path of transition and perhaps further along this path than all the other elements of the Internet\u2019s infrastructure.\u201d\u00a0 Therefore, if these core Internet DNS resolvers are using IPv6 in a significant way, then your organization\u2019s authoritative DNS resolvers should also use IPv6.<\/p>\n The behavior of Internet DNS resolution is documented in the early IETF RFCs,\u00a0RFC 1034<\/a>\u00a0and\u00a0RFC 1035<\/a>.\u00a0 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.\u00a0 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.\u00a0 It asks those root nameservers about the\u00a0Top-Level Domain<\/a>\u00a0(e.g., .com, .net, .org, etc.) nameservers.\u00a0 The resolver will then obtain the Name Server (NS) records for the domain\u2019s authoritative nameserver.\u00a0 We are also familiar with how a single FQDN can have both an A record for its IPv4 address and a AAAA (pronounced \u201cquad A\u201d) record for its IPv6 address.<\/p>\n The next question is what happens if there are multiple NS records using multiple protocols? \u00a0Does it sort them? \u00a0Is it based on response time? \u00a0How does it choose?\u00a0 Who has the wisdom to answer such questions?\u00a0 This sounds like a job for \u201cAsk Mr. DNS<\/a>\u201d!<\/p>\n If we open up our well-worn copy of\u00a0DNS and BIND<\/a>\u00a0(5th<\/sup>\u00a0edition) by Cricket Liu and Paul Albitz, we find in Chapter 2 a section titled \u201cChoosing Between Authoritative Nameservers\u201d that describes the process.<\/p>\n Nameservers use a method of calculating authoritative nameserver response time using Round Trip Time (RTT) calculated based on the observed latency of previous queries.\u00a0 Resolvers favor the nameservers with the fastest\/lowest RTT.\u00a0 This paper titled \u201cAuthority Server Selection of DNS Caching Resolvers<\/a>\u201d by Yingdi Yu and Lixia Zhang of UCLA and Duane Wessels and Matt Larson of Verisign, goes into the mathematics for the RTT calculation.<\/p>\n 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.<\/p>\n 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.<\/p>\n Another behavior of dual-protocol DNS that is helpful to understand is how DNS queries use IPv4 and IPv6.\u00a0 Many years ago, there were problems with early DNS resolvers that didn\u2019t understand IPv6 answers and would fail in curious ways.\u00a0 There was some known misbehavior of DNS authoritative servers when they were queried for AAAA resource records.\u00a0 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.\u00a0 This situation led to the publication of IETF RFC 4074, \u201cCommon Misbehavior Against DNS Queries for IPv6 Addresses<\/a>,\u201d which required queries be separated into individual IPv4 and IPv6 queries that were then sent simultaneously.\u00a0 The thinking was that if the IPv6 query failed, at least the IPv4 query would succeed and there wouldn\u2019t be a loss of connectivity.\u00a0 Now that there is so much IPv6 support on the Internet and this problem has long been solved, there are proposals to\u00a0change the behavior to treat IPv4 and IPv6 fairly to achieve greater DNS performance<\/a>.<\/p>\n Most enterprise organizations\u00a0take DNS for granted and fail to recognize how important it is<\/a>\u00a0to every application they use.\u00a0 The reality is, every application that an enterprise uses relies upon stable, accurate, available and high-performance DNS infrastructure.\u00a0 Poor quality DNS infrastructure can have a dramatic impact on\u00a0end-user experience<\/a>\u00a0(UX) and can have catastrophic results for businesses it if is not made to function reliably and fast.\u00a0 As enterprises strive to achieve high-performance and resilient IT infrastructure, they should strive to create the best possible DNS infrastructure and network connectivity.\u00a0 Using both IPv4 and IPv6 for your nameservers is strongly recommended and is a task that is on the critical path to IPv6 deployment.\u00a0 Whether an enterprise is using their own\u00a0on-premises DNS servers or a cloud-based DNS service<\/a>, organizations should be making their DNS infrastructure dual-protocol.\u00a0 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.<\/p>\n Scott Hogg\u00a0(@ScottHogg<\/a>) is CTO of\u00a0HexaBuild.io<\/a>, an IPv6 consulting and training company.\u00a0 Scott is Chair Emeritus of the Rocky Mountain IPv6 Task Force (RMv6TF<\/a>) and authored the Cisco Press book on\u00a0IPv6 Security<\/a>.\u00a0 Follow HexaBuild on\u00a0Twitter<\/a>\u00a0and\u00a0LinkedIn<\/a>.<\/p>\n","protected":false},"excerpt":{"rendered":" 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.\u00a0 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 […]<\/p>\n","protected":false},"author":321,"featured_media":1496,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"_genesis_hide_title":false,"_genesis_hide_breadcrumbs":false,"_genesis_hide_singular_image":false,"_genesis_hide_footer_widgets":false,"_genesis_custom_body_class":"","_genesis_custom_post_class":"","_genesis_layout":"","footnotes":""},"categories":[17],"tags":[30,56,38,39],"class_list":{"0":"post-1495","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-ipv6-coe","8":"tag-dns","9":"tag-ipv4","10":"tag-ipv6","11":"tag-protocols","12":"entry"},"acf":[],"yoast_head":"\nDual-Protocol Nameservers<\/h2>\n
IPv6 Internet Usage and DNS Usage<\/h2>\n
How DNS Nameservers Work<\/h2>\n
Summary<\/h2>\n