DNS IPv6 Transport Operational Guidelines

Introduction Despite IPv6 being first discussed in the mid-1990s , consistent deployment throughout the whole Internet has not yet been accomplished . Hence, today, the Internet consists of IPv4-only, dual-stack (networks supporting both IP versions), and IPv6-only networks. This creates a complex landscape where authoritative DNS servers might be accessible only via specific network protocols . At the same time, DNS resolvers may only be able to access the Internet via either IPv4 or IPv6. This poses a challenge for such resolvers because they may encounter names for which queries must be directed to authoritative DNS servers with which they do not share an IP version during the name resolution process. was initially written at a time when IPv6 deployment was not widespread, focusing primarily on maintaining name space continuity within the IPv4 landscape. Two decades later, IPv6 is not only widely deployed but also becoming the de facto standard in many areas. This document seeks to expand the scope of RFC3901 by recommending IPv6 connectivity for authoritative DNS servers, as well as recursive and stub DNS resolvers. This document provides guidance on:

IP version related name space fragmentation and best-practices for avoiding it.
Guidelines for configuring authoritative DNS servers for zones.
Guidelines for operating recursive DNS resolvers.
Guidelines for stub DNS resolvers.

While transitional technologies and dual-stack setups may mitigate some of the issues of DNS resolution in a mixed protocol-version Internet, making DNS data accessible over both IPv4 and IPv6 is the most robust and flexible approach, as it allows resolvers to reach the information they need without requiring intermediary translation or forwarding services which may introduce additional failure cases.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology This document uses DNS terminology as described in . Furthermore, the following terms are used with a defined meaning:

IPv4 name server:: A name server providing DNS services reachable via IPv4. It does not imply anything about what DNS data is served, but means that the name server receives and answers queries over IPv4.
IPv6 name server:: A name server providing DNS services reachable via IPv6. It does not imply anything about what DNS data is served, but means that the name server receives and answers queries over IPv6.
Dual-stack name server:: A name server that is both an "IPv4 name server" and also an "IPv6 name server".

Name Space Fragmentation A resolver that tries to look up a name starts out at the root, and follows referrals until it is referred to a name server that is authoritative for the name. If somewhere down the chain of referrals it is referred to a name server that is, based on the referral, only accessible over a transport which the resolver cannot use, the resolver is unable to continue DNS resolution. If this occurs, the DNS has, effectively, fragmented based on the recursive DNS resolver's and authoritative DNS server's mismatching IP version support. In a mixed IP Internet, name space fragmentation can occur for different reasons. One reason is that DNS zones are consistently configured to support only either IPv4 or IPv6. Another reason is due to misconfigurations that make a zone unresolvable by either IPv4 or IPv6-only resolvers. The latter cases are often hard to identify, as the impact of misconfigurations for only one IP version (IPv4 or IPv6) may be hidden in a dual-stack setting. In the worst case, a specific name may only be resolvable via dual-stack enabled resolvers.

Misconfigurations Causing IP Version Related Name Space Fragmentation Even when an administrator assumes that they have enabled support for a specific IP version on their authoritative DNS server, various misconfigurations may break the DNS delegation chain of a zone for that protocol and prevent any of its records from resolving for clients only supporting that IP version. These misconfigurations can be kept hidden if most clients can successfully fall back to the other IP version. The following name related misconfigurations can cause broken delegation for one IP version:

No A/AAAA records for NS names:: If all of the NS records for a zone in their parent zone have either only A records or only AAAA records, then resolution via the other IP version is not possible.
Missing GLUE:: If the name from an NS record for a zone is in-domain, i.e., the name is within the zone or below, a parent zone must contain both IPv4 and IPv6 GLUE records, i.e., a parent must serve the corresponding A and AAAA records as ADDITIONAL data when returning the NS record(s) as the referral response .
No A/AAAA record for in-domain NS:: If the parent provides GLUE records for both IP versions but the child zone itself lacks corresponding A or AAAA records for its in-domain name server names, resolution via the missing IP version will fail during delegation revalidation .
Zone of sibling domain NSes not resolving:: If the name from an NS record for a zone is sibling domain, the corresponding zone must be resolvable via the IP version in question as well. It is insufficient if the name pointed to by the NS record has an associated A or AAAA record correspondingly.
Parent zone not resolvable via one IP version:: For a zone to be resolvable via an IP version the parent zones up to the root zone must be resolvable via that IP version as well. Any zone not resolvable via the concerned IP version breaks the delegation chain for all its children.

The above misconfigurations are not mutually exclusive. Furthermore, any of the misconfigurations above may not only materialize via a missing Resource Record (RR) but also via an RR providing the IP address of a name server that is not configured to answer queries via that IP version .

Network Conditions Causing IP Version Related Name Space Fragmentation In addition to explicit misconfigurations in the served DNS zones, network conditions may also influence a resolver's ability to resolve names in a zone. The most common issue here are packets requiring fragmentation given a reduced path MTU (PMTU) and MTU blackholes, i.e., packets being dropped on-path due to exceeding the MTU of the link to the next-hop without the sender being notified. This can manifest in the following way:

DNS-over-UDP packets requiring fragmentation: When using EDNS(0) to communicate support for DNS messages larger than 512 octets via traditional DNS-over-UDP transport according to RFC1035 , an IP packet carrying a DNS response may exceed the PMTU for the path to a resolver. If an authoritative DNS server does not follow , i.e., honors EDNS(0) sizes larger than 1232 octets, it will try to fragment the packet according to the discovered PMTU. Such packets mostly occur for DNSKEY responses with DNSSEC . In general, DNS servers SHOULD follow RFC9715 , which provides additional guidance on preventing fragmentation by ensuring that the maximum DNS/UDP payload size does not exceed 1400 octets. This can be accomplished by setting a corresponding EDNS(0) size, with most implementations using a lower EDNS(0) size of 1232 octets following , to ensure that generated packets always fit into lower bound of the IPv6 MTU of 1280, as defined in . Hence, DNS servers MAY opt to set an EDNS(0) size of 1232 octets following . Additionally, DNS servers MAY opt to explicitly not rely on path MTU discovery or PLPMTUD , by instead using IPV6_USE_MIN_MTU=1 from RFC3542 to avoid the need to perform path MTU discovery.
DNS-over-TCP packets requiring fragmentation: If DNS resolution over UDP fails, or if a packet exceeds the communicated EDNS(0) size, a resolver should fall back to DNS resolution over TCP. However, similar to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU blackholes, especially on IPv6, if PMTUD does not work, if the MSS honored by the authoritative DNS server leads to IP packets exceeding the PMTU. In that case, similar to the case of DNS-over-UDP, DNS resolution will time out when the recursive DNS resolver did not receive a response in time. does not provide explicit guidance on mitigating this issue. However, transfering the guidance from , setting an MSS of 1388 octets would reduce the impact of this issue. It is therefore RECOMMENDED that DNS servers set an MSS of no more than 1388 octets for TCP connections. Similarly, aligned with the recommendations of the , DNS servers MAY ensure that a total packet size of 1280 octets is not exceeded by setting an MSS of 1220 octets. Additionally, DNS servers MAY opt to set IPV6_USE_MIN_MTU=1 from RFC3542 .
Broken IPv6 Connectivity at the Resolver: Similar to authoritative servers, (stub) recursive resolvers may face broken IPv6 connectivity, e.g., if a client has been assigned a global unicast IPv6 address, but IPv6 traffic is not routed on the resolver's network. Furthermore, broken IPv6 connectivity may be encountered when IPv4-IPv6 transition technologies, e.g., NAT64 on IPv6-mostly networks , or NAT64 connectivity discovered through PREF64 or DNS64 on IPv6-only networks are in use. There, the synthesized IPv6 addresses used in 464XLAT encounter additional PMTU fluctuation due to the difference in header size between IPv4 and IPv6.

Reasons for Intentional IP Version Related Name Space Fragmentation Intentional IP related name space fragmentation occurs if an operator consciously decides not to deploy IPv4 or IPv6 for a part of the resolution chain. Most commonly, this is realized by intentionally not listing A/AAAA records for NS names. At the time of writing, the share of zones not resolvable via IPv4 is negligible, while a little less than 40% of zones are not resolvable via IPv6 . However, as IPv4 exhaustion progresses, IPv6 adoption will have to increase.

Policy Based Avoidance of Name Space Fragmentation With the final exhaustion of IPv4 pools in RIRs, e.g., , and the progressing deployment of IPv6, IPv4 and IPv6 have become comparably relevant. Yet, while we now observe the first zones becoming exclusively IPv6 resolvable, we also still see a major portion of zones solely relying on IPv4 . Hence, at the moment, dual stack connectivity is instrumental to be able to resolve zones and avoid name space fragmentation. Having zones served only by name servers reachable via one IP version would fragment the DNS. Hence, we need to find a way to avoid this fragmentation. The recommended approach to maintain name space continuity is to use administrative policies, as described in this section.

Guidelines for Authoritative DNS Server Configuration It is usually recommended that DNS zones contain at least two name servers, which are geographically diverse and operate under different routing policies . To reduce the chance of DNS name space fragmentation, it is RECOMMENDED that at least two name servers for a zone are dual stack name servers. Specifically, this means that the following minimal requirements SHOULD be implemented for a zone:

IPv4 adoption:: Every DNS zone SHOULD be served by at least one IPv4-reachable authoritative DNS server to maintain name space continuity. The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) MUST NOT rely on IPv6 connectivity being available. As we acknowledge IPv4 scarcity, operators MAY opt not to provide DNS services via IPv4, if they can ensure that all clients expected to resolve this zone do support DNS resolution via IPv6.
IPv6 adoption:: Every DNS zone SHOULD be served by at least one IPv6-reachable authoritative DNS server to maintain name space continuity. To avoid reachability issues, authoritative DNS servers SHOULD use native IPv6 addresses instead of IPv6 addresses synthesized using IPv6 transition technologies for receiving queries. The delegation configuration (Resolution of the parent, resolution of sibling domain names, GLUE) MUST NOT rely on IPv4 connectivity being available.
Consistency:: Both IPv4 and IPv6 transports should serve identical DNS data to ensure a consistent resolution experience across different network types.
Avoiding IP Fragmentation:: IP fragmentation has been reported to be fragile . Furthermore, IPv6 transition technologies can introduce unexpected MTU breaks, e.g., when NAT64 is used . Therefore, IP fragmentation SHOULD be avoided by following guidance on maximum DNS payload sizes and providing TCP fall-back options . Furthermore, similar to the guidance in , it is RECOMMENDED that authoritative DNS servers sets an MSS of 1220 in TCP sessions carrying DNS responses.

To prevent name space fragmentation, zone validation processes SHOULD ensure that:

There is at least one IPv4 address record and one IPv6 address record available for the name servers of any child delegation within the zone.
The zone's authoritative servers follow for avoiding fragmentation on DNS-over-UDP.
The zone's authoritative servers support DNS-over-TCP .
The zone's authoritative servers can be reached via IPv4 and IPv6 when performing DNS resolution via IPv4-only and IPv6-only networks respectively.

Guidelines for Recursive DNS Resolvers Every recursive DNS resolver SHOULD be dual stack. While the zones that IPv6-only recursive DNS resolvers can resolve are growing, they do not yet cover all zones. Hence, a recursive DNS resolver MAY be IPv6-only, if it uses a transition mechanism that allows it to also query IPv4-only authoritative DNS servers, or uses a configuration where it forwards queries failing IPv6-only DNS resolution to a recursive DNS resolver that is able to perform DNS resolution over IPv4. For example, if a recursive DNS resolver is aware of a PREF64 to use for NAT64 , either through static configuration or by discovering it , it MAY synthesize IPv6 addresses for remote authoritative DNS servers. Similarly, a recursive DNS resolver MAY be IPv4-only, if it uses a configuration where such resolvers forward queries failing IPv4-only DNS resolution to a recursive DNS resolver that is able to perform DNS resolution over IPv6. Finally, when responding to recursive queries sent by stub DNS resolvers, a DNS resolver SHOULD follow the above guidance for communication between authoritative DNS servers and recursive DNS resolvers analogously.

Guidelines for DNS Stub Resolvers Contrary to authoritative DNS servers and recursive DNS resolvers, stub DNS resolvers are more likely to find themselves in either an IPv6-mostly or IPv4-only environment, as they are usually run on end-hosts / clients. Furthermore, a stub DNS resolver has to rely on recursive DNS servers discovered for the local network, e.g., using DHCPv4 , DHCPv6 , and/or SLAAC . In that case, the stub resolver may obtain multiple different IPv4 and IPv6 DNS resolver addresses to use. To prioritize different IPv4 and IPv6 DNS resolver addresses, a stub resolver SHOULD follow . However, a stub DNS resolver SHOULD NOT utilize synthesized addresses if it is able to identify them as such, e.g., by having discovered the PREF64 in use for the network . When providing multiple possible DNS servers to stub resolvers, operators SHOULD consider that various implementations can only configure a small set of possible DNS resolvers, e.g., only up to three for libc, and additional resolvers provided may be ignored by clients.

Security Considerations The guidelines described in this memo introduce no new security considerations into the DNS protocol. Recommendations for recursive and stub resolvers rely on a correctly discovered PREF64. Security issues may materialize if an incorrect PREF64 is used. Hence, guidance from on securely discovering PREF64 SHOULD be followed.

IANA Considerations This document requests IANA to update its technical requirements for authoritative DNS servers to require both IPv4 and IPv6 addresses for each authoritative server .

Acknowledgments Valuable input for this draft was provided by: Bob Harold, Andreas Schulze, Tommy Jensen, Nick Buraglio, Jen Linkova, Tim Chown, Brian E Carpenter, Tom Petch, Philipp S. Tiesel, Mark Andrews, Stefan Ubbink, Joey Abley, Gorry Fairhurst, Paul Vixie, Lorenzo Colitti, David Farmer Thank you for reading this draft.