| Internet-Draft | 3901bis | December 2025 |
| Momoka & Fiebig | Expires 18 June 2026 | [Page] |
This document 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 recommends that authoritative DNS servers as well as recursive DNS resolvers support both IPv4 and IPv6. It furthermore provides guidance for how recursive DNS resolvers should select upstream DNS servers, if both native and IPv4-embedded IPv6 addresses are available.¶
This document obsoletes RFC 3901.¶
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 18 June 2026.¶
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 since the mid-1990s [RFC2460], consistent deployment throughout the whole Internet has not yet been accomplished [RFC9386]. Hence, the Internet still consists of IPv4-only, dual-stack (networks supporting both IP address families), and IPv6-only 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 connectivity. This poses a challenge for such resolvers because they may receive queries for names that have authoritative DNS servers which do not support the same IP address family as the resolver.¶
[RFC3901] 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 (mobile and access networks, data center underlays, etc.). This document expands 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 address family 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 transition and co-existence setups may mitigate some of the DNS resolution issues in a mixed IP address family Internet, making DNS data accessible over both IPv4 and IPv6 is the most robust and flexible approach. This approach allows resolvers to retrieve the information they need without requiring intermediary translation or encapsulation services which may introduce additional failure cases.¶
Refer to Appendix A for an overview of main changes since [RFC3901].¶
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 set that is authoritative for the name. If it is referred to a name server set that, based on the referral, only contains name servers that are exclusively reachable via an IP address family that the resolver does not support, 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 address family support.¶
With the deployment of both IPv4 and IPv6, 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-only or IPv6-only resolvers. The latter cases are often hard to identify, as the impact of misconfigurations for only one IP address family (IPv4 or IPv6) may be hidden in a dual-stack setting. In the worst case (i.e., requiring both IP address families to be fully supported by a resolver), a specific name may only be resolvable via dual-stack enabled resolvers.¶
With the final exhaustion of IPv4 address pools in RIRs, e.g., [RIPEV4], and the progressing deployment of IPv6, IPv4 and IPv6 have become comparably relevant. Yet, while it is observed that the first zones becoming exclusively IPv6 resolvable, there is still a major portion of zones solely relying on IPv4 [V6DNSRDY-23]. Hence, dual-stack connectivity is still instrumental to be able to resolve zones and avoid name space fragmentation.¶
Having zones served only by name servers reachable via one IP address family would fragment the DNS. Hence, the need for 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 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. If a recursive DNS resolver is aware of a PREF64 to use for NAT64 [RFC6146], either through static configuration or by discovering it (e.g., [RFC8781]), 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 on fragmentation avoidance (Section 4.1) for communication between authoritative DNS servers and recursive DNS resolvers analogously.¶
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 [RFC2131], DHCPv6 [RFC8415], and/or router advertisements [RFC8106]. 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 [RFC6724]. However, a stub DNS resolver SHOULD NOT utilize IPv4-embedded IPv6 addresses if it is able to identify them as such, e.g., by having discovered the PREF64 in use for the network [RFC8781].¶
When providing multiple DNS servers to stub resolvers, network operators SHOULD consider that various implementations can only configure a small set of possible DNS resolvers, e.g., only up to three for libc [MAN], and additional resolvers provided may be ignored by clients.¶
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 [RFC9872] on securely discovering PREF64 SHOULD be followed.¶
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, Tom Petch, Philipp S. Tiesel, Mark Andrews, Stefan Ubbink, Joe Abley, Gorry Fairhurst, Paul Vixie, Lorenzo Colitti, David Farmer, Pieter Lexis, Ralf Weber, Philip Homburg, Marco Davids, Mohamed Boucadair¶
Thank you for reading this draft.¶
The authors furthermore express their thanks towards the authors of [RFC3901], Alain Durand and Johan Ihren, and provide their original acknowledgements verbatim below:¶
This document is the result of many conversations that happened in the DNS community at IETF and elsewhere since 2001. During that period of time, a number of Internet drafts have been published to clarify various aspects of the issues at stake. This document focuses on the conclusion of those discussions.¶
The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document.¶
The following changes have been made to the guidance published in [RFC3901]:¶
Expanded the terminology section, also taking considerations from [RFC9499] into account.¶
Expanded namespace fragmentation, independently discussing IP address family related namespace fragmentation, network condition based namespace fragmentation, and intentional namespace fragmentation.¶
Now recommends the use of IPv4 and IPv6 for authoritative DNS servers, instead of leaving IPv6 optional.¶
Now recommends testing IPv4 and IPv6 resolvability when delegating zones, instead of only testing IPv4 resolvability.¶
Added guidance on handling IP layer fragmentation.¶
Added guidance for IP address family handling for recursive and stub resolvers.¶