| Internet-Draft | 3901bis | April 2025 |
| Yamamoto & Fiebig | Expires 9 October 2025 | [Page] |
This memo provides guidelines and documents Best Current Practice for operating authoritative DNS servers as well as recursive and stub DNS resolvers, given that queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document expands on RFC 3901 by recommending that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance on recursive DNS resolver selection for stub DNS resolvers.¶
This document obsoletes RFC3901. (if approved)¶
This note is to be removed before publishing as an RFC.¶
Source for this draft and an issue tracker can be found at https://github.com/ietf-wg-dnsop/draft-ietf-dnsop-3901bis.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 9 October 2025.¶
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Despite IPv6 being first discussed in the mid-1990s [RFC1883], consistent deployment throughout the whole Internet has not yet been accomplished [RFC9386]. Hence, today, the Internet is a mixture of IPv4, dual-stack (networks connected via both IP versions), and IPv6 networks.¶
This creates a complex landscape where authoritative DNS servers might be accessible only via specific network protocols [V6DNSRDY-23]. 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.¶
[RFC3901] was initially written at a time when IPv6 deployment was not widespread, focusing primarily on maintaining namespace continuity within the IPv4 landscape. Now, nearly two decades later, with IPv6 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 compatibility for authoritative DNS servers, as well as recursive and stub DNS resolvers.¶
In this document, we discuss:¶
IP version related namespace 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.¶
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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses DNS terminology as described in [RFC9499]. Furthermore, the following terms are used with a defined meaning:¶
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, 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.¶
With the final exhaustion of IPv4 pools in RIRs, e.g., [RIPEV4], and the progressing deployment of IPv6, there no longer is a "preferred" IP version. 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 [V6DNSRDY-23]. 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.¶
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 server 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.¶
If a recursive DNS resolver runs in a network that uses XLAT [RFC6877], and the recursive DNS resolver is aware of the used PREF64 [RFC6146], it SHOULD synthesize mapped IPv6 addresses for remote authoritative DNS servers directly for DNS resolution, instead of relying on the socket translation layer of the operating system. Additionally, the PREF64 in use MAY also be statically configured for the DNS resolver.¶
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.¶
In general, DNS Stub Resolvers SHOULD follow the same guidance as outlined for recursive DNS resolvers when they are deployed to a dual-stack network not using IPv4-IPv6 transition techniques. 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.¶
For IPv4 only environments, a stub DNS resolver has to rely on the provided recursive DNS server following guidance in this document. However, in an IPv6 mostly scenario, the environment might appear similar to a dual-stack scenario, and the host running the stub DNS resolver may receive multiple IPv4 and IPv6 addresses for possible DNS resolvers to use via different protocols (DHCPv4, DHCPv6, SLAAC).¶
Hence, when a host running a stub DNS resolver receives addresses for IPv4 and IPv6 recursive DNS resolver to use, it SHOULD prioritize reachable IPv6 recursive DNS resolvers. If the host is aware of a PREF64 being used, it SHOULD NOT use IPv4 recursive DNS resolvers for which it also received the corresponding mapped address in the PREF64, but instead SHOULD only use the supplied IPv6 address. Additionally, if the host receives multiple IPv6 reachable recursive DNS resolvers and is aware of a PREF64 being in use, it SHOULD prioritize recursive DNS resolvers outside the PREF64.¶
The guidelines described in this memo introduce no new security considerations into the DNS protocol or associated operational scenarios.¶
This document requests IANA to update its technical requirements for authoritative DNS servers to require both IPv4 and IPv6 addresses for each authoritative server [IANANS].¶
Valuable input for this draft was provided by: Bob Harold, Andreas Schulze, Tommy Jensen, Nick Buraglio, Jen Linkova, Tim Chown, Brian E Carpenter¶
Thank you for reading this draft.¶