RFC 10001 - Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments
Skip to main content
Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript.<br>Please enable Javascript for full functionality.
Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments
RFC 10001<br>part of BCP 91
Status
Email expansions
History
Document<br>Type
RFC
- Best Current Practice
(August 2026)
Obsoletes RFC 3901
Was<br>draft-ietf-dnsop-3901bis<br>(dnsop WG)
Authors
Momoka
T. Fiebig
Last updated
2026-08-11
RFC stream
Internet Engineering Task Force (IETF)
Formats
txt
html
xml
htmlized
bibtex
Additional resources
Mailing list discussion
IESG
Responsible AD
Mohamed Boucadair
Send notices to
(None)
Email authors
Email WG
IPR
References
Referenced by
Get editor source
Search Lists
RFC 10001
Internet Engineering Task Force (IETF) Momoka<br>Request for Comments: 10001 WIDE Project<br>BCP: 91 T. Fiebig<br>Obsoletes: 3901 MPI-INF<br>Category: Best Current Practice August 2026<br>ISSN: 2070-1721
Operational Guidelines for DNS Transport in Mixed IPv4/IPv6 Environments
Abstract
This document provides guidelines and documents best current practice<br>for operating authoritative DNS servers, recursive resolvers, and<br>stub resolvers in a mixed IPv4/IPv6 environment. This document<br>recommends that both authoritative DNS servers and recursive<br>resolvers support IPv4 and IPv6. It also provides guidance on how<br>recursive DNS resolvers should select upstream DNS servers, including<br>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<br>(IETF). It represents the consensus of the IETF community. It has<br>received public review and has been approved for publication by the<br>Internet Engineering Steering Group (IESG). Further information on<br>BCPs is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,<br>and how to provide feedback on it may be obtained at<br>https://www.rfc-editor.org/info/rfc10001.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the<br>document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal<br>Provisions Relating to IETF Documents<br>(https://trustee.ietf.org/license-info) in effect on the date of<br>publication of this document. Please review these documents<br>carefully, as they describe your rights and restrictions with respect<br>to this document. Code Components extracted from this document must<br>include Revised BSD License text as described in Section 4.e of the<br>Trust Legal Provisions and are provided without warranty as described<br>in the Revised BSD License.
Table of Contents
1. Introduction<br>2. Terminology<br>2.1. Requirements Language<br>3. Name Space Partitioning<br>3.1. Misconfigurations Causing Name Space Partitioning Due to IP<br>Address Family Support<br>3.2. Network Conditions Causing Name Space Partitioning Due to<br>IP Address Family Support<br>3.3. Reasons for Intentional Name Space Partitioning Due to IP<br>Address Family Support<br>4. Policy-Based Avoidance of Name Space Partitioning<br>4.1. Guidelines for Authoritative DNS Server Configuration<br>4.2. Guidelines for Recursive DNS Resolvers<br>4.3. Guidelines for DNS Stub Resolvers<br>5. Security Considerations<br>6. IANA Considerations<br>7. References<br>7.1. Normative References<br>7.2. Informative References<br>Appendix A. Changes Since RFC 3901<br>Acknowledgments<br>Authors' Addresses
1. Introduction
Despite IPv6 being first discussed in the mid-1990s [RFC2460],<br>consistent deployment throughout the whole Internet has not yet been<br>accomplished [RFC9386]. Hence, the Internet still consists of<br>IPv4-only, dual-stack (networks supporting both IP address families),<br>and IPv6-only networks.
This creates a complex landscape where authoritative DNS servers<br>might be accessible only via specific network protocols<br>[V6DNSRDY-23]. At the same time, DNS resolvers may only be able to<br>access the Internet via either IPv4 or IPv6 connectivity. This poses<br>a challenge for such resolvers because they may receive queries for<br>names whose authoritative DNS servers do not support the same IP<br>address family as the resolver itself.
[RFC3901] was written at a time when IPv6 deployment was not<br>widespread and focuses primarily on maintaining name space continuity<br>within the IPv4 landscape. Two decades later, IPv6 is widely<br>deployed and is also becoming the de facto standard in many areas,<br>such as mobile and access networks and data-center underlays.<br>Furthermore, since 2012, IPv6 support being required for all IP-<br>capable nodes has been established as a best current practice<br>[RFC6540]. This document broadens the scope of [RFC3901] by<br>recommending IPv6 connectivity for authoritative DNS servers,<br>recursive resolvers, and stub resolvers.
This document provides:
* Guidance on name space partitioning due...