idnits 2.17.1 draft-tldr-sutld-ps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 343: '... "Standards Action" or "IESG Approval" specification [RFC5226] MUST...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 16, 2016) is 2769 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 343, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 883 (Obsoleted by RFC 1034, RFC 1035) == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-03 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group T. Lemon 3 Internet-Draft Nominum, Inc. 4 Intended status: Informational R. Droms 5 Expires: March 20, 2017 Cisco, Inc. 6 W. Kumari 7 Google 8 September 16, 2016 10 Special-Use Names Problem Statement 11 draft-tldr-sutld-ps-04 13 Abstract 15 The Special-Use Domain Names registration policy in RFC 6761 has been 16 shown through experience to present unanticipated challenges. This 17 memo presents a list, intended to be comprehensive, of the problems 18 that have been identified. In addition it reviews the history of 19 Domain Names and summarizes current IETF publications and some 20 publications from other standards organizations relating to special- 21 use domain names. 23 [ Ed note: John Levine suggested we use 'Domain Names' instead of 24 'Internet Names'; this is the only change between -03 and -04. 25 Please let us know which term you prefer. ] 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on March 20, 2017. 44 Copyright Notice 46 Copyright (c) 2016 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. Problems associated with Special-Use Internet Names . . . . . 3 64 4. Existing Practice Regarding SUINs . . . . . . . . . . . . . . 6 65 4.1. Primary SUIN Documents . . . . . . . . . . . . . . . . . 6 66 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 6 67 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 7 68 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 9 69 4.2. Secondary documents relating to the SUTLIN question . . . 10 70 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 10 71 4.2.2. The .onion Special-Use TLD . . . . . . . . . . . . . 11 72 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 11 73 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 11 74 4.2.5. Discovery of the IPv6 Prefix Used for IPv6 Address 75 Synthesis . . . . . . . . . . . . . . . . . . . . . . 12 76 4.2.6. Additional Reserved Top Level Domains . . . . . . . . 12 77 4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 79 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14 80 7. Informative References . . . . . . . . . . . . . . . . . . . 14 81 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 17 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17 84 1. Introduction 86 One of the key services required to use the Internet is name 87 resolution. Name resolution is the process of translating a human- 88 readable symbolic name into some object or set of objects to which 89 the name refers, most typically one or more IP addresses. These 90 names are often referred to as domain names. When reading this 91 document, care must be taken to not assume that the term Domain Name 92 implies the particular protocol for resolving these names, the Domain 93 Name System [RFC1034]. An excellent presentation on this topic can 94 be found in Domain Names [I-D.lewis-domain-names]. 96 At the time of this writing, the IETF has recently been asked to 97 allocate several new special-use top-level Domain Names. In 98 evaluating the process for additional special-use top-level Domain 99 Names as documented in Special-Use Domain Names [RFC6761], the IETF 100 encountered several different sorts of issues. Because of this, the 101 IETF has decided to investigate the problem and decide if and how the 102 RFC 6761 process can be improved, or whether it should be deprecated. 104 This document presents a list, believed to be complete, of the 105 problems associated with the allocation of special-use names. In 106 support of the particular set of problems described here, the 107 document also includes documentation of existing practice as it 108 relates to the use of Domain Names, as well as a brief history of 109 domain names, and finally to describe the set of problems that exist 110 as reported by various IETF participants with experience in the 111 various aspects of the problem. 113 2. Terminology 115 For the sake of brevity this document uses a number of abbreviations. 116 These are expanded here: 118 Domain Name A name which serves as input to a host's ordinary name 119 resolution process, for example 'EXAMPLE.ORG'. 121 SUDN Special Use Domain Name 123 SUTLDN Special-Use Top-Level Domain Name 125 IANA Internet Assigned Numbers Authority 127 ICANN Internet Corporation for Assigned Names and Numbers 129 3. Problems associated with Special-Use Internet Names 131 This section presents a list of problems that have been identified 132 with respect to the allocation of special-use names. Solutions to 133 these problems are out of scope. Because of that, problems with 134 solutions to these problems are also out of scope, and will be 135 covered in a separate document. 137 No assertion is made that any of these problems is more or less 138 important than any other. The point of this is simply to enumerate 139 and briefly describe the problems that have been raised during 140 discussions of the special-use name problem. The degree of detail is 141 intended to be sufficient that that participants in the discussion 142 can agree that the problems they've raised have been adequately 143 described, and no more. 145 In addition, no assertion is made that all of these problems must be 146 addressed; while each problem has one or more solutions, the 147 solutions may in some cases be mutually contradictory, or may come 148 with costs that do not justify the benefit that would be obtained 149 from solving them. 151 This is the list of problems: 153 o IETF and ICANN independently have remit to assign names out of the 154 namespace that Domain Names represent; a formal coordination 155 process does not exist. 157 o Although IETF and ICANN nominally have authority over this 158 namespace, neither organization can enforce that authority over 159 any third party who wants to just start using a subset of the 160 namespace. Reasons for doing this may include: 162 * Unaware that a process exists for allocating such names 164 * Intended use is covered by gTLD allocation, but no gTLD 165 allocation is ongoing 167 * Intended use is covered by gTLD allocation, don't want to pay 168 fee 170 * Intended use is covered by some IETF process, but don't want to 171 follow process 173 * Intended use is covered by ICANN or IETF process, but expected 174 outcome is refusal 176 o There is demand for more than one name resolution protocol for 177 Domain Names, but Domain Names contain no metadata to indicate 178 which protocol to use to resolve them. 180 o When a top-level name is used as a means either of marking the 181 rest of a Domain Name for resolution using a protocol other than 182 DNS, or is used for resolution of names with no global meaning, 183 not all software that processes such names will understand the 184 names' special meanings. Consequently, any such use results in 185 queries for those names being sent to authoritative servers. 187 o The RFC6761 process is sufficiently uncertain that some protocol 188 developers have assumed they could not get a name assigned; the 189 process of assigning the first new name following RFC 6761 took 190 more than ten years from beginning to end: longer by a factor of 191 ten than any other part of the protocol development process. 192 Other uses of the process have proceeded more smoothly, but there 193 is a reasonably justified perception that using this process is 194 likely to be slow and difficult, with an uncertain outcome. 196 o There is strong resistance within the IETF to assigning names to 197 things outside of the DNS, for a variety of reasons: 199 * Requires a mechanism for identifying which of a set of 200 resolution processes is required in order to resolve a 201 particular name. 203 * Assertion of authority: there is a sense that the namespace is 204 "owned" by the IETF or by ICANN, and so, if a name is allocated 205 outside of that process, the person or entity that allocated 206 that name should suffer some consequence that would, 207 presumably, deter future circumvention of the official process. 209 * More than one name resolution protocol is bad, in the sense 210 that a single protocol is less complicated to implement and 211 deploy. 213 * The semantics of alternative resolution protocols may differ 214 from the DNS protocol; DNS has the concept of RRtypes; other 215 protocols may not support RRtypes, or may support some entirely 216 different data structuring mechanism. 218 * If there is an IETF process through which a name can be 219 allocated at zero cost other than time, this process will be 220 used as an alternative to allocating the name through ICANN. 222 * Some names that might be allocated would be sufficiently 223 generic that other legitimate uses of those names would overlap 224 with a proposed use, so that assigning the name would preclude 225 some future, better use of it. 227 * If the IETF allocates a name that some third party or parties 228 believes belongs to them in some way, the IETF could become 229 embroiled in an expensive dispute with those parties. 231 o In cases where the IETF has made assignments through the RFC 6761 232 process, technical mistakes have been made due either to 233 insufficiently well-defined process or to a failure to follow the 234 process that was defined in RFC 6761. 236 o In principal, the RFC 6761 process could be used to document the 237 existence of domain names that are not safe to allocate, and 238 provide information on how those names are used in practice. 239 However, attempts to use RFC6761 to accomplish this 240 [I-D.chapin-additional-reserved-tlds] have not been successful. 242 o No process exists for checking documents to make sure they don't 243 accidentally assign names (e.g. RFC 7788). 245 o Use of the registry is inconsistent--some SUTLIN RFCs specify 246 registry entries; some don't; some specify delegation, some don't. 248 o There exists no safe, non-process-violating mechanism for ad-hoc 249 allocation of special-use names. 251 o RFC 6761 uses the term "Domain Name" to describe the thing for 252 which special uses are registered. This creates a great deal of 253 confusion because some readers take "Domain Name" to imply the use 254 of the DNS protocol. 256 The problems we have stated here represent the current understanding 257 of the authors of the document as to the complete set of problems 258 that have been identified during discussion by the working group on 259 this topic. The remainder of this document provides additional 260 context that will be needed for reasoning about these problems. 262 4. Existing Practice Regarding SUINs 264 There are three primary and numerous secondary documents to consider 265 when thinking about the Special-Use Domain Names process. 267 4.1. Primary SUIN Documents 269 The primary documents are considered primary because they directly 270 address the IETF's past thoughts on this topic in a general way, and 271 also because they describe what the IETF does in practice. Only one 272 of these documents is an IETF consensus document. 274 4.1.1. IAB Technical Comment on the Unique DNS Root 276 This document [RFC2826] is not an IETF consensus document, and 277 appears to have been written to address a different problem than the 278 SUDN problem. However, it speaks directly to several of the key 279 issues that must be considered, and of course coming as it does from 280 the IAB, it is rightly given with a great deal of authority despite 281 not being an IETF consensus document. 283 This document should be considered required reading for IETF 284 participants who wish to express an informed opinion on the topic of 285 SUDNs. The main points that appear relevant to the specal use names 286 problem are: 288 o The Internet requires a globally unique namespace 289 o Private networks may operate private namespaces, but still require 290 that names in the public namespace be globally unique. 292 o The Domain Name System [RFC1035] is not the only protocol that may 293 be used for resolving domain names. 295 o Users cannot be assumed to know how to distinguish between symbols 296 that have local meaning and symbols that have global meaning. 297 Users may therefore share symbols that incorporate domain names 298 with no global meaning (for example, a URL of 299 'http://mysite.example.corp', where 'example.corp' is a domain 300 allocated privately and informally as described in 301 [SDO-ICANN-COLL]). Such symbols might refer to the object the 302 user intends to share within that user's context, but either refer 303 to some other object any recipient's context, or might not refer 304 to any object at all in a recipient's context. The effect of this 305 is that the user's intended communication will not be able to be 306 understood by the recipients of the communication. This same 307 problem can also occur simply because a single user copies a name 308 from one context in which it has one meaning, into a different 309 context in which it has a different meaning-- for example copying 310 a '.onion' Domain Name out of a TOR browser, where it has meaning, 311 and pasting this name into an ssh client that doesn't support 312 connecting over TOR. [TODO: Consider "labels" instead of 313 "symbols".] 315 To boil this down even further, we can take the following advice from 316 this document: 318 o Domain names with unambiguous global meaning are preferable to 319 domain names with local meaning which will be ambiguous. 320 Nevertheless both globally-meaningful and locally-special names 321 are in use and must be supported. 323 o At the time of the writing of this document the IAB was of the 324 opinion that there might well be more than one name resolution 325 protocol used to resolve domain names. 327 4.1.2. Special-Use Domain Names 329 The second important document is Special-Use Domain Names [RFC6761]. 330 RFC6761 represents the current IETF consensus on designating and 331 recording SUDNs. The IETF has experienced problems with the 332 designation process described in RFC6761; these concerns motivate 333 this document. Again, familiarity with RFC6761 is a prerequisite for 334 having an informed opinion on the topic of SUDNs. 336 RFC 6761 defines two aspects of SUDNs: designating a domain name to 337 have a special purpose and registering that special use in the 338 Special-Use Domain Names registry. The designation process is 339 defined in a single sentence (RFC6761, section 4): 341 If it is determined that special handling of a name is required in 342 order to implement some desired new functionality, then an IETF 343 "Standards Action" or "IESG Approval" specification [RFC5226] MUST 344 be published describing the new functionality. 346 This sentence implies that any designation of a special-use name is 347 subject to the same open review and consensus process as used to 348 produce and publish all other IETF specifications. 350 The registration process is a purely mechanical process, in which the 351 existence of the newly designated special use name is recorded, with 352 a pointer to a section in the relevant specification document that 353 defines the ways in which special handling is to be applied to the 354 name. 356 RFC6761 provided the process wherebyMulticast DNS [RFC6762]designated 357 ".local" as a special-use name and included it in the Special-Use 358 Names registry. It itself also enumerated a set of names that had 359 been previously used or defined to have special uses prior to the 360 publication of RFC6761. Since there had been no registry for these 361 names prior to the publication of RFC 6761, the documents defining 362 these names could not have added them to the registry. 364 There are at least several important points to think of with respect 365 to the RFC6761: 367 o A special-use name may be a name that should be resolved using the 368 DNS protocol with no special handling. An example of this is 369 .ARPA. 371 o A special-use name may be a name that is resolved using the DNS 372 protocol, requires no special handling in the stub resolver, but 373 requires special handling in the recursive resolver. An example 374 of this would be "10.in-addr.arpa." 376 o A special-use name may be name that requires special handling in 377 the stub resolver. An example would be a special-use top-level 378 name like '.local' which acts as a signal to indicate that the 379 local stub resolver should use a non-DNS protocol for name 380 resolution. 382 o The current IETF consensus (from a process perspective, not 383 necessarily from the perspective of what would be consensus if the 384 IETF were to attempt to produce a new consensus document) is that 385 these purposes for special-use names are valid. [TODO: "Both" 386 implies that there are only two applications; the above bullet 387 points outline 3...] 389 The term "stub resolver" in this case does not mean "DNS protocol 390 stub resolver." The stub resolver is the entity within a particular 391 software stack that takes a question about a Domain name and answers 392 it. One way a stub resolver can answer such a question is using the 393 DNS protocol, but it is in the stub resolver, as we are using the 394 term here, that the decision as to whether to use a protocol, and if 395 so which protocol, or whether to use a local database of some sort, 396 is made. 398 RFC6761 does not limit special-use names to TLDs. However, at 399 present, all special-use names registered in the IANA Special-Use 400 Domain Names registry [SDO-IANA-SUDR] are either intended to be 401 resolved using the DNS protocol, or are top-level domains, or both. 402 That is, at present there exist no special-use names which require 403 special handling by stub resolvers and which are not at the top level 404 of the naming hierarchy. 406 This does mean, however, that at present, RFC6762 requires the use of 407 a special label, '.LOCAL', to indicate to stub resolvers that 408 mDNS[RFC6762] be used to resolve names under that label. 410 4.1.3. MoU Concerning the Technical Work of the IANA 412 There exists a Memorandum of Understanding[RFC2860] between the IETF 413 and ICANN (Internet Corporation for Assigned Names and Numbers) which 414 discusses how names and numbers will be managed through the IANA 415 (Internet Assigned Numbers Authority). This document is important to 416 the discussion of SUDNs because, while it delegates authority for 417 managing the Domain Name System Namespace generally to ICANN, it 418 reserves to the IETF the authority that RFC 6761 formalizes: 420 Note that (a) assignments of domain names for technical uses (such 421 as domain names for inverse DNS lookup), (b) assignments of 422 specialised address blocks (such as multicast or anycast blocks), 423 and (c) experimental assignments are not considered to be policy 424 issues, and shall remain subject to the provisions of this 425 Section 4. 427 The above text is an addendum to the following: 429 Two particular assigned spaces present policy issues in addition 430 to the technical considerations specified by the IETF: the 431 assignment of domain names, and the assignment of IP address 432 blocks. These policy issues are outside the scope of this MOU. 434 In general, then, the assignment of names in the DNS root zone, and 435 the management of the DNS namespace, is a function that is performed 436 by ICANN. However, the MoU specifically exempts domain names 437 assigned for technical use, and uses the example of 'IN-ADDR.ARPA' 438 and 'IP6.ARPA' to illustrate. Both of these names are in the RFC 439 6761 registry. 441 The point here is not to say what the implications of this statement 442 in the MoU are, but rather to call the reader's attention to the 443 existence of this statement. 445 4.2. Secondary documents relating to the SUTLIN question 447 In addition to these documents, there are several others with which 448 participants in this discussion should be familiar. 450 4.2.1. Multicast DNS 452 Multicast DNS [RFC6762] defines the Multicast DNS protocol, which 453 uses the '.LOCAL' SUTLDN. Section 3 describes the semantics of 454 "multicast DNS names." It is of considerable historical importance 455 to note that the -00 version of this document, an individual 456 submission, was published in July of 2001. This version contains 457 substantially the same text in section 3, and was discussed in the 458 DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The 459 first version of this document designated '.LOCAL.ARPA' as the 460 special-use name. This idea was strongly opposed by DNSEXT working 461 group participants, and as a result the author eventually switched to 462 using '.LOCAL'. 464 The history of RFC 6762 is documented in substantial detail in 465 Appendix H; some notable milestones include the initial proposal to 466 replace Appletalk's NBP in July 1997, the chartering of the Zeroconf 467 working group in September 1999, allocation of a multicast address 468 for link-local name discovery in April of 2000. A companion 469 requirements document, eventually published as [RFC6760] was first 470 published in September of 2001. 472 The point of mentioning these dates is so that discussions involving 473 the time when the '.LOCAL' domain was first deployed, and the context 474 in which it was deployed, may be properly informed. 476 4.2.2. The .onion Special-Use TLD 478 The .onion Special Use TLD [RFC7686] is important because it is the 479 most recent IETF action on the topic of SUTLDNs; although it does not 480 set new policy, the mere fact of its publication is worth thinking 481 about. 483 Two important points to consider about this document are that: 485 o The IETF gained consensus to publish it 487 o The situation was somewhat forced, both by the fact of its 488 unilateral allocation by the TOR project without following the RFC 489 6761 process, and because a deadline had been set by the CA/ 490 Browser Forum [SDO-CABF-INT] after which all .onion PKI 491 certificates would expire and no new certificates would be issued, 492 unless the .onion SUTLDN were to be recognized by the IETF. 494 4.2.3. Locally Served DNS Zones 496 Locally Served DNS Zones [RFC6303] describes a particular use case 497 for zones that exist by definition, and that are resolved using the 498 DNS protocol, but that cannot have a global meaning, because the host 499 IP addresses they reference are not unique. This applies to a 500 variety of addresses, including Private IPv4 addresses [RFC1918], 501 Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice 502 was first described) and IANA-Reserved IPv4 Prefix for Shared Address 503 Space [RFC6598]. 505 This use case is distinct from the use-case for SUTLDNs like '.local' 506 and '.onion' in that the names are resolved using the DNS protocol. 507 But it shares the problem that such names cannot be assumed either to 508 be unique or to be functional in all contexts for all Internet- 509 connected hosts. 511 4.2.4. Name Collision in the DNS 513 Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by 514 ICANN that attempts to characterize the potential risk to the 515 Internet of adding global DNS delegations for names that were not 516 previously delegated in the DNS, not reserved under any RFC, but also 517 known to be (.local) or surmised to be (.corp) in significant use for 518 special-use-type reasons (local scope DNS, or other resolution 519 protocols altogether). 521 4.2.5. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 523 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 524 [RFC7050] is an example of a document that successfully used the RFC 525 6761 process to designate '.ipv4only.arpa' as a special-use name; in 526 this case the process worked smoothly and without controversy. 528 4.2.6. Additional Reserved Top Level Domains 530 Additional Reserved Top Level Domains 531 [I-D.chapin-additional-reserved-tlds] is an example of a document 532 that attempted to reserve several TLDs identified by ICANN as 533 particularly at risk for collision as special-use domain names with 534 no documented use. This attempt failed. 536 Although this document failed to gain consensus to publish, the need 537 it was intended to fill still exists. Unfortunately, although a fair 538 amount is known about the use of these names, no document exists that 539 documents how they are used, and why it would be a problem to 540 allocate them. Additionally, to the extent that the uses being made 541 of these names are valid, no document exists indicating when it might 542 make sense to use them, and when it would not make sense to use them 543 (the simplest version of this document would of course say "never use 544 them." If that were the IETF consensus, that would be a good reason 545 not to bother to publish the document. 547 4.3. Summary 549 The assignment of Internet Names is not under the sole control of any 550 one organization. ICANN has authority in many cases, and could be 551 considered in some sense the default. IETF has authority in other 552 cases, but only with respect to protocol development. And neither of 553 these authorities can in any practical sense exclude the practice of 554 ad-hoc allocation of names, which can be done by any entity that has 555 control over one or more name servers or resolvers, in the context of 556 any hosts and services that that entity operates. 558 5. History 560 Newcomers to the problem of resolving domain names may be under the 561 mistaken impression that the DNS sprang, as in the Greek legend of 562 Athena, directly from Paul Mockapetris' forehead. This is not the 563 case. At the time of the writing of the IAB technical document, 564 memories would have been fresh of the evolutionary process that led 565 to the DNS' dominance as a protocol for domain name resolution. 567 In fact, in the early days of the Internet, hostnames were resolved 568 using a text file, HOSTS.TXT, which was maintained by a central 569 authority, the Network Information Center, and distributed to all 570 hosts on the Internet using the File Transfer Protocol (FTP) 571 [RFC0959]. The inefficiency of this process is cited as a reason for 572 the development of the DNS [RFC0882] [RFC0883] in 1983. 574 However, the transition from HOSTS.TXT to the DNS was not smooth. 575 For example, Sun Microsystems's Network Information System 576 [CORP-SUN-NIS], at the time known as Yellow Pages, was an active 577 competitor to the DNS, although it failed to provide a complete 578 solution to the global naming problem. 580 Another example was NetBIOS Name Service, also known as WINS 581 [RFC1002]. This protocol was used mostly by Microsoft Windows 582 machines, but also by open source BSD and Linux operating systems to 583 do name resolution using Microsoft's own name resolution protocol. 585 Most modern operating systems can still use the '/etc/hosts' file for 586 name resolution. Many still have a name service switch that can be 587 configured on the host to resolve some domains using NIS or WINS. 588 Most have the capability to resolve names using mDNS by recognizing 589 the special meaning of the '.local' SUTLDN. 591 The Sun Microsystems model of having private domains within a 592 corporate site, while supporting the global domain name system for 593 off-site persisted even after the NIS protocol fell into disuse. 594 Microsoft used to recommend that site administrators allocate a 595 "private" top-level domain for internal use, and this practice was 596 very much a part of the zeitgeist at the time. This attitude is the 597 root of the widespread practice of simply picking an unused top-level 598 domain and using it for experimental purposes, which persists even at 599 the time of writing of this memo. 601 This history is being presented because discussions about special-use 602 names in the IETF often come down to the question of why users of new 603 name resolution protocols choose to use Domain names, rather than 604 using some other naming concept that doesn't overlap with the 605 namespace that, in modern times is, by default, resolved using the 606 DNS. 608 The answer is that as a consequence of this long history of resolving 609 Domain Names, Domain Names appear in a large variety of contexts in 610 user interfaces applications programming interfaces. Any name that 611 appears in such a context is a Domain Name. What this means is that 612 Domain Names have a highly privileged status in deployed software. 613 Proposals to change that will be almost possible to get adopted in a 614 useful or consistent way. And since in most operating systems, 615 mechanisms already exist for implementing special handling for some 616 Domain Names, from a practical perspective the only way to achieve 617 the goals of any new name resolution protocol is through the use of 618 special-use Domain Names. 620 6. Contributors 622 This document came about as a result of conversations that occurred 623 in the lobby, the weekend before IETF 95. Stuart Cheshire, Mark 624 Andrews, David Conrad, Paul Ebersman and Aaron Falk all made helpful 625 and insightful observations or patiently answered questions. This 626 should not be taken as an indication that any of these folks actually 627 agree with what the document says, but their generosity with time and 628 thought are appreciated in any case. 630 Ralph started out as an innocent bystander, but discussion with him 631 was the key motivating factor in the writing of this document, and he 632 agreed to co-author it without too much arm-twisting. Warren spent a 633 lot of time working with me on this document after it was first 634 published, and joined as an author in order to make sure that the 635 work got finished; without him the -01 and -02 versions might not 636 have happened. 638 And this document owes a great deal to Ed Lewis' excellent work on 639 what a "domain name" is [I-D.lewis-domain-names]. 641 7. Informative References 643 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 644 RFC 882, DOI 10.17487/RFC0882, November 1983, 645 . 647 [RFC0883] Mockapetris, P., "Domain names: Implementation 648 specification", RFC 883, DOI 10.17487/RFC0883, November 649 1983, . 651 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 652 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 653 . 655 [RFC1002] NetBIOS Working Group in the Defense Advanced Research 656 Projects Agency, Internet Activities Board, and End-to-End 657 Services Task Force, "Protocol standard for a NetBIOS 658 service on a TCP/UDP transport: Detailed specifications", 659 STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, 660 . 662 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 663 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 664 . 666 [RFC1035] Mockapetris, P., "Domain names - implementation and 667 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 668 November 1987, . 670 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 671 and E. Lear, "Address Allocation for Private Internets", 672 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 673 . 675 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 676 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 677 2000, . 679 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 680 Understanding Concerning the Technical Work of the 681 Internet Assigned Numbers Authority", RFC 2860, DOI 682 10.17487/RFC2860, June 2000, 683 . 685 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 686 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 687 . 689 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 690 6303, DOI 10.17487/RFC6303, July 2011, 691 . 693 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 694 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 695 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 696 2012, . 698 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 699 to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 700 6760, DOI 10.17487/RFC6760, February 2013, 701 . 703 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 704 RFC 6761, DOI 10.17487/RFC6761, February 2013, 705 . 707 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 708 DOI 10.17487/RFC6762, February 2013, 709 . 711 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 712 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 713 7050, DOI 10.17487/RFC7050, November 2013, 714 . 716 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 717 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 718 2015, . 720 [I-D.chapin-additional-reserved-tlds] 721 Chapin, L. and M. McFadden, "Additional Reserved Top Level 722 Domains", draft-chapin-additional-reserved-tlds-02 (work 723 in progress), March 2015. 725 [I-D.lewis-domain-names] 726 Lewis, E., "Domain Names", draft-lewis-domain-names-03 727 (work in progress), June 2016. 729 [SDO-CABF-INT] 730 CA/Browser Forum, "Guidance on the Deprecation of Internal 731 Server Names and Reserved IP Addresses", June 2012, 732 . 734 [SDO-ICANN-COLL] 735 Interisle Consulting Group, LLC, "Name Collisions in the 736 DNS", August 2013, 737 . 740 [SDO-IANA-SUDR] 741 Internet Assigned Numbers Authority, "Special-Use Domain 742 Names registry", October 2015, 743 . 746 [CORP-SUN-NIS] 747 Sun Microsystems, "Large System and Network 748 Administration", March 1990. 750 [IETF-PRO-51] 751 Internet Engineering Task Force, "Proceedings of the 51st 752 IETF", August 2001, 753 . 755 Appendix A. Change Log. 757 -03 to -04: 759 o Replaced 'Internet Names' with 'Domain Names' - suggestion by John 760 Levine. 762 -02 to -03: 764 o Readability fixes, small grammar updates. 766 -01 to -02: 768 o Cleaned up the abstract. 770 o Fixed the case of Internet 772 o Reference to Ed Lewis' "domain names" 774 o Fleshed out the problems, primarily the coordination, collisions 775 ones. 777 -00 to -01: 779 o Large refactoring, basically a rewrite. Incorporated comments, 780 removed a bunch of unneeded text, etc. 782 Authors' Addresses 784 Ted Lemon 785 Nominum, Inc. 786 800 Bridge Parkway 787 Redwood City, California 94065 788 United States of America 790 Phone: +1 650 381 6000 791 Email: ted.lemon@nominum.com 793 Ralph Droms 794 Cisco, Inc. 796 Email: rdroms.ietf@gmail.com 797 Warren Kumari 798 Google 799 1600 Amphitheatre Parkway 800 Mountain View, CA 94043 801 US 803 Email: warren@kumari.net