From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2826.txt | 339 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 339 insertions(+) create mode 100644 doc/rfc/rfc2826.txt (limited to 'doc/rfc/rfc2826.txt') diff --git a/doc/rfc/rfc2826.txt b/doc/rfc/rfc2826.txt new file mode 100644 index 0000000..f31054e --- /dev/null +++ b/doc/rfc/rfc2826.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group Internet Architecture Board +Request for Comments: 2826 May 2000 +Category: Informational + + + IAB Technical Comment on the Unique DNS Root + +Status of this Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2000). All Rights Reserved. + +Summary + + To remain a global network, the Internet requires the existence of a + globally unique public name space. The DNS name space is a + hierarchical name space derived from a single, globally unique root. + This is a technical constraint inherent in the design of the DNS. + Therefore it is not technically feasible for there to be more than + one root in the public DNS. That one root must be supported by a set + of coordinated root servers administered by a unique naming + authority. + + Put simply, deploying multiple public DNS roots would raise a very + strong possibility that users of different ISPs who click on the same + link on a web page could end up at different destinations, against + the will of the web page designers. + + This does not preclude private networks from operating their own + private name spaces, but if they wish to make use of names uniquely + defined for the global Internet, they have to fetch that information + from the global DNS naming hierarchy, and in particular from the + coordinated root servers of the global DNS naming hierarchy. + +1. Detailed Explanation + + There are several distinct reasons why the DNS requires a single root + in order to operate properly. + +1.1. Maintenance of a Common Symbol Set + + Effective communications between two parties requires two essential + preconditions: + + + +IAB Informational [Page 1] + +RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000 + + + - The existence of a common symbol set, and + + - The existence of a common semantic interpretation of these + symbols. + + Failure to meet the first condition implies a failure to communicate + at all, while failure to meet the second implies that the meaning of + the communication is lost. + + In the case of a public communications system this condition of a + common symbol set with a common semantic interpretation must be + further strengthened to that of a unique symbol set with a unique + semantic interpretation. This condition of uniqueness allows any + party to initiate a communication that can be received and understood + by any other party. Such a condition rules out the ability to define + a symbol within some bounded context. In such a case, once the + communication moves out of the context of interpretation in which it + was defined, the meaning of the symbol becomes lost. + + Within public digital communications networks such as the Internet + this requirement for a uniquely defined symbol set with a uniquely + defined meaning exists at many levels, commencing with the binary + encoding scheme, extending to packet headers and payload formats and + the protocol that an application uses to interact. In each case a + variation of the symbol set or a difference of interpretation of the + symbols being used within the interaction causes a protocol failure, + and the communication fails. The property of uniqueness allows a + symbol to be used unambiguously in any context, allowing the symbol + to be passed on, referred to, and reused, while still preserving the + meaning of the original use. + + The DNS fulfills an essential role within the Internet protocol + environment, allowing network locations to be referred to using a + label other than a protocol address. As with any other such symbol + set, DNS names are designed to be globally unique, that is, for any + one DNS name at any one time there must be a single set of DNS + records uniquely describing protocol addresses, network resources and + services associated with that DNS name. All of the applications + deployed on the Internet which use the DNS assume this, and Internet + users expect such behavior from DNS names. Names are then constant + symbols, whose interpretation does not specifically require knowledge + of the context of any individual party. A DNS name can be passed + from one party to another without altering the semantic intent of the + name. + + Since the DNS is hierarchically structured into domains, the + uniqueness requirement for DNS names in their entirety implies that + each of the names (sub-domains) defined within a domain has a unique + + + +IAB Informational [Page 2] + +RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000 + + + meaning (i.e., set of DNS records) within that domain. This is as + true for the root domain as for any other DNS domain. The + requirement for uniqueness within a domain further implies that there + be some mechanism to prevent name conflicts within a domain. In DNS + this is accomplished by assigning a single owner or maintainer to + every domain, including the root domain, who is responsible for + ensuring that each sub-domain of that domain has the proper records + associated with it. This is a technical requirement, not a policy + choice. + +1.2. Coordination of Updates + + Both the design and implementations of the DNS protocol are heavily + based on the assumption that there is a single owner or maintainer + for every domain, and that any set of resources records associated + with a domain is modified in a single-copy serializable fashion. + That is, even assuming that a single domain could somehow be "shared" + by uncooperating parties, there is no means within the DNS protocol + by which a user or client could discover, and choose between, + conflicting definitions of a DNS name made by different parties. The + client will simply return the first set of resource records that it + finds that matches the requested domain, and assume that these are + valid. This protocol is embedded in the operating software of + hundreds of millions of computer systems, and is not easily updated + to support a shared domain scenario. + + Moreover, even supposing that some other means of resolving + conflicting definitions could be provided in the future, it would + have to be based on objective rules established in advance. For + example, zone A.B could declare that naming authority Y had been + delegated all subdomains of A.B with an odd number of characters, and + that naming authority Z had been delegated authority to define + subdomains of A.B with an even number of characters. Thus, a single + set of rules would have to be agreed to prevent Y and Z from making + conflicting assignments, and with this train of actions a single + unique space has been created in any case. Even this would not allow + multiple non-cooperating authorities to assign arbitrary sub-domains + within a single domain. + + It seems that a degree of cooperation and agreed technical rules are + required in order to guarantee the uniqueness of names. In the DNS, + these rules are established independently for each part of the naming + hierarchy, and the root domain is no exception. Thus, there must be + a generally agreed single set of rules for the root. + + + + + + + +IAB Informational [Page 3] + +RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000 + + +1.3. Difficulty of Relocating the Root Zone + + There is one specific technical respect in which the root zone + differs from all other DNS zones: the addresses of the name servers + for the root zone come primarily from out-of-band information. This + out-of-band information is often poorly maintained and, unlike all + other data in the DNS, the out-of-band information has no automatic + timeout mechanism. It is not uncommon for this information to be + years out of date at many sites. + + Like any other zone, the root zone contains a set of "name server" + resource records listing its servers, but a resolver with no valid + addresses for the current set of root servers will never be able to + obtain these records. More insidiously, a resolver that has a mixed + set of partially valid and partially stale out-of-band configuration + information will not be able to tell which are the "real" root + servers if it gets back conflicting answers; thus, it is very + difficult to revoke the status of a malicious root server, or even to + route around a buggy root server. + + In effect, every full-service resolver in the world "delegates" the + root of the public tree to the public root server(s) of its choice. + + As a direct consequence, any change to the list of IP addresses that + specify the public root zone is significantly more difficult than + changing any other aspect of the DNS delegation chain. Thus, + stability of the system calls for extremely conservative and cautious + management of the public root zone: the frequency of updates to the + root zone must be kept low, and the servers for the root zone must be + closely coordinated. + + These problems can be ameliorated to some extent by the DNS Security + Extensions [DNSSEC], but a similar out-of-band configuration problem + exists for the cryptographic signature key to the root zone, so the + root zone still requires tight coupling and coordinated management + even in the presence of DNSSEC. + +2. Conclusion + + The DNS type of unique naming and name-mapping system may not be + ideal for a number of purposes for which it was never designed, such + a locating information when the user doesn't precisely know the + correct names. As the Internet continues to expand, we would expect + directory systems to evolve which can assist the user in dealing with + vague or ambiguous references. To preserve the many important + features of the DNS and its multiple record types -- including the + Internet's equivalent of telephone number portability -- we would + expect the result of directory lookups and identification of the + + + +IAB Informational [Page 4] + +RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000 + + + correct names for a particular purpose to be unique DNS names that + are then resolved normally, rather than having directory systems + "replace" the DNS. + + There is no getting away from the unique root of the public DNS. + +3. Security Considerations + + This memo does not introduce any new security issues, but it does + attempt to identify some of the problems inherent in a family of + recurring technically naive proposals. + +4. IANA Considerations + + This memo is not intended to create any new issues for IANA. + +5. References + + [DNS-CONCEPTS] Mockapetris, P., "Domain Names - Concepts and + Facilities", STD 13, RFC 1034, November 1987. + + [DNS-IMPLEMENTATION] Mockapetris, P., "Domain Names - Implementation + and Specification", STD 13, RFC 1035, November + 1987. + + [DNSSEC] Eastlake, D., "Domain Name System Security + Extensions", RFC 2535, March 1999. + +6. Author's Address + + Internet Architecture Board + + EMail: iab@iab.org + + + + + + + + + + + + + + + + + + +IAB Informational [Page 5] + +RFC 2826 IAB Technical Comment on the Unique DNS Root May 2000 + + +7. Full Copyright Statement + + Copyright (C) The Internet Society (2000). All Rights Reserved. + + This document and translations of it may be copied and furnished to + others, and derivative works that comment on or otherwise explain it + or assist in its implementation may be prepared, copied, published + and distributed, in whole or in part, without restriction of any + kind, provided that the above copyright notice and this paragraph are + included on all such copies and derivative works. However, this + document itself may not be modified in any way, such as by removing + the copyright notice or references to the Internet Society or other + Internet organizations, except as needed for the purpose of + developing Internet standards in which case the procedures for + copyrights defined in the Internet Standards process must be + followed, or as required to translate it into languages other than + English. + + The limited permissions granted above are perpetual and will not be + revoked by the Internet Society or its successors or assigns. + + This document and the information contained herein is provided on an + "AS IS" basis and 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +IAB Informational [Page 6] + -- cgit v1.2.3