RFC 2826

IAB Technical Comment on the Unique DNS Root 🎀

Network Working Group 🌸 Request for Comments: 2826 💅 Author: Internet Architecture Board 👑 Date: May 2000 📅 Category: Informational ✨ Obsoletes/Updates: none listed in the title block 🦋

Status of this Memo

okay bestie, this memo is here to give info to the Internet community 🫶 It does not specify an Internet standard of any kind, so nobody has to "implement" it like a rule. Distribution of this memo is unlimited, so share it with everyone 💖

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved. 🔥

Summary ✨

okay so the Internet needs a globally unique public name space to stay one global network 🌍 The DNS name space is a hierarchical name space that comes from a single, globally unique root. This is a technical constraint built into how the DNS is designed, so it is not technically feasible to have more than one root in the public DNS 🙅‍♀️ That one root has to be backed by a set of coordinated root servers, and they're run by a unique naming authority 👑

Put simply, if we deployed multiple public DNS roots, users of different ISPs who click the same link on a web page could end up at different destinations 😭 That's totally against what the web page designers wanted!! 💀

Private networks are still allowed to run their own private name spaces 🧚 But if they want to use names that are uniquely defined for the global Internet, they have to fetch that info from the global DNS naming hierarchy, and in particular from the coordinated root servers of that hierarchy 💜

1. Detailed Explanation 💖

There are several distinct reasons why the DNS needs a single root in order to work properly 🌈

1.1. Maintenance of a Common Symbol Set 🦋

Effective communication between two parties needs two essential preconditions:

• The existence of a common symbol set, and
• The existence of a common semantic interpretation of these symbols.

If the first one fails, there's no communication at all 💀 If the second one fails, the meaning of the message gets lost 😭

On a public communications system, this condition of a common symbol set with a common semantic interpretation has to be pushed even further, into a unique symbol set with a unique semantic interpretation ✨ That uniqueness lets any party start a communication that any other party can receive and understand 🫶 A symbol defined inside some bounded context is a no-go, because once the communication leaves the context where it was defined, the meaning of the symbol is lost 🙈

On public digital networks like the Internet, this need for a uniquely defined symbol set with a uniquely defined meaning shows up at many levels 🔥 It starts with the binary encoding scheme, then covers packet headers and payload formats, and goes all the way up to the protocol an application uses to interact 💅 At every level, if the symbol set changes or the symbols get interpreted differently during an interaction, the protocol breaks and the communication fails 😭 Uniqueness is what lets a symbol be used unambiguously in any context, so it can be passed on, referred to, and reused while still keeping the meaning of the original use 💖

The DNS plays a huge role in the Internet protocol environment 🧚 It lets network locations be referred to with a label other than a protocol address ✨ Like any other symbol set like this, DNS names are designed to be globally unique 👑 That means for any one DNS name, at any one time, there must be a single set of DNS records that uniquely describes the protocol addresses, network resources, and services tied to that name 🫶 Every application on the Internet that uses the DNS assumes this, and Internet users expect it from DNS names too 💜 So names are constant symbols, and understanding them doesn't require knowing the context of any individual party 🦋 A DNS name can be passed from one party to another without changing what the name means 🌸

Here's the tricky part 🙈 The DNS is hierarchically structured into domains, so the uniqueness requirement for whole DNS names means that each name (sub-domain) defined inside a domain also has a unique meaning, meaning a unique set of DNS records, within that domain 💅 This is just as true for the root domain as for any other DNS domain 👑 Uniqueness inside a domain also means there has to be some mechanism to stop name conflicts within that domain 😭 In the DNS, that's handled by assigning a single owner or maintainer to every domain, including the root domain 🔥 That owner is responsible for making sure each sub-domain of their domain has the proper records attached 🫶 This is a technical requirement, not a policy choice, bestie 💖

1.2. Coordination of Updates 🌈

Both the design and the implementations of the DNS protocol are heavily based on the assumption that every domain has a single owner or maintainer, and that any set of resource records for a domain is modified in a single-copy serializable fashion ✨ Even if a single domain could somehow be "shared" by parties that don't cooperate, the DNS protocol has no way for a user or client to discover conflicting definitions of a DNS name made by different parties and choose between them 💀 The client just returns the first set of resource records it finds that matches the requested domain, and assumes they're valid 🙈 This protocol is baked into the operating software of hundreds of millions of computer systems, so it's not easy to update it for a shared domain scenario 😭

Even if some other way of resolving conflicting definitions showed up in the future, it would have to be based on objective rules set up in advance 🦋 For example, zone A.B could declare that naming authority Y was delegated all subdomains of A.B with an odd number of characters, and that naming authority Z was delegated authority to define subdomains of A.B with an even number of characters 🧚 So a single set of rules would have to be agreed on to stop Y and Z from making conflicting assignments, and with that whole train of actions, a single unique space has been created anyway 💅 Even then, it still wouldn't let multiple non-cooperating authorities assign arbitrary sub-domains inside a single domain 💀

It seems like a degree of cooperation and agreed technical rules are needed to guarantee that names are unique 🫶 In the DNS, these rules are set up independently for each part of the naming hierarchy, and the root domain is no exception 👑 So there must be a generally agreed single set of rules for the root 💖

1.3. Difficulty of Relocating the Root Zone 🎀

The root zone is different from all other DNS zones in one specific technical way 🙈 The addresses of the name servers for the root zone mostly come from out-of-band information ✨ This out-of-band info is often poorly maintained, and unlike all other data in the DNS, it has no automatic timeout mechanism 😭 It's not unusual for this info to be years out of date at many sites 💀

Like any other zone, the root zone has a set of "name server" resource records that list its servers 🦋 But a resolver with no valid addresses for the current set of root servers will never be able to get those records 🙈 It gets even sneakier: a resolver with a mix of partially valid and partially stale out-of-band config info can't tell which servers are the "real" root servers if it gets conflicting answers back 😱 So it's really hard to revoke the status of a malicious root server, or even to route around a buggy one 🔥

Basically, every full-service resolver in the world "delegates" the root of the public tree to the public root server(s) it chooses 🧚

As a direct result, changing the list of IP addresses that specify the public root zone is way harder than changing any other part of the DNS delegation chain 💅 So for stability, the public root zone has to be managed in an extremely conservative and cautious way 👑 The frequency of updates to the root zone must be kept low, and the root zone's servers must be closely coordinated 🫶

These problems can be eased a bit by the DNS Security Extensions [DNSSEC] 💜 But a similar out-of-band configuration problem exists for the cryptographic signature key of the root zone, so the root zone still needs tight coupling and coordinated management even with DNSSEC in place 🌸

7. Full Copyright Statement ✨

okay bestie, copyright time 💅 Copyright (C) The Internet Society (2000). All Rights Reserved. 🌸

So here's the deal: you can copy this document and share it with anyone 🫶 You can also make derivative works that comment on it, explain it, or help people implement it, and you can publish and distribute those in whole or in part, no restrictions of any kind 🎀 The one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work.

What you can't do is edit this document itself. That means no removing the copyright notice, and no removing references to the Internet Society or other Internet organizations 🙅‍♀️ The exceptions are if you need it for developing Internet standards, in which case you follow the copyright procedures in the Internet Standards process, or if you need to translate it into a language other than English 🌈

These permissions are perpetual. The Internet Society and its successors or assigns will never revoke them 💜

And the legal disclaimer, because we have to 💀 This document and the information in it is provided "AS IS". THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Not giving anyone a guarantee, but still obsessed with it ✨

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society. 🍓 Someone's paying for the RFC Editor to keep things running, and that's iconic 👑