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