idnits 2.17.1 draft-iab-unique-dns-root-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** The document seems to lack an Introduction section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 2000) is 8836 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'DNS-CONCEPTS' is defined on line 222, but no explicit reference was found in the text == Unused Reference: 'DNS-IMPLEMENTATION' is defined on line 225, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (ref. 'DNSSEC') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Internet Architecture Board 3 draft-iab-unique-dns-root-00.txt 4 February 2000 6 IAB Technical Comment on the Unique DNS Root 8 Status of this document 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 26 The list of Internet-Draft Shadow Directories can be accessed at 27 29 Distribution of this document is unlimited. Please send comments to 30 iab@ietf.org. 32 1. Summary 34 To remain a global network, the Internet requires the existence of a 35 globally unique public name space. The DNS name space is a 36 hierarchical name space derived from a single, globally unique root. 37 This is a technical constraint inherent in the design of the DNS 38 system. Therefore it is not technically feasible for there to be 39 more than one root in the public DNS system. That one root must be 40 supported by a small number of coordinated root servers, and 41 administered by a unique naming authority. 43 Put simply, deploying multiple public DNS roots would raise a very 44 strong possibility that users of different ISPs who click on the same 45 link on a web page could end up at different destinations, against 46 the will of the web page designers. 48 This does not preclude private networks from operating their own 49 private name spaces, but if they wish to make use of names uniquely 50 defined for the global Internet, they have to fetch that information 51 from the global DNS naming hierarchy, and in particular from the 52 coordinated root servers of the global DNS naming hierarchy. 54 2. Detailed Explanation 56 There are several distinct reasons why the DNS requires a single root 57 in order to operate properly. 59 2.1. Maintenance of a Common Symbol Set 61 Effective communications between two parties requires two essential 62 preconditions: 64 - The existence of a common symbol set, and 66 - The existence of a common semantic interpretation of these symbols. 68 Failure to meet the first condition implies a failure to communicate 69 at all, while failure to meet the second implies that the meaning of 70 the communication is lost. 72 In the case of a public communications system this condition of a 73 common symbol set with a common semantic interpretation must be 74 further strengthened to that of a unique symbol set with a unique 75 semantic interpretation. This condition of uniqueness allows any 76 party to initiate a communication that can be received and understood 77 by any other party. Such a condition rules out the ability to define 78 a symbol within some bounded context. In such a case, once the 79 communication moves out of the context of interpretation in which it 80 was defined, the meaning of the symbol becomes lost. 82 Within public digital communications networks such as the Internet 83 this requirement for a uniquely defined symbol set with a uniquely 84 defined meaning exists at many levels, commencing with the binary 85 encoding scheme, extending to packet headers and payload formats and 86 the protocol that an application uses to interact. In each case a 87 variation of the symbol set or a difference of interpretation of the 88 symbols being used within the interaction causes a protocol failure, 89 and the communication fails. The property of uniqueness allows a 90 symbol to be used unambiguously in any context, allowing the symbol 91 to be passed on, referred to, and reused, while still preserving the 92 meaning of the original use. 94 The DNS fulfills an essential role within the Internet protocol 95 environment, allowing network locations to be referred to using a 96 label other than a protocol address. As with any other such symbol 97 set, DNS names are designed to be globally unique, that is, for any 98 one DNS name at any one time there must be a single set of DNS 99 records uniquely describing protocol addresses, network resources and 100 services associated with that DNS name. All of the applications 101 deployed on the Internet which use DNS assume this, and Internet 102 users expect such behavior from DNS names. Names are then constant 103 symbols, whose interpretation does not specifically require knowledge 104 of the context of any individual party. A DNS name can be passed 105 from one party to another without altering the semantic intent of the 106 name. 108 Since the DNS is hierarchically structured into domains, the 109 uniqueness requirement for DNS names in their entirety implies that 110 each of the names (sub-domains) defined within a domain has a unique 111 meaning (i.e. set of DNS records) within that domain. This is as 112 true for the root domain as for any other DNS domain. The 113 requirement for uniqueness within a domain further implies that there 114 be some mechanism to prevent name conflicts within a domain. In DNS 115 this is accomplished by assigning a single owner or maintainer to 116 every domain, including the root domain, who is responsible for 117 ensuring that each sub-domain of that domain has the proper records 118 associated with it. This is a technical requirement, not a policy 119 choice. 121 2.2. Coordination of Updates 123 Both the design and implementations of the DNS protocol are heavily 124 based on the assumption that there is a single owner or maintainer 125 for every domain, and that any set of resources records associated 126 with a domain is modified in a single-copy serializable fashion. 127 That is, even assuming that a single domain could somehow be "shared" 128 by uncooperating parties, there is no means within the DNS protocol 129 by which a user or client could discover, and choose between, 130 conflicting definitions of a DNS name made by different parties. The 131 client will simply return the first set of resource records that it 132 finds that matches the requested domain, and assume that these are 133 valid. This protocol is embedded in the operating software of 134 hundreds of millions of computer systems, and is not easily updated 135 to support a shared domain scenario. 137 Moreover, even supposing that some other means of resolving 138 conflicting definitions could be provided in the future, it would 139 have to be based on objective rules established in advance. For 140 example, zone A.B could declare that naming authority Y had been 141 delegated all subdomains of A.B with an odd number of characters, and 142 that naming authority Z had been delegated authority to define 143 subdomains of A.B with an even number of characters. Thus, a single 144 set of rules would have to be agreed to prevent Y and Z from making 145 conflicting assignments, and with this train of actions a single 146 unique space has been created in any case. Even this would not allow 147 multiple non-cooperating authorities to assign arbitrary sub-domains 148 within a single domain. 150 It seems that a degree of cooperation and agreed technical rules are 151 required in order to guarantee the uniqueness of names. In the DNS, 152 these rules are established independently for each part of the naming 153 hierarchy, and the root domain is no exception. Thus, there must be 154 a generally agreed single set of rules for the root. 156 2.3. Difficulty of Relocating the Root Zone 158 There is one specific technical respect in which the root zone 159 differs from all other DNS zones: the addresses of the name servers 160 for the root zone come primarily from out-of-band information. This 161 out-of-band information is often poorly maintained and, unlike all 162 other data in the DNS, the out-of-band information has no automatic 163 timeout mechanism. It is not uncommon for this information to be 164 years out of date at many sites. 166 Like any other zone, the root zone contains a set of "name server" 167 resource records listing its servers, but a resolver with no valid 168 addresses for the current set of root servers will never be able to 169 obtain these records. More insidiously, a resolver that has a mixed 170 set of partially valid and partially stale out-of-band configuration 171 information will not be able to tell which are the "real" root 172 servers if it gets back conflicting answers; thus, it is very 173 difficult to revoke the status of a malicious root server, or even to 174 route around a buggy root server. 176 In effect, every full-service resolver in the world "delegates" the 177 root of the public tree to the public root server(s) of its choice. 179 As a direct consequence, any change to the list of IP addresses that 180 specify the public root zone is significantly more difficult than 181 changing any other aspect of the DNS delegation chain. Thus, 182 stability of the system calls for extremely conservative and cautious 183 management of the public root zone: the frequency of updates to the 184 root zone should be kept low, and the servers for the root zone 185 should be closely coordinated. 187 These problems can be ameliorated to some extent by the DNS Security 188 Extensions [DNSSEC], but a similar out-of-band configuration problem 189 exists for the cryptographic signature key to the root zone, so the 190 root zone still requires tight coupling and coordinated management 191 even in the presence of DNSSEC. 193 3. Conclusion 195 The DNS type of unique naming and name-mapping system may not be 196 ideal for a number of purposes for which it was never designed, such 197 a locating information when the user doesn't precisely know the 198 correct names. As the Internet continues to expand, we would expect 199 directory systems to evolve which can assist the user in dealing with 200 vague or ambiguous references. To preserve the many important 201 features of the DNS and its multiple record types -- including the 202 Internet's equivalent of telephone number portability -- we would 203 expect the result of directory lookups and identification of the 204 correct names for a particular purpose to be unique DNS names that 205 are then resolved normally, rather than having directory systems 206 "replace" the DNS. 208 There is no getting away from the unique root of the public DNS. 210 4. Security Considerations 212 This memo does not introduce any new security issues, but it does 213 attempt to identify some of the problems inherent in a family of 214 recurring technically naive proposals. 216 5. IANA Considerations 218 This memo is not intended to create any new issues for IANA. 220 6. References 222 [DNS-CONCEPTS] Mockapetris, P., "Domain names - concepts and 223 facilities", RFC 1034, November 1987. 225 [DNS-IMPLEMENTATION] Mockapetris, P., "Domain names - implementation 226 and specification", RFC 1035, November 1987. 228 [DNSSEC] Eastlake, D., "Domain Name System Security Extensions", RFC 229 2535, March 1999. 231 7. Author's address: 233 Internet Architecture Board 234 iab@iab.org