Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments WIDE Project
momoka.my6@gmail.com
Max-Planck-Institut fuer Informatik
Campus E14 Saarbruecken 66123 Germany +49 681 9325 3527 tfiebig@mpi-inf.mpg.de
OPS dnsop DNS IPv6 This document provides guidelines and documents best current practice for operating authoritative DNS servers, recursive resolvers, and stub resolvers in a mixed IPv4/IPv6 environment. This document recommends that both authoritative DNS servers and recursive resolvers support IPv4 and IPv6. It also provides guidance on how recursive DNS resolvers should select upstream DNS servers, including when IPv4-embedded IPv6 addresses are available. This document obsoletes RFC 3901.
Status of This Memo This memo documents an Internet Best Current Practice. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at .
Copyright Notice Copyright (c) 2026 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 () 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
  • .  Introduction
  • .  Terminology
    • .  Requirements Language
  • .  Name Space Partitioning
    • .  Misconfigurations Causing Name Space Partitioning Due to IP Address Family Support
    • .  Network Conditions Causing Name Space Partitioning Due to IP Address Family Support
    • .  Reasons for Intentional Name Space Partitioning Due to IP Address Family Support
  • .  Policy-Based Avoidance of Name Space Partitioning
    • .  Guidelines for Authoritative DNS Server Configuration
    • .  Guidelines for Recursive DNS Resolvers
    • .  Guidelines for DNS Stub Resolvers
  • .  Security Considerations
  • .  IANA Considerations
  • .  References
    • .  Normative References
    • .  Informative References
  • .  Changes Since RFC 3901
  • Acknowledgments
  • Authors' Addresses
Introduction Despite IPv6 being first discussed in the mid-1990s , consistent deployment throughout the whole Internet has not yet been accomplished . 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 . 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 whose authoritative DNS servers do not support the same IP address family as the resolver itself. was written at a time when IPv6 deployment was not widespread and focuses primarily on maintaining name space continuity within the IPv4 landscape. Two decades later, IPv6 is widely deployed and is also becoming the de facto standard in many areas, such as mobile and access networks and data-center underlays. Furthermore, since 2012, IPv6 support being required for all IP-capable nodes has been established as a best current practice . This document broadens the scope of by recommending IPv6 connectivity for authoritative DNS servers, recursive resolvers, and stub resolvers. This document provides:
  • Guidance on name space partitioning due to differences in IP address family support and best practices for avoiding it.
  • Guidelines for configuring authoritative DNS servers for zones.
  • Guidelines for operating recursive DNS resolvers.
  • Guidelines for DNS stub resolvers.
While transition and coexistence 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 for an overview of the main changes since .
Terminology This document uses DNS terminology as described in . Furthermore, the following terms are used with a defined meaning:
IPv4-reachable name server:
A name server that provides either authoritative or recursive DNS services via IPv4. This does not imply anything about the DNS data served but rather indicates that the name server receives and answers queries over IPv4.
IPv6-reachable name server:
A name server that provides either authoritative or recursive DNS services via IPv6. This does not imply anything about the DNS data served but rather indicates that the name server receives and answers queries over IPv6.
Dual-stack name server (or resolver):
A name server (or resolver) that is both IPv4-reachable and IPv6-reachable.
Effective PMTU:
The effective Path Maximum Transmission Unit (PMTU) is the largest IP packet size (in octets) that can successfully traverse a network path from source to destination without requiring fragmentation.
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.
Name Space Partitioning When a resolver looks up a name, it starts at the root and follows referrals until it reaches a name server set that is authoritative for the name. However, if the referrals lead to a name server set that only contains name servers reachable via an IP address family not supported by the resolver, the resolver is unable to continue DNS resolution. If this occurs, the DNS has been effectively partitioned due to mismatching IP address family support between the recursive DNS resolver and the authoritative DNS server. With the deployment of both IPv4 and IPv6, name space partitioning can occur for different reasons. One reason is that DNS zones are consistently configured to support only either IPv4 or IPv6. Another reason is misconfigurations that make a zone unresolvable by either IPv4-only or IPv6-only resolvers. The latter is often hard to identify because the impact of misconfigurations affecting one IP address family (IPv4 or IPv6) may be hidden in a dual-stack setting. In the worst case, where both IP address families must be fully supported by a resolver, a specific name may only be resolvable via dual-stack enabled resolvers.
Misconfigurations Causing Name Space Partitioning Due to IP Address Family Support 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, preventing any of its records from being resolved by clients that only support that IP address family. Such misconfigurations may remain undetected 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 (RRs) 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 .
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 the names of its in-domain NS, resolution via the missing IP address family will fail during delegation revalidation (see, e.g., ).
Zone of sibling domain NSes not resolving:
If the name from an NS RR for a zone is in a 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.
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 need 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. Furthermore, any of the misconfigurations above may materialize not only 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 . Finally, at the time of this writing, addresses (A or AAAA RRs) for a delegation's authoritative name servers are the only type of glue defined for the DNS. In the future, alternative, yet related, delegation systems may be available, where other considerations apply.
Network Conditions Causing Name Space Partitioning Due to IP Address Family Support 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 is silent MTU discards for packets that would require fragmentation to fit a reduced effective PMTU, i.e., packets being dropped on-path when they exceed 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 Extension Mechanisms for DNS (EDNS(0)) to communicate support for DNS messages larger than 512 octets via conventional DNS-over-UDP transport according to , 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 , which provides additional guidance on preventing fragmentation. suggests setting an upper bound for received EDNS(0) sizes of 1400 octets to avoid the need for fragmentation. However, the DNS Flag Day 2020 initiative suggests using an upper bound EDNS(0) size of only 1232 octets, which is also adopted by most implementations. Setting the upper bound at 1232 octets ensures that generated packets do not exceed 1280 octets, i.e., the minimum MTU for IPv6 , which avoids IPv6 host fragmentation by the server. Hence, for clarity, the present document specifically notes that clients MAY use an EDNS(0) size of 1232 octets as well. As an additional precaution or because the DNS implementation in use does not support limiting the effective EDNS(0) size, DNS servers MAY opt to explicitly not rely on Path MTU Discovery (PMTUD) or Packetization Layer Path MTU Discovery (PLPMTUD) . It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from to avoid the need to perform PMTU discovery.
DNS-over-TCP packets requiring fragmentation:
For various reasons, a resolver can 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 if PMTUD is not possible on a given path. This can occur, for example, if PMTUD-related ICMP/ICMPv6 messages are dropped (i.e., cannot be returned to the sender) or if the size communicated in these messages is incorrect (i.e., an on-path device alters the size of packets). Under these conditions, the Maximum Segment Size (MSS) honored by the authoritative DNS server leads to IP packets exceeding the effective PMTU of the path taken by responses. In that case, similar to the case of DNS-over-UDP, DNS resolution will time out when the recursive DNS resolver does not receive a response in time. does not provide explicit guidance on mitigating this issue. recommends that IPv6 nodes implement Path MTU Discovery (PMTUD) in order to discover and take advantage of PMTUs greater than 1280 octets. Usually, when a transport protocol can use PMTU (or PLPMTUD or Datagram PLPMTUD ), this SHOULD be used to determine an effective PMTU. However, DNS generally benefits from low latency, and performing PMTU (or PLPMTUD or Datagram PLPMTUD ) increases the time needed to process a DNS request. This overhead could even lead to DNS requests timing out before the effective PMTU can be established by the server. Furthermore, at the time of writing, most DNS messages fit into less than 1280 octets , which means that the benefits of being able to leverage a larger effective PMTU only affect corner cases, e.g., requests for DNSKEY RRs. Additionally, not having to rely on PMTUD benefits the time budget for DNS, as the time needed for PMTUD could already exceed the timeout budget for DNS resolution, i.e., it could prevent resolution for cases where PMTUD is needed. Hence, DNS servers SHOULD configure the maximum response size to avoid fragmentation or on-path discarding of packets larger than the effective PMTU. For TCP, this can be accomplished by restricting the used MSS, either by the host limiting the MSS on its own or by rewriting the MSS field in packets during a TCP handshake. Therefore, it is RECOMMENDED that DNS servers set a Sender MSS (MSS_S) of no more than 1388 octets for TCP connections. Setting this MSS ensures that packets do not exceed a size of 1448 octets, i.e., the same packet size recommended to avoid fragmentation for DNS-over-UDP packets in . Furthermore, to provide additional clarity similar to the above guidance on UDP, DNS servers MAY ensure that a total packet size of 1280 octets is not exceeded by setting the MSS_S to 1220 octets, as suggested by the DNS Flag Day 2020 initiative . See . As an additional precaution or because the DNS implementation in use does not support limiting the effective MSS size, DNS servers MAY opt to explicitly not rely on PMTUD or PLPMTUD . It can do so, for example, by setting IPV6_USE_MIN_MTU=1 from .
Broken IP connectivity at the resolver:
Similar to authoritative servers, stub and 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) 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, addressing in 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. Also, a resolver may only have received a unique local IPv6 unicast address , which does not allow it to reach global addresses without translation. Similarly, IPv6 connectivity can experience issues when IPv4-IPv6 transition technologies like NAT64 on IPv6-mostly networks are in use, where the use of NAT64 can be, e.g., discovered through PREF64 in Router Advertisements (RAs) or DNS64 . There, the synthesized IPv6 addresses used in 464XLAT (for example) encounter additional PMTU fluctuation due to the difference in header size between IPv4 and IPv6, possibly impacting DNS resolution.
Reasons for Intentional Name Space Partitioning Due to IP Address Family Support Intentional name space partitioning due to IP address family support 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. Based on a 2023 study, 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 address exhaustion progresses, IPv6 adoption is expected to increase.
Policy-Based Avoidance of Name Space Partitioning IPv4 and IPv6 have become comparably relevant with the final exhaustion of IPv4 address pools in Regional Internet Registries (RIRs) (see, e.g., ) and the progressing deployment of IPv6. Yet, while the first zones that are exclusively IPv6 resolvable can now be observed, exclusively IPv4 resolvable zones are considerably more common . Hence, dual-stack connectivity is still instrumental to be able to resolve zones and avoid name space partitioning. Having zones served only by name servers reachable via one IP address family would partition the DNS. Hence, a way to avoid this partitioning is needed. 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 (). Typically, these servers are geographically diverse and operate under different routing policies , as also discussed in, e.g., the IANA requirements for Top-Level Domain (TLD) authoritative name servers . To prevent DNS name space partitioning, at least two IPv4-reachable and two IPv6-reachable name servers MUST be configured for a zone. A single name server that is reachable over both IPv4 and IPv6 counts once per address family. Please note that a name set in an NS RR that has either only an A or AAAA record may add overhead to the resolution process for resolvers only supporting the IP address family for which no corresponding A or AAAA RR is present. When selecting such an authoritative name server during DNS resolution, a query for the missing A or AAAA record would return NODATA, requiring the client to query for the A or AAAA record of another NS RR. To prevent this, it is RECOMMENDED that all names used in NS RRs have an A and AAAA record set. Specifically, the key requirements for a zone are:
IPv4 adoption:
To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv4. Furthermore, the delegation configuration of an NS (resolution of the parent, resolution of sibling domain names, glue) MUST NOT rely on IPv6 connectivity being available.
IPv6 adoption:
To maintain name space continuity, every DNS zone MUST be served by at least two authoritative DNS servers providing services via IPv6. To avoid reachability issues, authoritative DNS servers MUST NOT use IPv4-embedded addresses (including IPv4-Mapped IPv6 addresses and deprecated IPv4-compatible addresses ) for receiving queries. Furthermore, the delegation configuration of an NS (resolution of the parent, resolution of sibling domain names, glue) MUST NOT rely on IPv4 connectivity being available.
Consistency:
Both IPv4 and IPv6 transports MUST serve equivalent 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 reductions in the effective PMTU (e.g., when NAT64 is used ()). Therefore, IP fragmentation SHOULD be avoided by following guidance on maximum DNS payload sizes . Furthermore, as per , DNS-over-TCP MUST be available as a fallback option, instead of relying on fragmented UDP packets. Similar to the guidance in , authoritative DNS servers MAY set an MSS of either 1388 (analogous to ) or 1220 (analogous to the suggestions) in TCP sessions carrying DNS responses.
To prevent name space partitioning, zone validation processes SHOULD ensure that:
  • There are at least two IPv4 address records and two IPv6 address records 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 To ensure robust DNS resolution even when facing name space partitioning, every recursive DNS resolver SHOULD be dual-stack. Exceptions apply if one of the methods to prevent name space partitioning described in this section is in place. 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 dual-stack recursive DNS resolver (i.e., a resolver that is also able to perform DNS resolution over IPv4). If a recursive DNS resolver is aware of a PREF64 to use for NAT64 , either through static configuration or by discovering it (e.g., using the option described in ), 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 dual-stack recursive DNS resolver (i.e., a resolver that is also able to perform DNS resolution over IPv6). Finally, when responding to recursive queries (i.e., a query with the Recursion Desired (RD) bit set ), a DNS resolver SHOULD follow the above guidance on fragmentation avoidance (see ) 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, DNS stub resolvers are more likely to find themselves in either an IPv6-mostly or IPv4-only environment, as they are usually run on end hosts or clients. Furthermore, a DNS stub resolver has to rely on recursive DNS servers discovered for the local network, e.g., using DHCPv4 , DHCPv6 , and/or router advertisements . 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 DNS stub 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 . When providing multiple recursive DNS servers to stub resolvers, network operators have to consider that, at the time of writing, various implementations can only configure a small set of possible DNS resolver addresses, e.g., only up to three for glibc , and additional resolver addresses provided may be non-deterministically ignored by clients. Hence, when providing more than three recursive server addresses to stub resolvers, operators SHOULD ensure that either:
  1. all supplied recursive server IP addresses are from the same address family, based on knowledge as to clients being IPv4-only or IPv6-mostly; or
  2. exactly two IP addresses are from one address family (IPv4 or IPv6) and exactly one is from the other address family.
Furthermore, all supplied resolvers SHOULD be able to perform dual-stack DNS resolution to avoid name space partitioning due to IP address family support.
Security Considerations The guidelines described in this memo introduce no new security considerations into the DNS protocol itself. Nevertheless, corner cases exist where forwarding queries requiring an IP address family for resolution that is not supported by the initial resolver leads to an infinite forwarding loop under the following conditions:
  • Two resolvers handle queries for a set of clients, each of these resolvers supports one and only one address family that is distinct from the address family supported by the other resolver;
  • Both resolvers are configured to forward queries requiring DNS resolution via the IP address family they do not support to the other; and
  • A query for a zone that is not resolvable via IPv4 and not resolvable via IPv6 is received.
In such cases, a query for the non-resolvable zone would be endlessly forwarded between these resolvers. To prevent such cases, single-stack recursive DNS resolvers SHOULD be configured to forward queries they cannot resolve due to lacking support for one address family to dual-stack recursive DNS resolvers. Furthermore, recursive DNS resolvers MUST NOT be configured to forward queries to DNS resolvers that are configured to forward queries to them in the first place. 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. Preventing fragmentation according to the guidance in this document may increase load on DNS servers, as more TCP fallbacks might be required. While measurements have shown this to be (at the time of writing) in the range of 3-5% of connections , operators SHOULD monitor the actual impact on their servers when implementing guidance from this document to detect unexpected load increases early on.
IANA Considerations This document has no IANA actions. However, IANA should consider updating its technical requirements for authoritative DNS servers to require both IPv4 and IPv6 addresses for each authoritative server , in accordance with the processes for reviewing and revising these procedures.
References Normative References Domain names - concepts and facilities This RFC is the revised basic definition of The Domain Name System. It obsoletes RFC-882. This memo describes the domain style names and their used for host address look up and electronic mail forwarding. It discusses the clients and servers in the domain name system and the protocol used between them. Domain names - implementation and specification This RFC is the revised specification of the protocol and format used in the implementation of the Domain Name System. It obsoletes RFC-883. This memo documents the details of the domain name client - server communication. Key words for use in RFCs to Indicate Requirement Levels In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. IP Version 6 Addressing Architecture This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 3513, "IP Version 6 Addressing Architecture". [STANDARDS-TRACK] Packetization Layer Path MTU Discovery This document describes a robust method for Path MTU Discovery (PMTUD) that relies on TCP or some other Packetization Layer to probe an Internet path with progressively larger packets. This method is described as an extension to RFC 1191 and RFC 1981, which specify ICMP-based Path MTU Discovery for IP versions 4 and 6, respectively. [STANDARDS-TRACK] IPv6 Addressing of IPv4/IPv6 Translators This document discusses the algorithmic translation of an IPv6 address to a corresponding IPv4 address, and vice versa, using only statically configured information. It defines a well-known prefix for use in algorithmic translations, while allowing organizations to also use network-specific prefixes when appropriate. Algorithmic translation is used in IPv4/IPv6 translators, as well as other types of proxies and gateways (e.g., for DNS) used in IPv4/IPv6 scenarios. [STANDARDS-TRACK] Default Address Selection for Internet Protocol Version 6 (IPv6) This document describes two algorithms, one for source address selection and one for destination address selection. The algorithms specify default behavior for all Internet Protocol version 6 (IPv6) implementations. They do not override choices made by applications or upper-layer protocols, nor do they preclude the development of more advanced mechanisms for address selection. The two algorithms share a common context, including an optional mechanism for allowing administrators to provide policy that can override the default behavior. In dual-stack implementations, the destination address selection algorithm can consider both IPv4 and IPv6 addresses -- depending on the available source addresses, the algorithm might prefer IPv6 addresses over IPv4 addresses, or vice versa. Default address selection as defined in this specification applies to all IPv6 nodes, including both hosts and routers. This document obsoletes RFC 3484. [STANDARDS-TRACK] Extension Mechanisms for DNS (EDNS(0)) The Domain Name System's wire protocol includes a number of fixed fields whose range has been or soon will be exhausted and does not allow requestors to advertise their capabilities to responders. This document describes backward-compatible mechanisms for allowing the protocol to grow. This document updates the Extension Mechanisms for DNS (EDNS(0)) specification (and obsoletes RFC 2671) based on feedback from deployment experience in several implementations. It also obsoletes RFC 2673 ("Binary Labels in the Domain Name System") and adds considerations on the use of extended labels in the DNS. DNS Transport over TCP - Implementation Requirements This document specifies the requirement for support of TCP as a transport protocol for DNS implementations and provides guidelines towards DNS-over-TCP performance on par with that of DNS-over-UDP. This document obsoletes RFC 5966 and therefore updates RFC 1035 and RFC 1123. Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. Packetization Layer Path MTU Discovery for Datagram Transports This document specifies Datagram Packetization Layer Path MTU Discovery (DPLPMTUD). This is a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). It allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a packet black hole. It can also probe a network path to discover whether the maximum packet size can be increased. This provides functionality for datagram transports that is equivalent to the PLPMTUD specification for TCP, specified in RFC 4821, which it updates. It also updates the UDP Usage Guidelines to refer to this method for use with UDP datagrams and updates SCTP. The document provides implementation notes for incorporating Datagram PMTUD into IETF datagram transports or applications that use datagram transports. This specification updates RFC 4960, RFC 4821, RFC 6951, RFC 8085, and RFC 8261. DNS Transport over TCP - Operational Requirements This document updates RFCs 1123 and 1536. This document requires the operational practice of permitting DNS messages to be carried over TCP on the Internet as a Best Current Practice. This operational requirement is aligned with the implementation requirements in RFC 7766. The use of TCP includes both DNS over unencrypted TCP as well as over an encrypted TLS session. The document also considers the consequences of this form of DNS communication and the potential operational issues that can arise when this Best Current Practice is not upheld. Transmission Control Protocol (TCP) This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168. DNS Glue Requirements in Referral Responses The DNS uses glue records to allow iterative clients to find the addresses of name servers that are contained within a delegated zone. Authoritative servers are expected to return all available glue records for in-domain name servers in a referral response. If message size constraints prevent the inclusion of all glue records for in-domain name servers, the server must set the TC (Truncated) flag to inform the client that the response is incomplete and that the client should use another transport to retrieve the full response. This document updates RFC 1034 to clarify correct server behavior. IP Fragmentation Avoidance in DNS over UDP The widely deployed Extension Mechanisms for DNS (EDNS(0)) feature in the DNS enables a DNS receiver to indicate its received UDP message size capacity, which supports the sending of large UDP responses by a DNS server. Large DNS/UDP messages are more likely to be fragmented, and IP fragmentation has exposed weaknesses in application protocols. It is possible to avoid IP fragmentation in DNS by limiting the response size where possible and signaling the need to upgrade from UDP to TCP transport where necessary. This document describes techniques to avoid IP fragmentation in DNS. Informative References DNS flag day 2020 'How I learned to stop worrying and love IPv6': Measuring the Internet's Readiness for DNS over IPv6 IMC '25: Proceedings of the 2025 ACM Internet Measurement Conference, pp. 359-380 Technical requirements for authoritative name servers IANA resolv.conf(5) - Linux manual page Delegation Revalidation by DNS Resolvers Salesforce SIE Europe, U.G. NLnet Labs This document describes an optional algorithm for the processing of Name Server (NS) resource record (RR) sets (RRsets) during iterative resolution, and describes the benefits and considerations of using this approach. When following a referral response from an authoritative server to a child zone, DNS resolvers should explicitly query the authoritative NS RRset at the apex of the child zone and cache this in preference to the NS RRset on the parent side of the zone cut. The (A and AAAA) address RRsets in the additional section from referral responses and authoritative NS answers for the names of the NS RRset, should similarly be re-queried and used to replace the entries with the lower trustworthiness ranking in cache. Resolvers should also periodically revalidate the delegation by re-querying the parent zone at the expiration of the shortest TTL among the parent NS RRset, the DS RRset (if present), and the child NS RRset. Work in Progress Address Allocation for Private Internets This document describes address allocation for private internets. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Dynamic Host Configuration Protocol The Dynamic Host Configuration Protocol (DHCP) provides a framework for passing configuration information to hosts on a TCPIP network. DHCP is based on the Bootstrap Protocol (BOOTP), adding the capability of automatic allocation of reusable network addresses and additional configuration options. [STANDARDS-TRACK] Selection and Operation of Secondary DNS Servers This document discusses the selection of secondary servers for DNS zones.The number of servers appropriate for a zone is also discussed, and some general secondary server maintenance issues considered. This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Internet Protocol, Version 6 (IPv6) Specification This document specifies version 6 of the Internet Protocol (IPv6), also sometimes referred to as IP Next Generation or IPng. [STANDARDS-TRACK] Advanced Sockets Application Program Interface (API) for IPv6 This document provides sockets Application Program Interface (API) to support "advanced" IPv6 applications, as a supplement to a separate specification, RFC 3493. The expected applications include Ping, Traceroute, routing daemons and the like, which typically use raw sockets to access IPv6 or ICMPv6 header fields. This document proposes some portable interfaces for applications that use raw sockets under IPv6. There are other features of IPv6 that some applications will need to access: interface identification (specifying the outgoing interface and determining the incoming interface), IPv6 extension headers, and path Maximum Transmission Unit (MTU) information. This document provides API access to these features too. Additionally, some extended interfaces to libraries for the "r" commands are defined. The extension will provide better backward compatibility to existing implementations that are not IPv6-capable. This memo provides information for the Internet community. DNS IPv6 Transport Operational Guidelines This memo provides guidelines and Best Current Practice for operating DNS in a world where queries and responses are carried in a mixed environment of IPv4 and IPv6 networks. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Resource Records for the DNS Security Extensions This document is part of a family of documents that describe the DNS Security Extensions (DNSSEC). The DNS Security Extensions are a collection of resource records and protocol modifications that provide source authentication for the DNS. This document defines the public key (DNSKEY), delegation signer (DS), resource record digital signature (RRSIG), and authenticated denial of existence (NSEC) resource records. The purpose and format of each resource record is described in detail, and an example of each resource record is given. This document obsoletes RFC 2535 and incorporates changes from all updates to RFC 2535. [STANDARDS-TRACK] Unique Local IPv6 Unicast Addresses This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet. [STANDARDS-TRACK] Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server. IPv6 Support Required for All IP-Capable Nodes Given the global lack of available IPv4 space, and limitations in IPv4 extension and transition technologies, this document advises that IPv6 support is no longer considered optional. It also cautions that there are places in existing IETF documents where the term "IP" is used in a way that could be misunderstood by implementers as the term "IP" becomes a generic that can mean IPv4 + IPv6, IPv6-only, or IPv4-only, depending on context and application. This memo documents an Internet Best Current Practice. 464XLAT: Combination of Stateful and Stateless Translation This document describes an architecture (464XLAT) for providing limited IPv4 connectivity across an IPv6-only network by combining existing and well-known stateful protocol translation (as described in RFC 6146) in the core and stateless protocol translation (as described in RFC 6145) at the edge. 464XLAT is a simple and scalable technique to quickly deploy limited IPv4 access service to IPv6-only edge networks without encapsulation. Common Requirements for Carrier-Grade NATs (CGNs) This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis This document describes a method for detecting the presence of DNS64 and for learning the IPv6 prefix used for protocol translation on an access network. The method depends on the existence of a well-known IPv4-only fully qualified domain name "ipv4only.arpa.". The information learned enables nodes to perform local IPv6 address synthesis and to potentially avoid NAT64 on dual-stack and multi-interface deployments. NAT64 Deployment Options and Experience This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. Specification for DNS over Transport Layer Security (TLS) This document describes the use of Transport Layer Security (TLS) to provide privacy for DNS. Encryption provided by TLS eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network, such as discussed in RFC 7626. In addition, this document specifies two usage profiles for DNS over TLS and provides advice on performance considerations to minimize overhead from using TCP and TLS with DNS. This document focuses on securing stub-to-recursive traffic, as per the charter of the DPRIVE Working Group. It does not prevent future applications of the protocol to recursive-to-authoritative traffic. IPv6 Router Advertisement Options for DNS Configuration This document specifies IPv6 Router Advertisement (RA) options (called "DNS RA options") to allow IPv6 routers to advertise a list of DNS Recursive Server Addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss. Path MTU Discovery for IP version 6 This document describes Path MTU Discovery (PMTUD) for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC 1981. Discovering PREF64 in Router Advertisements This document specifies a Neighbor Discovery option to be used in Router Advertisements (RAs) to communicate prefixes of Network Address and Protocol Translation from IPv6 clients to IPv4 servers (NAT64) to hosts. IP Fragmentation Considered Fragile This document describes IP fragmentation and explains how it introduces fragility to Internet communication. This document also proposes alternatives to IP fragmentation and provides recommendations for developers and network operators. DNS over Dedicated QUIC Connections This document describes the use of QUIC to provide transport confidentiality for DNS. The encryption provided by QUIC has similar properties to those provided by TLS, while QUIC transport eliminates the head-of-line blocking issues inherent with TCP and provides more efficient packet-loss recovery than UDP. DNS over QUIC (DoQ) has privacy properties similar to DNS over TLS (DoT) specified in RFC 7858, and latency characteristics similar to classic DNS over UDP. This specification describes the use of DoQ as a general-purpose transport for DNS and includes the use of DoQ for stub to recursive, recursive to authoritative, and zone transfer scenarios. Pros and Cons of IPv6 Transition Technologies for IPv4-as-a-Service (IPv4aaS) Several IPv6 transition technologies have been developed to provide customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only access and/or core network. These technologies have their advantages and disadvantages. Depending on existing topology, skills, strategy, and other preferences, one of these technologies may be the most appropriate solution for a network operator. This document examines the five most prominent IPv4aaS technologies and considers a number of different aspects to provide network operators with an easy-to-use reference to assist in selecting the technology that best suits their needs. IPv6 Deployment Status This document provides an overview of the status of IPv6 deployment in 2022. Specifically, it looks at the degree of adoption of IPv6 in the industry, analyzes the remaining challenges, and proposes further investigations in areas where the industry has not yet taken a clear and unified approach in the transition to IPv6. It obsoletes RFC 6036. DNS Terminology The Domain Name System (DNS) is defined in literally dozens of different RFCs. The terminology used by implementers and developers of DNS protocols, and by operators of DNS systems, has changed in the decades since the DNS was first defined. This document gives current definitions for many of the terms used in the DNS in a single document. This document updates RFC 2308 by clarifying the definitions of "forwarder" and "QNAME". It obsoletes RFC 8499 by adding multiple terms and clarifications. Comprehensive lists of changed and new definitions can be found in Appendices A and B. Recommendations for Discovering IPv6 Prefix Used for IPv6 Address Synthesis On networks providing IPv4-IPv6 translation (RFC 7915), hosts and other endpoints need to know the IPv6 prefix(es) used for translation (the NAT64 prefix (RFC 6052)). This document provides guidelines for NAT64 prefix discovery, specifically recommending obtaining the NAT64 prefix from the Router Advertisement option (RFC 8781) when available. Dynamic Host Configuration Protocol for IPv6 (DHCPv6) This document specifies the Dynamic Host Configuration Protocol for IPv6 (DHCPv6), an extensible mechanism for configuring nodes with network configuration parameters, IP addresses, and prefixes. Parameters can be provided statelessly or in combination with stateful assignment of one or more IPv6 addresses and/or IPv6 prefixes. DHCPv6 can operate either in place of or in addition to stateless address autoconfiguration (SLAAC). This document obsoletes RFC 8415. It incorporates verified errata and obsoletes the assignment of temporary addresses (the IA_TA option) and the server unicast capability (the Server Unicast option and UseMulticast status code). The RIPE NCC has run out of IPv4 Addresses RIPE NCC How Ready is DNS for an IPv6-Only World? Passive and Active Measurement (PAM 2023), Lecture Notes in Computer Science, vol. 13882, pp. 525-549
Changes Since RFC 3901 The following changes have been made to the guidance published in :
  • Expanded the terminology section, also taking considerations from into account.
  • Expanded name space partitioning, independently discussing intentional choices, misconfigurations, and network conditions, which lead to name space partitioning due to differences in IP address family support.
  • 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.
Acknowledgments Valuable input for this document was provided by the following individuals: , , , , , , , , , , , , , , , , , , , , , , , , , , , and . Furthermore, the authors express their thanks to the authors of , and , 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 in his thorough review of the document.
Authors' Addresses WIDE Project
momoka.my6@gmail.com
Max-Planck-Institut fuer Informatik
Campus E14 Saarbruecken 66123 Germany +49 681 9325 3527 tfiebig@mpi-inf.mpg.de