contrib/bind9/doc/rfc/rfc2826.txt

   1 \r
   2 \r
   3 \r
   4 \r
   5 \r
   6 \r
   7 Network Working Group                        Internet Architecture Board\r
   8 Request for Comments: 2826                                      May 2000\r
   9 Category: Informational\r
  10 \r
  11 \r
  12               IAB Technical Comment on the Unique DNS Root\r
  13 \r
  14 Status of this Memo\r
  15 \r
  16    This memo provides information for the Internet community.  It does\r
  17    not specify an Internet standard of any kind.  Distribution of this\r
  18    memo is unlimited.\r
  19 \r
  20 Copyright Notice\r
  21 \r
  22    Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
  23 \r
  24 Summary\r
  25 \r
  26    To remain a global network, the Internet requires the existence of a\r
  27    globally unique public name space.  The DNS name space is a\r
  28    hierarchical name space derived from a single, globally unique root.\r
  29    This is a technical constraint inherent in the design of the DNS.\r
  30    Therefore it is not technically feasible for there to be more than\r
  31    one root in the public DNS.  That one root must be supported by a set\r
  32    of coordinated root servers administered by a unique naming\r
  33    authority.\r
  34 \r
  35    Put simply, deploying multiple public DNS roots would raise a very\r
  36    strong possibility that users of different ISPs who click on the same\r
  37    link on a web page could end up at different destinations, against\r
  38    the will of the web page designers.\r
  39 \r
  40    This does not preclude private networks from operating their own\r
  41    private name spaces, but if they wish to make use of names uniquely\r
  42    defined for the global Internet, they have to fetch that information\r
  43    from the global DNS naming hierarchy, and in particular from the\r
  44    coordinated root servers of the global DNS naming hierarchy.\r
  45 \r
  46 1.  Detailed Explanation\r
  47 \r
  48    There are several distinct reasons why the DNS requires a single root\r
  49    in order to operate properly.\r
  50 \r
  51 1.1.  Maintenance of a Common Symbol Set\r
  52 \r
  53    Effective communications between two parties requires two essential\r
  54    preconditions:\r
  55 \r
  56 \r
  57 \r
  58 IAB                          Informational                      [Page 1]\r
  59 \f\r
  60 RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000\r
  61 \r
  62 \r
  63    -  The existence of a common symbol set, and\r
  64 \r
  65    -  The existence of a common semantic interpretation of these\r
  66       symbols.\r
  67 \r
  68    Failure to meet the first condition implies a failure to communicate\r
  69    at all, while failure to meet the second implies that the meaning of\r
  70    the communication is lost.\r
  71 \r
  72    In the case of a public communications system this condition of a\r
  73    common symbol set with a common semantic interpretation must be\r
  74    further strengthened to that of a unique symbol set with a unique\r
  75    semantic interpretation.  This condition of uniqueness allows any\r
  76    party to initiate a communication that can be received and understood\r
  77    by any other party.  Such a condition rules out the ability to define\r
  78    a symbol within some bounded context.  In such a case, once the\r
  79    communication moves out of the context of interpretation in which it\r
  80    was defined, the meaning of the symbol becomes lost.\r
  81 \r
  82    Within public digital communications networks such as the Internet\r
  83    this requirement for a uniquely defined symbol set with a uniquely\r
  84    defined meaning exists at many levels, commencing with the binary\r
  85    encoding scheme, extending to packet headers and payload formats and\r
  86    the protocol that an application uses to interact.  In each case a\r
  87    variation of the symbol set or a difference of interpretation of the\r
  88    symbols being used within the interaction causes a protocol failure,\r
  89    and the communication fails.  The property of uniqueness allows a\r
  90    symbol to be used unambiguously in any context, allowing the symbol\r
  91    to be passed on, referred to, and reused, while still preserving the\r
  92    meaning of the original use.\r
  93 \r
  94    The DNS fulfills an essential role within the Internet protocol\r
  95    environment, allowing network locations to be referred to using a\r
  96    label other than a protocol address.  As with any other such symbol\r
  97    set, DNS names are designed to be globally unique, that is, for any\r
  98    one DNS name at any one time there must be a single set of DNS\r
  99    records uniquely describing protocol addresses, network resources and\r
 100    services associated with that DNS name.  All of the applications\r
 101    deployed on the Internet which use the DNS assume this, and Internet\r
 102    users expect such behavior from DNS names.  Names are then constant\r
 103    symbols, whose interpretation does not specifically require knowledge\r
 104    of the context of any individual party.  A DNS name can be passed\r
 105    from one party to another without altering the semantic intent of the\r
 106    name.\r
 107 \r
 108    Since the DNS is hierarchically structured into domains, the\r
 109    uniqueness requirement for DNS names in their entirety implies that\r
 110    each of the names (sub-domains) defined within a domain has a unique\r
 111 \r
 112 \r
 113 \r
 114 IAB                          Informational                      [Page 2]\r
 115 \f\r
 116 RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000\r
 117 \r
 118 \r
 119    meaning (i.e., set of DNS records) within that domain.  This is as\r
 120    true for the root domain as for any other DNS domain.  The\r
 121    requirement for uniqueness within a domain further implies that there\r
 122    be some mechanism to prevent name conflicts within a domain.  In DNS\r
 123    this is accomplished by assigning a single owner or maintainer to\r
 124    every domain, including the root domain, who is responsible for\r
 125    ensuring that each sub-domain of that domain has the proper records\r
 126    associated with it.  This is a technical requirement, not a policy\r
 127    choice.\r
 128 \r
 129 1.2.  Coordination of Updates\r
 130 \r
 131    Both the design and implementations of the DNS protocol are heavily\r
 132    based on the assumption that there is a single owner or maintainer\r
 133    for every domain, and that any set of resources records associated\r
 134    with a domain is modified in a single-copy serializable fashion.\r
 135    That is, even assuming that a single domain could somehow be "shared"\r
 136    by uncooperating parties, there is no means within the DNS protocol\r
 137    by which a user or client could discover, and choose between,\r
 138    conflicting definitions of a DNS name made by different parties.  The\r
 139    client will simply return the first set of resource records that it\r
 140    finds that matches the requested domain, and assume that these are\r
 141    valid.  This protocol is embedded in the operating software of\r
 142    hundreds of millions of computer systems, and is not easily updated\r
 143    to support a shared domain scenario.\r
 144 \r
 145    Moreover, even supposing that some other means of resolving\r
 146    conflicting definitions could be provided in the future, it would\r
 147    have to be based on objective rules established in advance.  For\r
 148    example, zone A.B could declare that naming authority Y had been\r
 149    delegated all subdomains of A.B with an odd number of characters, and\r
 150    that naming authority Z had been delegated authority to define\r
 151    subdomains of A.B with an even number of characters.  Thus, a single\r
 152    set of rules would have to be agreed to prevent Y and Z from making\r
 153    conflicting assignments, and with this train of actions a single\r
 154    unique space has been created in any case.  Even this would not allow\r
 155    multiple non-cooperating authorities to assign arbitrary sub-domains\r
 156    within a single domain.\r
 157 \r
 158    It seems that a degree of cooperation and agreed technical rules are\r
 159    required in order to guarantee the uniqueness of names.  In the DNS,\r
 160    these rules are established independently for each part of the naming\r
 161    hierarchy, and the root domain is no exception.  Thus, there must be\r
 162    a generally agreed single set of rules for the root.\r
 163 \r
 164 \r
 165 \r
 166 \r
 167 \r
 168 \r
 169 \r
 170 IAB                          Informational                      [Page 3]\r
 171 \f\r
 172 RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000\r
 173 \r
 174 \r
 175 1.3.  Difficulty of Relocating the Root Zone\r
 176 \r
 177    There is one specific technical respect in which the root zone\r
 178    differs from all other DNS zones: the addresses of the name servers\r
 179    for the root zone come primarily from out-of-band information.  This\r
 180    out-of-band information is often poorly maintained and, unlike all\r
 181    other data in the DNS, the out-of-band information has no automatic\r
 182    timeout mechanism.  It is not uncommon for this information to be\r
 183    years out of date at many sites.\r
 184 \r
 185    Like any other zone, the root zone contains a set of "name server"\r
 186    resource records listing its servers, but a resolver with no valid\r
 187    addresses for the current set of root servers will never be able to\r
 188    obtain these records.  More insidiously, a resolver that has a mixed\r
 189    set of partially valid and partially stale out-of-band configuration\r
 190    information will not be able to tell which are the "real" root\r
 191    servers if it gets back conflicting answers; thus, it is very\r
 192    difficult to revoke the status of a malicious root server, or even to\r
 193    route around a buggy root server.\r
 194 \r
 195    In effect, every full-service resolver in the world "delegates" the\r
 196    root of the public tree to the public root server(s) of its choice.\r
 197 \r
 198    As a direct consequence, any change to the list of IP addresses that\r
 199    specify the public root zone is significantly more difficult than\r
 200    changing any other aspect of the DNS delegation chain.   Thus,\r
 201    stability of the system calls for extremely conservative and cautious\r
 202    management of the public root zone: the frequency of updates to the\r
 203    root zone must be kept low, and the servers for the root zone must be\r
 204    closely coordinated.\r
 205 \r
 206    These problems can be ameliorated to some extent by the DNS Security\r
 207    Extensions [DNSSEC], but a similar out-of-band configuration problem\r
 208    exists for the cryptographic signature key to the root zone, so the\r
 209    root zone still requires tight coupling and coordinated management\r
 210    even in the presence of DNSSEC.\r
 211 \r
 212 2.  Conclusion\r
 213 \r
 214    The DNS type of unique naming and name-mapping system may not be\r
 215    ideal for a number of purposes for which it was never designed, such\r
 216    a locating information when the user doesn't precisely know the\r
 217    correct names.  As the Internet continues to expand, we would expect\r
 218    directory systems to evolve which can assist the user in dealing with\r
 219    vague or ambiguous references.  To preserve the many important\r
 220    features of the DNS and its multiple record types -- including the\r
 221    Internet's equivalent of telephone number portability -- we would\r
 222    expect the result of directory lookups and identification of the\r
 223 \r
 224 \r
 225 \r
 226 IAB                          Informational                      [Page 4]\r
 227 \f\r
 228 RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000\r
 229 \r
 230 \r
 231    correct names for a particular purpose to be unique DNS names that\r
 232    are then resolved normally, rather than having directory systems\r
 233    "replace" the DNS.\r
 234 \r
 235    There is no getting away from the unique root of the public DNS.\r
 236 \r
 237 3.  Security Considerations\r
 238 \r
 239    This memo does not introduce any new security issues, but it does\r
 240    attempt to identify some of the problems inherent in a family of\r
 241    recurring technically naive proposals.\r
 242 \r
 243 4.  IANA Considerations\r
 244 \r
 245    This memo is not intended to create any new issues for IANA.\r
 246 \r
 247 5.  References\r
 248 \r
 249    [DNS-CONCEPTS]        Mockapetris, P., "Domain Names - Concepts and\r
 250                          Facilities", STD 13, RFC 1034, November 1987.\r
 251 \r
 252    [DNS-IMPLEMENTATION]  Mockapetris, P., "Domain Names - Implementation\r
 253                          and Specification", STD 13, RFC 1035, November\r
 254                          1987.\r
 255 \r
 256    [DNSSEC]              Eastlake, D., "Domain Name System Security\r
 257                          Extensions", RFC 2535, March 1999.\r
 258 \r
 259 6.  Author's Address\r
 260 \r
 261    Internet Architecture Board\r
 262 \r
 263    EMail: iab@iab.org\r
 264 \r
 265 \r
 266 \r
 267 \r
 268 \r
 269 \r
 270 \r
 271 \r
 272 \r
 273 \r
 274 \r
 275 \r
 276 \r
 277 \r
 278 \r
 279 \r
 280 \r
 281 \r
 282 IAB                          Informational                      [Page 5]\r
 283 \f\r
 284 RFC 2826      IAB Technical Comment on the Unique DNS Root      May 2000\r
 285 \r
 286 \r
 287 7.  Full Copyright Statement\r
 288 \r
 289    Copyright (C) The Internet Society (2000).  All Rights Reserved.\r
 290 \r
 291    This document and translations of it may be copied and furnished to\r
 292    others, and derivative works that comment on or otherwise explain it\r
 293    or assist in its implementation may be prepared, copied, published\r
 294    and distributed, in whole or in part, without restriction of any\r
 295    kind, provided that the above copyright notice and this paragraph are\r
 296    included on all such copies and derivative works.  However, this\r
 297    document itself may not be modified in any way, such as by removing\r
 298    the copyright notice or references to the Internet Society or other\r
 299    Internet organizations, except as needed for the purpose of\r
 300    developing Internet standards in which case the procedures for\r
 301    copyrights defined in the Internet Standards process must be\r
 302    followed, or as required to translate it into languages other than\r
 303    English.\r
 304 \r
 305    The limited permissions granted above are perpetual and will not be\r
 306    revoked by the Internet Society or its successors or assigns.\r
 307 \r
 308    This document and the information contained herein is provided on an\r
 309    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING\r
 310    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING\r
 311    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION\r
 312    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF\r
 313    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.\r
 314 \r
 315 Acknowledgement\r
 316 \r
 317    Funding for the RFC Editor function is currently provided by the\r
 318    Internet Society.\r
 319 \r
 320 \r
 321 \r
 322 \r
 323 \r
 324 \r
 325 \r
 326 \r
 327 \r
 328 \r
 329 \r
 330 \r
 331 \r
 332 \r
 333 \r
 334 \r
 335 \r
 336 \r
 337 \r
 338 IAB                          Informational                      [Page 6]\r
 339 \f\r