dnsop Momoka Internet-Draft WIDE Project Obsoletes: 3901 (if approved) T. Fiebig Intended status: Best Current Practice MPI-INF Expires: 18 June 2026 15 December 2025 DNS IPv6 Transport Operational Guidelines draft-ietf-dnsop-3901bis-09 Abstract 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. Discussion Venues 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. Status of This Memo 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. Momoka & Fiebig Expires 18 June 2026 [Page 1] Internet-Draft 3901bis December 2025 Copyright Notice 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Name Space Fragmentation . . . . . . . . . . . . . . . . . . 4 3.1. Misconfigurations Causing IP Address Family Related Name Space Fragmentation . . . . . . . . . . . . . . . . . . . 5 3.2. Network Conditions Causing IP Address Family Related Name Space Fragmentation . . . . . . . . . . . . . . . . . . . 6 3.3. Reasons for Intentional IP Address Family Related Name Space Fragmentation . . . . . . . . . . . . . . . . . . . 8 4. Policy Based Avoidance of Name Space Fragmentation . . . . . 8 4.1. Guidelines for Authoritative DNS Server Configuration . . 9 4.2. Guidelines for Recursive DNS Resolvers . . . . . . . . . 10 4.3. Guidelines for DNS Stub Resolvers . . . . . . . . . . . . 10 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . . 12 Informative References . . . . . . . . . . . . . . . . . . . . 13 Appendix A. Changes Since RFC3901 . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction 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. Momoka & Fiebig Expires 18 June 2026 [Page 2] Internet-Draft 3901bis December 2025 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]. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Momoka & Fiebig Expires 18 June 2026 [Page 3] Internet-Draft 3901bis December 2025 2. Terminology This document uses DNS terminology as described in [RFC9499]. Furthermore, the following terms are used with a defined meaning: IPv4 name server: A name server providing either authoritative or recrusive 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 either authoritative or recursive 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 an "IPv6 name server". 3. 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 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. Momoka & Fiebig Expires 18 June 2026 [Page 4] Internet-Draft 3901bis December 2025 3.1. Misconfigurations Causing IP Address Family Related Name Space Fragmentation Even when an administrator assumes that they have enabled support for a specific IP address family on their authoritative DNS server, various misconfigurations may break the DNS delegation chain of a zone for that IP address family and prevent any of its records from resolving for clients only supporting that IP address family. These misconfigurations can be kept hidden if most clients can successfully fall back to the other IP address family. The following name related misconfigurations can cause broken delegation for one IP address family: No A/AAAA records for NS names: If all of the NS resource records (RR) for a zone in their parent zone have either only A RRs or only AAAA RRs, then resolution via the other IP address family 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 needs to contain both IPv4 and IPv6 glue records. A parent needs to serve the corresponding A and AAAA RRs in the additional section when returning the NS RRs as the referral response [RFC9471]. No A/AAAA RR for in-domain NS: If the parent provides glue records for both IP address families but the child zone itself lacks corresponding A or AAAA RRs for its in-domain NS' names, resolution via the missing IP address family will fail during delegation revalidation (see, e.g., [I-D.ietf-dnsop-ns-revalidation]). Zone of sibling domain NSes not resolving: If the name from an NS RR for a zone is sibling domain, the corresponding zone needs to be resolvable via the IP address family in question as well. It is insufficient if the name pointed to by the NS RR has an associated A or AAAA RR correspondingly. Parent zone not resolvable via one IP address family: For a zone to be resolvable via an IP address family the parent zones up to the root zone needs to be resolvable via that IP address family as well. Any zone not resolvable via the concerned IP address family breaks the delegation chain for all its children. The above misconfigurations are not mutually exclusive. Momoka & Fiebig Expires 18 June 2026 [Page 5] Internet-Draft 3901bis December 2025 Furthermore, any of the misconfigurations above may not only materialize via a missing RR but also via an RR providing the IP address of a name server that is not configured to answer queries via that IP address family [V6DNSRDY-23]. 3.2. Network Conditions Causing IP Address Family 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 are packets requiring fragmentation given a reduced path MTU (PMTU) and MTU discards, 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 ways: DNS-over-UDP packets requiring fragmentation When using EDNS(0) to communicate support for DNS messages larger than 512 octets [RFC6891] via conventional 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 [RFC9715], 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 [RFC4034]. 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 [DNSFlagDay2020], to ensure that generated packets always fit into lower bound of the IPv6 MTU of 1280, as defined in [RFC8200]. Hence, DNS servers MAY opt to set an EDNS(0) size of 1232 octets following [DNSFlagDay2020]. Additionally, DNS servers MAY opt to explicitly not rely on path MTU discovery [RFC4821] or PLPMTUD [RFC8899]. It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from [RFC3542] to avoid the need to perform PMTU discovery. DNS-over-TCP packets requiring fragmentation Momoka & Fiebig Expires 18 June 2026 [Page 6] Internet-Draft 3901bis December 2025 A resolver can for various reasons also initiate connections via TCP for resolution to an authoritative server. However, similar to the case of DNS-over-UDP, DNS-over-TCP may encounter MTU discards, 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. [RFC9715] does not provide explicit guidance on mitigating this issue. However, transferring the guidance from [RFC9715], setting an MSS of 1388 octets would reduce the impact of this issue. Hence, DNS servers MAY set an MSS of no more than 1388 octets for TCP connections. Similarly, aligned with the recommendations of the [DNSFlagDay2020], 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 not rely on PMTU discovery. It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from [RFC3542]. Broken IP Connectivity at the Resolver Similar to authoritative servers, (stub) recursive resolvers may face broken IP connectivity for either IPv4 or IPv6: IPv4 connectivity for a DNS resolver may experience issues, e.g., if the resolver is deployed behind a Carrier Grade NAT (CGN) [RFC6888] that implements strict timeouts on active sessions, or limits the number of available TCP and UDP ports numbers for connections below the number required by the multiple connections necessary during recursive DNS resolution. Similarly, [RFC1918] addressing may be in use on the resolver, while address translation is not performed, or, similar to the case for IPv6, when the DNS resolver has a global IPv4 address, but that address is not forwarded on the resolver's network. IPv6 connectivity for a DNS resolver may experience issues, if, e.g., a client has been assigned a global unicast IPv6 address, but IPv6 traffic is not forwarded on the resolver's network. Similarly, IPv6 connectivity can experience issues when IPv4-IPv6 transition technologies like NAT64 [RFC6146] on IPv6-mostly networks [RFC9313] are in use, where the use of NAT64 can be, e.g., discovered through PREF64 in router advertisments [RFC8781] or DNS64 [RFC7050]. There, the synthesized IPv6 addresses used in, e.g., 464XLAT [RFC6877] encounter additional PMTU fluctuation due to the difference in header size between IPv4 and IPv6, possibly impacting DNS resolution. Momoka & Fiebig Expires 18 June 2026 [Page 7] Internet-Draft 3901bis December 2025 Note: This document only explicitly discusses DNS-over-TCP and DNS- over-UDP. However, several other transport methods between recursive and authoritative DNS severs exist, including DNS over various encrypted transports. Some of these technologies provide additional mechanisms for preventing the impact of a reduced PMTU or MTU discards. Guidance in this document focuses on IP address family support, and questions of the underlying transport protocol (TCP or UDP). If DNS servers use an additional protocol layer, e.g., DNS- over-TLS [RFC7858] or DNS-over-QUIC [RFC9250], for their communication, and that protocol supports additional measures to prevent fragmentation on the IP layer related issues, these measures SHOULD be used for the connection. Otherwise, if the protocol is not resilient to IP layer fragmentation related issues by default, the above guidance for TCP and UDP based connections SHOULD be applied analogously. 3.3. Reasons for Intentional IP Address Family 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 RRs 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 [V6DNSRDY-23]. However, as IPv4 address exhaustion progresses, IPv6 adoption is expected to increase. 4. Policy Based Avoidance of Name Space Fragmentation 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. Momoka & Fiebig Expires 18 June 2026 [Page 8] Internet-Draft 3901bis December 2025 4.1. 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 [IANANS]. 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. Given the IPv4 address 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 IPv4-converted IPv6 addresses 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 [RFC8900]. Furthermore, IPv6 transition technologies can introduce unexpected MTU breaks (e.g., when NAT64 is used (Section 7 of [RFC7269])). Therefore, IP fragmentation SHOULD be avoided by following guidance on maximum DNS payload sizes [RFC9715] and providing TCP fall back options [RFC7766]. Furthermore, similar to the guidance in [RFC9715], authoritative DNS servers MAY set an MSS of either 1388 (analogous to [RFC9715]) or 1220 (analogous to the [DNSFlagDay2020] suggestions) in TCP sessions carrying DNS responses. To prevent name space fragmentation, zone validation processes SHOULD ensure that: Momoka & Fiebig Expires 18 June 2026 [Page 9] Internet-Draft 3901bis December 2025 * 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 [RFC9715] for avoiding fragmentation on DNS-over-UDP. * The zone's authoritative servers support DNS-over-TCP [RFC9210]. * The zone's authoritative servers can be reached via IPv4 and IPv6 when performing DNS resolution via IPv4-only and IPv6-only networks respectively. 4.2. 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. 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. 4.3. 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 [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. Momoka & Fiebig Expires 18 June 2026 [Page 10] Internet-Draft 3901bis December 2025 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. 5. 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 [RFC9872] on securely discovering PREF64 SHOULD be followed. 6. 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 [IANANS]. 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, 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. Momoka & Fiebig Expires 18 June 2026 [Page 11] Internet-Draft 3901bis December 2025 The authors would like to acknowledge the role of Pekka Savola in his thorough review of the document. References Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, . [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, . [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, DOI 10.17487/RFC6891, April 2013, . [RFC7766] Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and D. Wessels, "DNS Transport over TCP - Implementation Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . [RFC8899] Fairhurst, G., Jones, T., Tüxen, M., Rüngeler, I., and T. Völker, "Packetization Layer Path MTU Discovery for Datagram Transports", RFC 8899, DOI 10.17487/RFC8899, September 2020, . Momoka & Fiebig Expires 18 June 2026 [Page 12] Internet-Draft 3901bis December 2025 [RFC9210] Kristoff, J. and D. Wessels, "DNS Transport over TCP - Operational Requirements", BCP 235, RFC 9210, DOI 10.17487/RFC9210, March 2022, . [RFC9471] Andrews, M., Huque, S., Wouters, P., and D. Wessels, "DNS Glue Requirements in Referral Responses", RFC 9471, DOI 10.17487/RFC9471, September 2023, . Informative References [DNSFlagDay2020] "DNS flag day 2020", . [I-D.ietf-dnsop-ns-revalidation] Huque, S., Vixie, P. A., and W. Toorop, "Delegation Revalidation by DNS Resolvers", Work in Progress, Internet-Draft, draft-ietf-dnsop-ns-revalidation-11, 19 October 2025, . [IANANS] IANA, "Technical requirements for authoritative name servers", . [MAN] Linux, "resolv.conf(5) — Linux manual page", 2025, . [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, . [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, DOI 10.17487/RFC2131, March 1997, . [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, . [RFC3542] Stevens, W., Thomas, M., Nordmark, E., and T. Jinmei, "Advanced Sockets Application Program Interface (API) for IPv6", RFC 3542, DOI 10.17487/RFC3542, May 2003, . Momoka & Fiebig Expires 18 June 2026 [Page 13] Internet-Draft 3901bis December 2025 [RFC3901] Durand, A. and J. Ihren, "DNS IPv6 Transport Operational Guidelines", BCP 91, RFC 3901, DOI 10.17487/RFC3901, September 2004, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, . [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, . [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, DOI 10.17487/RFC6877, April 2013, . [RFC6888] Perreault, S., Ed., Yamagata, I., Miyakawa, S., Nakagawa, A., and H. Ashida, "Common Requirements for Carrier-Grade NATs (CGNs)", BCP 127, RFC 6888, DOI 10.17487/RFC6888, April 2013, . [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, DOI 10.17487/RFC7050, November 2013, . [RFC7269] Chen, G., Cao, Z., Xie, C., and D. Binet, "NAT64 Deployment Options and Experience", RFC 7269, DOI 10.17487/RFC7269, June 2014, . [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, . Momoka & Fiebig Expires 18 June 2026 [Page 14] Internet-Draft 3901bis December 2025 [RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, . [RFC8781] Colitti, L. and J. Linkova, "Discovering PREF64 in Router Advertisements", RFC 8781, DOI 10.17487/RFC8781, April 2020, . [RFC8900] Bonica, R., Baker, F., Huston, G., Hinden, R., Troan, O., and F. Gont, "IP Fragmentation Considered Fragile", BCP 230, RFC 8900, DOI 10.17487/RFC8900, September 2020, . [RFC9250] Huitema, C., Dickinson, S., and A. Mankin, "DNS over Dedicated QUIC Connections", RFC 9250, DOI 10.17487/RFC9250, May 2022, . [RFC9313] Lencse, G., Palet Martinez, J., Howard, L., Patterson, R., and I. Farrer, "Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS)", RFC 9313, DOI 10.17487/RFC9313, October 2022, . [RFC9386] Fioccola, G., Volpato, P., Palet Martinez, J., Mishra, G., and C. Xie, "IPv6 Deployment Status", RFC 9386, DOI 10.17487/RFC9386, April 2023, . [RFC9499] Hoffman, P. and K. Fujiwara, "DNS Terminology", BCP 219, RFC 9499, DOI 10.17487/RFC9499, March 2024, . [RFC9715] Fujiwara, K. and P. Vixie, "IP Fragmentation Avoidance in DNS over UDP", RFC 9715, DOI 10.17487/RFC9715, January 2025, . [RFC9872] Buraglio, N., Jensen, T., and J. Linkova, "Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis", RFC 9872, DOI 10.17487/RFC9872, September 2025, . [RIPEV4] RIPE NCC, "The RIPE NCC has run out of IPv4 Addresses", November 2019, . Momoka & Fiebig Expires 18 June 2026 [Page 15] Internet-Draft 3901bis December 2025 [V6DNSRDY-23] Streibelt, F., Sattler, P., Lichtblau, F., Hernandez- Gañán, C., Gasser, O., and T. Fiebig, "How Ready is DNS for an IPv6-Only World?", March 2023, . Appendix A. Changes Since [RFC3901] 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. Authors' Addresses Momoka Yamamoto WIDE Project Email: momoka.my6@gmail.com Tobias Fiebig Max-Planck-Institut fuer Informatik Campus E14 66123 Saarbruecken Germany Phone: +49 681 9325 3527 Email: tfiebig@mpi-inf.mpg.de Momoka & Fiebig Expires 18 June 2026 [Page 16]