RFC 3901

DNS IPv6 Transport Operational Guidelines

📅 published September 2004, from ietf

RFC 3901: DNS IPv6 Transport Operational Guidelines 🎀

okay bestie, let's do the paperwork first 📋✨ this is RFC 3901, a Best Current Practice (it's BCP 91), published in September 2004. It's by A. Durand (SUN Microsystems, Inc.) and J. Ihren (Autonomica), and the title block doesn't list anything it obsoletes or updates 🫶 the Network Working Group is where it came from 💅

Status of This Memo 📌

so this doc is an Internet Best Current Practice for the Internet Community 🌸 it's literally asking for discussion and suggestions for improvements, so bring your thoughts! and distribution of this memo is unlimited 🦋

Copyright (C) The Internet Society (2004) 💜

Abstract 🧚

okay so this memo gives guidelines and Best Current Practice for running DNS in a world where queries and responses travel over a mixed bag of IPv4 and IPv6 networks 🌈 it's giving "let's not break everything during the glow-up" energy 💅

1. Introduction to the Problem of Name Space Fragmentation: following the referral chain ✨

okay this part is lowkey the core drama 🎭 a resolver looking up a name starts at the root, then follows referrals until it gets sent to a name server that's authoritative for that name 🦋 but here's the catch: if somewhere down that chain of referrals it's pointed at a name server that's only reachable over a transport the resolver can't use, the resolver just cannot finish the job 😭

when the Internet moves from IPv4 to a mix of IPv4 and IPv6, this is literally only a matter of time 💀 the whole DNS hierarchy starts to fragment into a graph, where the authoritative name servers for certain nodes are only reachable over certain transports 🧩 the worry is that a resolver using just one IP version, asking about a node that also uses that same version, still can't get the answer, because somewhere in the chain one of the servers is only reachable over the other version 🙈

with all DNS data only available over IPv4 transport, everything is simple 🍓 IPv4 resolvers can use the intended mechanism of following referrals from the root and down, while IPv6 resolvers have to go through a "translator" (aka they use a recursive name server on a so-called "dual stack" host as a "forwarder", since they can't access the DNS data directly) 🫠

with all DNS data only available over IPv6 transport, everything would be equally simple, except IPv4 recursive name servers would have to switch to a forwarding configuration 🌸

BUT the second situation isn't going to happen in the foreseeable future 🙃 instead, the transition goes from IPv4-only to a mix of IPv4 and IPv6, with three categories of DNS data: available only over IPv4 transport, only over IPv6, or over both 💖

having DNS data on both transports is the best situation ✨ the major question is how to make it the norm as fast as possible 🏃‍♀️ still, it's obvious that some DNS data will only be available over v4 transport for a long time, so it's super important to avoid fragmenting the name space available to IPv4-only hosts 🫶 for example, during the transition it is not acceptable to break the name space we currently have available for IPv4-only hosts 🚫

2. Terminology 📖

so an "IPv4 name server" is a name server available over IPv4 transport 🦋 it doesn't say anything about what DNS [1,2] data it serves 🌈 same vibe for "IPv6 [4,5,6] name server", which is a name server available over IPv6 transport 💜

and a "dual-stack name server" is one that's actually configured to run both IPv4 and IPv6 🧚 it's NOT just a server sitting on a system that could run both but is actually only set up to run one 🙈

3. Policy Based Avoidance of Name Space Fragmentation 🛡️

right now there are only a few DNS "zones" on the public Internet that are available over IPv6 transport, and most of them can be called "experimental" 🧪 but once the root and top level domains are available over IPv6 transport, it's totally reasonable to expect that zones served by IPv6 servers will become more common 📈

having those zones served only by IPv6-only name servers would not be a good development 😬 it would fragment the previously unfragmented IPv4 name space, and there are strong reasons to find a mechanism to avoid that 🚨

the recommended approach for keeping name space continuity is administrative policies, which the next section covers 💅

okay so to preserve name space continuity, the following administrative policies are recommended 🫶

  • every recursive name server SHOULD be either IPv4-only or dual stack,

this rules out IPv6-only recursive servers 🙅‍♀️ but one might design configurations where a chain of IPv6-only name servers forwards queries to a set of dual stack recursive name servers that actually perform those recursive queries 🧠

  • every DNS zone SHOULD be served by at least one IPv4-reachable authoritative name server.

this rules out DNS zones served only by IPv6-only authoritative name servers 🚫

Note: zone validation processes SHOULD ensure that there is at least one IPv4 address record available for the name servers of any child delegations within the zone. 📝

5. Security Considerations 🔐

okay this is the serious bit, so listen 👀 the guidelines in this memo introduce no new security considerations into the DNS protocol or its associated operational scenarios 🛡️✨ nothing new to panic about, but keep your DNS locked in 🔥

6. Acknowledgment 🫶

this document is the result of many conversations in the DNS community at the IETF and elsewhere since 2001 🌷 during that time, a bunch of Internet drafts got published to clarify different parts of the issues, and this doc focuses on where those discussions landed 💜

the authors would like to give a shoutout to Pekka Savola for his thorough review of the document 👏🌈

7. Normative References 📚

  • [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
  • [2] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
  • [3] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
  • [4] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
  • [5] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
  • [6] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.

8. Authors' Addresses 🏡

Alain Durand
SUN Microsystems, Inc
17 Network circle UMPK17-202
Menlo Park, CA, 94025
USA

EMail: Alain.Durand@sun.com


Johan Ihren
Autonomica
Bellmansgatan 30
SE-118 47 Stockholm
Sweden

EMail: johani@autonomica.se

Copyright (C) The Internet Society (2004) 💜

this document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth there, the authors keep all their rights 🦋

the legal disclaimer is serious business, so here it is exactly as written 👇

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property 🔍

the IETF takes no position on the validity or scope of any Intellectual Property Rights or other rights that might be claimed to apply to the technology in this document, or on whether any license under those rights might be available 🤷‍♀️ it also doesn't claim to have made any independent effort to find such rights. info on the IETF's procedures for rights in IETF Documents is in BCP 78 and BCP 79 📖

copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license for implementers or users, can be found in the IETF on-line IPR repository at http://www.ietf.org/ipr 🌐

the IETF also invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology required to implement this standard 💌 send that info to ietf-ipr@ietf.org 📬

Acknowledgement 🌷

funding for the RFC Editor function is currently provided by the Internet Society 🫶💖

📦 where this page comes from