idnits 2.17.1 draft-ietf-dnsop-sutld-ps-01.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 408: '... "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 (January 27, 2017) is 2638 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 408, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Unused Reference: 'SDO-ICANN-DAG' is defined on line 855, but no explicit reference was found in the text -- 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-04 Summary: 4 errors (**), 0 flaws (~~), 4 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: July 31, 2017 6 W. Kumari 7 Google 8 January 27, 2017 10 Special-Use Names Problem Statement 11 draft-ietf-dnsop-sutld-ps-01 13 Abstract 15 The Special-Use Domain Names IANA registry policy defined in RFC 6761 16 has been shown through experience to present unanticipated 17 challenges. This memo presents a list, intended to be comprehensive, 18 of the problems that have been identified. In addition it reviews 19 the history of Domain Names and summarizes current IETF publications 20 and some publications from other standards organizations relating to 21 special-use Domain Names. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on July 31, 2017. 40 Copyright Notice 42 Copyright (c) 2017 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Problems associated with Special-Use Domain Names . . . . . . 3 60 4. Existing Practice Regarding SUDNs . . . . . . . . . . . . . . 7 61 4.1. Primary SUDN Documents . . . . . . . . . . . . . . . . . 7 62 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 8 63 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 9 64 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 10 65 4.2. Secondary documents relating to the SUTLDN question . . . 11 66 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 11 67 4.2.2. The .onion Special-Use TLD . . . . . . . . . . . . . 12 68 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 12 69 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 13 70 4.2.5. SSAC Advisory on the Stability of the Domain 71 Namespace . . . . . . . . . . . . . . . . . . . . . . 13 72 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address 73 Synthesis . . . . . . . . . . . . . . . . . . . . . . 13 74 4.2.7. Additional Reserved Top Level Domains . . . . . . . . 13 75 4.3. Summary . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 77 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 78 7. Informative References . . . . . . . . . . . . . . . . . . . 16 79 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 19 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 One of the key services required to use the Internet is name 85 resolution. Name resolution is the process of translating a symbolic 86 name into some object or set of objects to which the name refers, 87 most typically one or more IP addresses. These names are often 88 referred to as Domain Names. When reading this document, care must 89 be taken to not assume that the term Domain Name implies the 90 particular protocol for resolving these names, the Domain Name System 91 [RFC1034]. An excellent presentation on this topic can be found in 92 Domain Names [I-D.lewis-domain-names]. 94 Special-Use Domain Names [RFC6761] created an IANA registry for 95 special-use Domain Names [SDO-IANA-SUDR], defined policies for adding 96 to the registry, and made some suggestions about how that policy 97 might be implemented. Since the publication of RFC 6761, the IETF 98 has been asked to designate several new special-use Domain Names in 99 this registry. During the evaluation process for these special-use 100 Domain Names, the IETF encountered several different sorts of issues. 101 Because of this, the IETF has decided to investigate the problem and 102 decide if and how the RFC 6761 process can be improved, or whether it 103 should be deprecated. 105 This document presents a list, believed to be complete, of the 106 problems associated with the assignment of special-use names. In 107 support of the particular set of problems described here, the 108 document also includes documentation of existing practice as it 109 relates to the use of Domain Names, as well as a brief history of 110 Domain Names, and finally to describe the set of problems that exist 111 as reported by various IETF participants with experience in the 112 various aspects of the problem. 114 2. Terminology 116 For the sake of brevity this document uses a number of abbreviations. 117 These are expanded here: 119 Domain Name A name which serves as input to a name resolution 120 process, for example 'EXAMPLE.ORG'. 122 Domain Namespace The set of all possible Domain Names. 124 SUDN Special Use Domain Name 126 SUTLDN Special-Use Top-Level Domain Name 128 IANA Internet Assigned Numbers Authority 130 ICANN Internet Corporation for Assigned Names and Numbers 132 3. Problems associated with Special-Use Domain Names 134 This section presents a list of problems that have been identified 135 with respect to the assignment of special-use names. Solutions to 136 these problems are out of scope for this document, and will be 137 discussed in separate documents. 139 No assertion is made that any of these problems is more or less 140 important than any other. The point of this is simply to enumerate 141 and briefly describe the problems that have been raised during 142 discussions of the special-use name problem. The degree of detail is 143 intended to be sufficient that that participants in the discussion 144 can agree that the problems they've raised have been adequately 145 described, and no more. These problems should not appear to every 146 reader to all be problems: we intend to cover any problem that any 147 participant considers a problem, not just those problems that 148 everyone agrees are problems. 150 In addition, no assertion is made that all of these problems must be 151 addressed, or that, if we think they should be addressed, the IETF is 152 the organization with competence to address them. While each problem 153 has one or more solutions, the solutions may in some cases be 154 mutually contradictory, or may come with costs that do not justify 155 the benefit that would be obtained from solving them. 157 This is the list of problems: 159 o There are several different types of names in the root of the 160 Domain Namespace: 162 * Reserved by the IETF for technical purposes 164 * Assigned by ICANN to the public DNS root 166 * ICANN Reserved Names; names that may not be applied for as a 167 TLD (see [SDO-ICANN-DAG]Section 2.2.1.2.1, Reserved Names ) 169 * Commandeered for use by other organizations 171 * Not a member of any other category 173 o Both ICANN and the IETF have the authority and formal processes to 174 assign names from the pool of unused names, but no formal 175 coordination process exists. The lack of coordination complicates 176 the management of the root of the Domain Namespace and may lead to 177 conflicts in name assignments [SDO-ICANN-SAC090]. 179 o The term "technical use" in RFC 2860 [RFC2860] is considered by 180 some to be too inclusive. 182 o The IETF and ICANN each have administrative authority over the 183 Domain Namespace. Not all developers of protocols on the internet 184 agree that this authority should reside with the IETF and ICANN. 186 o Although IETF and ICANN nominally have authority over this 187 namespace, neither organization can enforce that authority over 188 any third party who wants to just start using a subset of the 189 namespace. 191 o Organizations do in fact sometimes commandeer subsets of the 192 namespace. Reasons a third party might do this include: 194 * Unaware that a process exists for assigning such names 196 * Intended use is covered by gTLD process, but no gTLD process is 197 ongoing 199 * Intended use is covered by gTLD process, don't want to pay fee 201 * Intended use is covered by some IETF process, but don't want to 202 follow process 204 * Intended use is covered by ICANN or IETF process, but expected 205 outcome is refusal or non-action 207 o There is demand for more than one name resolution protocol for 208 Domain Names, but Domain Names contain no metadata to indicate 209 which protocol to use to resolve them. 211 o When a special-use Domain Name is added to the special-use Domain 212 Names registry, not all software that processes such names will 213 understand the special use of that name. In many cases, name 214 resolution software will use the Domain Name System for resolution 215 of names not known to have a special use. Consequently, any such 216 use will result in queries for special-use names being sent to 217 Domain Name System authoritative servers. These queries may 218 constitute an operational problem for operators of root zone 219 authoritative name servers. 221 o The RFC6761 process is sufficiently uncertain that some protocol 222 developers have assumed they could not get a name assigned; the 223 process of assigning the first new name ('.local') using the RFC 224 6761 process took more than ten years from beginning to end: 225 longer by a factor of ten than any other part of the protocol 226 development process. Other uses of the process have proceeded 227 more smoothly, but there is a reasonably justified perception that 228 using this process is likely to be slow and difficult, with an 229 uncertain outcome. 231 o There is strong resistance within the IETF to assigning Domain 232 Names to resolution systems outside of the DNS, for a variety of 233 reasons: 235 * Requires a mechanism for identifying which of a set of 236 resolution processes is required in order to resolve a 237 particular name. 239 * Assertion of authority: there is a sense that the Domain 240 Namespace is "owned" by the IETF or by ICANN, and so, if a name 241 is claimed outside of that process, the person or entity that 242 claimed that name should suffer some consequence that would, 243 presumably, deter future circumvention of the official process. 245 * More than one name resolution protocol is bad, in the sense 246 that a single protocol is less complicated to implement and 247 deploy. 249 * The semantics of alternative resolution protocols may differ 250 from the DNS protocol; DNS has the concept of RRtypes; other 251 protocols may not support RRtypes, or may support some entirely 252 different data structuring mechanism. 254 * If there is an IETF process through which a name can be 255 assigned at zero cost other than time, this process will be 256 used as an alternative to purchasing the name through ICANN. 258 * The semantics associated with a particular name at the time of 259 its assignment might conflict with other possible semantics and 260 preclude assignment of the name to a better use in the future. 262 * If the IETF assigns a name that some third party or parties 263 believes belongs to them in some way, the IETF could become 264 embroiled in an expensive dispute with those parties. 266 o If there were no process for assigning names for technical use 267 through the IETF, there is a concern that protocols that require 268 such names would not be able to get them. 270 o In cases where the IETF has made assignments through the RFC 6761 271 process, technical mistakes have been made due either to 272 misunderstandings as to the actual process that RFC 6761 specifies 273 (e.g., treating the list of suggested considerations for assigning 274 a name as a set of requirements all of which must be met), or to a 275 failure to follow the process that was defined in RFC 6761. 277 o In principle, the RFC 6761 process could be used to document the 278 existence of Domain Names that are not safe to assign, and provide 279 information on how those names are used in practice. However, 280 attempts to use RFC6761 to accomplish this 281 [I-D.chapin-additional-reserved-tlds] have not been successful. 282 One side effect of this is that any mitigation effect on the root 283 name servers has been missed. 285 o There are several Domain Name TLDs that have been commandeered 286 without due process for a variety of purposes [SDO-ICANN-COLL]. 287 The status of these names need to be clarified and recorded to 288 avoid future disputes about their use. [ Ed note: We note that 289 DNSOP has previously discussed some of these in draft-chapin- 290 additional-reserved-tlds-02, and decided not to adopt the draft - 291 https://www.ietf.org/mail-archive/web/dnsop/current/msg14887.html 292 . The authors are not recommending that DNSOP revisit this, 293 rather that is needs to be addressed in some venue. ] 295 o No mechanism exists for adding a name to the registry without 296 claiming that the IETF is responsible for that name, nor is it 297 possible to state a precedence for the name, e.g. "if ICANN 298 delegates this name, ICANN's delegation takes precedence." 300 o No process exists for checking documents to make sure they don't 301 accidentally assign names (e.g. RFC 7788). 303 o Use of the registry is inconsistent--some SUTLDN RFCs specify 304 registry entries, some don't; some specify delegation, some don't. 306 o There exists no safe, non-process-violating mechanism for ad-hoc 307 assignment of special-use names. 309 o It is generally assumed that protocols that need a special-use 310 name need a human-readable special-use name. This assumption may 311 not be warranted in all cases. 313 o RFC 6761 uses the term "Domain Name" to describe the thing for 314 which special uses are registered. This creates a great deal of 315 confusion because some readers take "Domain Name" to imply the use 316 of the DNS protocol. 318 The problems we have stated here represent the current understanding 319 of the authors of the document as to the complete set of problems 320 that have been identified during discussion by the working group on 321 this topic. The remainder of this document provides additional 322 context that will be needed for reasoning about these problems. 324 4. Existing Practice Regarding SUDNs 326 There are three primary and numerous secondary documents to consider 327 when thinking about the Special-Use Domain Names process. 329 4.1. Primary SUDN Documents 331 The primary documents are considered primary because they directly 332 address the IETF's past thoughts on this topic in a general way, and 333 also because they describe what the IETF does in practice. Only one 334 of these documents is an IETF consensus document. 336 4.1.1. IAB Technical Comment on the Unique DNS Root 338 This document [RFC2826] is not an IETF consensus document, and 339 appears to have been written to address a different problem than the 340 SUDN problem. However, it speaks directly to several of the key 341 issues that must be considered, and of course coming as it does from 342 the IAB, it is rightly treated as having significant authority 343 despite not being an IETF consensus document. 345 This document should be considered required reading for IETF 346 participants who wish to express an informed opinion on the topic of 347 SUDNs. The main points that appear relevant to the special use names 348 problem are: 350 o The Internet requires a globally unique namespace 352 o Private networks may operate private namespaces, but still require 353 that names in the public namespace be globally unique. 355 o The Domain Name System [RFC1035] is not the only protocol that may 356 be used for resolving domain names. 358 o Users cannot be assumed to know how to distinguish between 359 symbolic references that have local meaning and references that 360 have global meaning. Users may therefore share references that 361 incorporate Domain Names with no global meaning (for example, a 362 URL of 'http://mysite.example.corp', where 'example.corp' is a 363 domain used privately and informally as described in 364 [SDO-ICANN-COLL]). 366 o Such references might refer to the object the user intends to 367 share within that user's context, but either refer to some other 368 object any recipient's context, or might not refer to any object 369 at all in a recipient's context. The effect of this is that the 370 user's intended communication will not be able to be understood by 371 the recipients of the communication. 373 o This same problem can also occur simply because a single user 374 copies a name from one context in which it has one meaning, into a 375 different context in which it has a different meaning-- for 376 example copying a '.onion' Domain Name out of a TOR browser, where 377 it has meaning, and pasting this name into an ssh client that 378 doesn't support connecting over TOR. 380 To boil this down even further, we can take the following advice from 381 this document: 383 o Domain Names with unambiguous global meaning are preferable to 384 Domain Names with local meaning which will be ambiguous. 385 Nevertheless both globally-meaningful and locally-special names 386 are in use and must be supported. 388 o At the time of the writing of this document the IAB was of the 389 opinion that there might well be more than one name resolution 390 protocol used to resolve Domain Names. 392 4.1.2. Special-Use Domain Names 394 The second important document is "Special-Use Domain Names" 395 [RFC6761]. RFC6761 represents the current IETF consensus on 396 designating and recording SUDNs. The IETF has experienced problems 397 with the designation process described in RFC6761; these concerns 398 motivate this document. Again, familiarity with RFC6761 is a 399 prerequisite for having an informed opinion on the topic of SUDNs. 401 RFC 6761 defines two aspects of SUDNs: designating a Domain Name to 402 have a special purpose and registering that special use in the 403 Special-Use Domain Names registry. The designation process is 404 defined in a single sentence (RFC6761, section 4): 406 If it is determined that special handling of a name is required in 407 order to implement some desired new functionality, then an IETF 408 "Standards Action" or "IESG Approval" specification [RFC5226] MUST 409 be published describing the new functionality. 411 This sentence implies that any designation of a special-use name is 412 subject to the same open review and consensus process as used to 413 produce and publish all other IETF specifications. 415 The registration process is a purely mechanical process, in which the 416 existence of the newly designated special use name is recorded, with 417 a pointer to a section in the relevant specification document that 418 defines the ways in which special handling is to be applied to the 419 name. 421 RFC6761 provided the process whereby Multicast DNS [RFC6762] 422 designated ".local" as a SUDN and included it in the Special-Use 423 Domain Names registry. It itself also enumerated a set of names that 424 had been previously used or defined to have special uses prior to the 425 publication of RFC6761. Since there had been no registry for these 426 names prior to the publication of RFC 6761, the documents defining 427 these names could not have added them to the registry. 429 There are at least several important points to think of with respect 430 to the RFC6761: 432 o A special-use name may be a name that should be resolved using the 433 DNS protocol with no special handling. An example of this is 'IN- 434 ADDR.ARPA.' 436 o A special-use name may be a name that is resolved using the DNS 437 protocol, requires no special handling in the stub resolver, but 438 requires special handling in the recursive resolver. An example 439 of this would be "10.in-addr.arpa." 441 o A special-use name may be a name that requires special handling in 442 the stub resolver. An example would be a special-use top-level 443 name like '.local' which acts as a signal to indicate that the 444 local stub resolver should use a non-DNS protocol for name 445 resolution. 447 o The current IETF consensus (from a process perspective, not 448 necessarily from the perspective of what would be consensus if the 449 IETF were to attempt to produce a new consensus document) is that 450 all of these purposes for special-use names are valid. 452 The term "stub resolver" in this case does not mean "DNS protocol 453 stub resolver." The stub resolver is the entity within a particular 454 software stack that takes a question about a Domain Name and answers 455 it. One way a stub resolver can answer such a question is using the 456 DNS protocol, but it is in the stub resolver, as we are using the 457 term here, that the decision as to whether to use a protocol, and if 458 so which protocol, or whether to use a local database of some sort, 459 is made. 461 RFC6761 does not limit special-use names to TLDs. However, at 462 present, all special-use names registered in the IANA Special-Use 463 Domain Names registry [SDO-IANA-SUDR] are either intended to be 464 resolved using the DNS protocol, or are top-level domains, or both. 465 That is, at present there exist no special-use names which require 466 special handling by stub resolvers and which are not at the top level 467 of the naming hierarchy. 469 One point to take from this is that there is already a requirement in 470 RFC6762 that when stub resolvers encounter the special label, 471 '.LOCAL' at the top level of a domain name, they can only use the 472 mDNS protocol be used for resolving that Domain Name. 474 4.1.3. MoU Concerning the Technical Work of the IANA 476 There exists a Memorandum of Understanding[RFC2860] between the IETF 477 and ICANN (Internet Corporation for Assigned Names and Numbers) which 478 discusses how names and numbers will be managed through the IANA 479 (Internet Assigned Numbers Authority). This document is important to 480 the discussion of SUDNs because, while it delegates authority for 481 managing the Domain Name System Namespace generally to ICANN, it 482 reserves to the IETF the authority that RFC 6761 formalizes: 484 Note that (a) assignments of Domain Names for technical uses (such 485 as Domain Names for inverse DNS lookup), (b) assignments of 486 specialised address blocks (such as multicast or anycast blocks), 487 and (c) experimental assignments are not considered to be policy 488 issues, and shall remain subject to the provisions of this 489 Section 4. 491 The above text is an addendum to the following: 493 Two particular assigned spaces present policy issues in addition 494 to the technical considerations specified by the IETF: the 495 assignment of Domain Names, and the assignment of IP address 496 blocks. These policy issues are outside the scope of this MOU. 498 In general, then, the assignment of names in the DNS root zone, and 499 the management of the DNS namespace, is a function that is performed 500 by ICANN. However, the MoU specifically exempts domain names 501 assigned for technical use, and uses the example of domains used for 502 inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the 503 special-use Domain Names registry. 505 The point here is not to say what the implications of this statement 506 in the MoU are, but rather to call the reader's attention to the 507 existence of this statement. 509 4.2. Secondary documents relating to the SUTLDN question 511 In addition to these documents, there are several others with which 512 participants in this discussion should be familiar. 514 4.2.1. Multicast DNS 516 Multicast DNS [RFC6762] defines the Multicast DNS protocol, which 517 uses the '.LOCAL' SUTLDN. Section 3 describes the semantics of 518 "multicast DNS names." It is of considerable historical importance 519 to note that the -00 version of this document, an individual 520 submission, was published in July of 2001. This version contains 521 substantially the same text in section 3, and was discussed in the 522 DNSEXT working group at IETF 51 in August of 2001[IETF-PRO-51]. The 523 first version of this document designated '.LOCAL.ARPA' as the 524 special-use name. This idea was strongly opposed by DNSEXT working 525 group participants, and as a result the author eventually switched to 526 using '.LOCAL'. 528 The history of RFC 6762 is documented in substantial detail in 529 Appendix H; some notable milestones include the initial proposal to 530 replace Appletalk's NBP in July 1997, the chartering of the Zeroconf 531 working group in September 1999, assignment of a multicast address 532 for link-local name discovery in April of 2000. A companion 533 requirements document, eventually published as [RFC6760] was first 534 published in September of 2001. 536 The point of mentioning these dates is so that discussions involving 537 the time when the '.LOCAL' domain was first deployed, and the context 538 in which it was deployed, may be properly informed. 540 4.2.2. The .onion Special-Use TLD 542 The .onion Special Use TLD [RFC7686] is important because it is the 543 most recent IETF action on the topic of SUTLDNs; although it does not 544 set new policy, the mere fact of its publication is worth thinking 545 about. 547 Two important points to consider about this document are that: 549 o The IETF gained consensus to publish it 551 o The situation was somewhat forced, both by the fact of its 552 unilateral use by the TOR project without following the RFC 6761 553 process, and because a deadline had been set by the CA/Browser 554 Forum [SDO-CABF-INT] after which all .onion PKI certificates would 555 expire and no new certificates would be issued, unless the .onion 556 SUTLDN were to be recognized by the IETF. 558 4.2.3. Locally Served DNS Zones 560 Locally Served DNS Zones [RFC6303] describes a particular use case 561 for zones that exist by definition, and that are resolved using the 562 DNS protocol, but that cannot have a global meaning, because the host 563 IP addresses they reference are not unique. This applies to a 564 variety of addresses, including Private IPv4 addresses [RFC1918], 565 Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice 566 was first described) and IANA-Reserved IPv4 Prefix for Shared Address 567 Space [RFC6598]. 569 This use case is distinct from the use-case for SUTLDNs like '.local' 570 and '.onion' in that the names are resolved using the DNS protocol 571 (but do require extensions or exceptions to the usual DNS resolution 572 to enforce resolution in a local context rather than the global DNS 573 context). But it shares the problem that such names cannot be 574 assumed either to be unique or to be functional in all contexts for 575 all Internet-connected hosts. 577 4.2.4. Name Collision in the DNS 579 Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by 580 ICANN that attempts to characterize the potential risk to the 581 Internet of adding global DNS delegations for names that were not 582 previously delegated in the DNS, not reserved under any RFC, but also 583 known to be (.home) or surmised to be (.corp) in significant use for 584 special-use-type reasons (local scope DNS, or other resolution 585 protocols altogether). 587 4.2.5. SSAC Advisory on the Stability of the Domain Namespace 589 This document reports on some issues surrounding the conflicting 590 uses, interested parties and processes related to the Domain 591 Namespace. The document recommends the development of collaborative 592 processes among the various interested parties to coordinate their 593 activities related to the Domain Namespace. 595 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 597 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 598 [RFC7050] is an example of a document that successfully used the RFC 599 6761 process to designate '.ipv4only.arpa' as a special-use name; in 600 this case the process worked smoothly and without controversy. 602 Unfortunately, while the IETF process worked smoothly, in the sense 603 that there was little controversy or delay in approving the new use, 604 it did not work correctly: the name 'ipv4only.arpa' was never added 605 to the special-use Domain Names registry. This appears to have 606 happened because the IAB was able to simply add the name to the .ARPA 607 zone, which the IAB administers. This is an illustration of one of 608 the problems that we have with the 6761 process: it is apparently 609 fairly easy to miss the step of adding the name to the registry. 611 4.2.7. Additional Reserved Top Level Domains 613 Additional Reserved Top Level Domains 614 [I-D.chapin-additional-reserved-tlds] is an example of a document 615 that attempted to reserve several TLDs identified by ICANN as 616 particularly at risk for collision as special-use Domain Names with 617 no documented use. This attempt failed. 619 Although this document failed to gain consensus to publish, the need 620 it was intended to fill still exists. Unfortunately, although a fair 621 amount is known about the use of these names, no document exists that 622 documents how they are used, and why it would be a problem to 623 delegate them. Additionally, to the extent that the uses being made 624 of these names are valid, no document exists indicating when it might 625 make sense to use them, and when it would not make sense to use them. 627 RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the 628 default name for name resolution relative to a home network context. 629 Although, as define in RFC 7788, ".home" is a special-use Domain 630 Name, RFC 7788 did not follow the process in RFC 6761 and request the 631 addition of ".home" to the IANA Special-Use Domain Name registry. 632 Additionally, ".home" is an example of an attempt to reuse a Domain 633 Name that has already been commandeered for other purposes 634 [SDO-ICANN-COLL], which further complicates the situation. At the 635 time this document was written, the IETF was developing a solution to 636 this problem. 638 4.3. Summary 640 How names are resolved is ambiguous, in the sense that some names are 641 special-use names that require special handling, and some names can 642 be resolved using the DNS protocol with no special handling. 644 The assignment of Internet Names is not under the sole control of any 645 one organization. IETF has authority in some cases, but only with 646 respect to "technical uses." ICANN at present is the designated 647 administrator of the root zone, but generally not of zones other than 648 the root zone. And neither of these authorities can in any practical 649 sense exclude the practice of ad-hoc use of names. This can be done 650 by any entity that has control over one or more name servers or 651 resolvers, in the context of any hosts and services that that entity 652 operates. It can also be done by authors of software who decide that 653 a special-use name is the right way to indicate the use of an 654 alternate resolution mechanism. 656 5. History 658 Newcomers to the problem of resolving Domain Names may be under the 659 mistaken impression that the DNS sprang, as in the Greek legend of 660 Athena, directly from Paul Mockapetris' forehead. This is not the 661 case. At the time of the writing of the IAB technical document, 662 memories would have been fresh of the evolutionary process that led 663 to the DNS' dominance as a protocol for Domain Name resolution. 665 In fact, in the early days of the Internet, hostnames were resolved 666 using a text file, HOSTS.TXT, which was maintained by a central 667 authority, the Network Information Center, and distributed to all 668 hosts on the Internet using the File Transfer Protocol (FTP) 669 [RFC0959]. The inefficiency of this process is cited as a reason for 670 the development of the DNS [RFC0882] [RFC0883] in 1983. 672 However, the transition from HOSTS.TXT to the DNS was not smooth. 673 For example, Sun Microsystems's Network Information System 674 [CORP-SUN-NIS], at the time known as Yellow Pages, was an active 675 competitor to the DNS, although it failed to provide a complete 676 solution to the global naming problem. 678 Another example was NetBIOS Name Service, also known as WINS 679 [RFC1002]. This protocol was used mostly by Microsoft Windows 680 machines, but also by open source BSD and Linux operating systems to 681 do name resolution using Microsoft's own name resolution protocol. 683 Most modern operating systems can still use the '/etc/hosts' file for 684 name resolution. Many still have a name service switch that can be 685 configured on the host to resolve some domains using NIS or WINS. 686 Most have the capability to resolve names using mDNS by recognizing 687 the special meaning of the '.local' SUTLDN. 689 The Sun Microsystems model of having private domains within a 690 corporate site, while supporting the global Domain Name system for 691 off-site, persisted even after the NIS protocol fell into disuse. 692 Microsoft used to recommend that site administrators use a "private" 693 top-level domain for internal use, and this practice was very much a 694 part of the zeitgeist at the time (see section 5.1 of 695 [SDO-ICANN-COLL] and Appendix G of [RFC6762]). This attitude is at 696 the root of the widespread practice of simply picking an unused top- 697 level domain and using it for experimental purposes, which persists 698 even at the time of writing of this memo. 700 This history is being presented because discussions about special-use 701 names in the IETF often come down to the question of why users of new 702 name resolution protocols choose to use Domain Names, rather than 703 using some other naming concept that doesn't overlap with the 704 namespace that, in modern times is, by default, resolved using the 705 DNS. 707 The answer is that as a consequence of this long history of resolving 708 Domain Names using a wide variety of name resolution systems, Domain 709 Names are required in a large variety of contexts in user interfaces 710 and applications programming interfaces. Any name that appears in 711 such a context is a Domain Name. So developers of new name 712 resolution systems that must work in existing contexts actually have 713 no choice: they must use a special-use Domain Name to segregate a 714 portion of the namespace for use with their system. 716 6. Contributors 718 This document came about as a result of conversations that occurred 719 in the conference hotel lobby, the weekend before IETF 95, when the 720 original author, Ted Lemon, was trying to come up with a better 721 problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul 722 Ebersman and Aaron Falk all made helpful and insightful observations 723 or patiently answered questions. This should not be taken as an 724 indication that any of these folks actually agree with what the 725 document says, but their generosity with time and thought are 726 appreciated in any case. 728 Ralph started out as an innocent bystander, but discussion with him 729 was the key motivating factor in the writing of this document, and he 730 agreed to co-author it without too much arm-twisting. Warren spent a 731 lot of time working with us on this document after it was first 732 published, and joined as an author in order to make sure that the 733 work got finished; without him the -01 and -02 versions might not 734 have happened. 736 This document also owes a great deal to Ed Lewis' excellent work on 737 what a "Domain Name" is [I-D.lewis-domain-names]. 739 7. Informative References 741 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 742 RFC 882, DOI 10.17487/RFC0882, November 1983, 743 . 745 [RFC0883] Mockapetris, P., "Domain names: Implementation 746 specification", RFC 883, DOI 10.17487/RFC0883, November 747 1983, . 749 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 750 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 751 . 753 [RFC1002] NetBIOS Working Group in the Defense Advanced Research 754 Projects Agency, Internet Activities Board, and End-to-End 755 Services Task Force, "Protocol standard for a NetBIOS 756 service on a TCP/UDP transport: Detailed specifications", 757 STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, 758 . 760 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 761 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 762 . 764 [RFC1035] Mockapetris, P., "Domain names - implementation and 765 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 766 November 1987, . 768 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 769 and E. Lear, "Address Allocation for Private Internets", 770 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 771 . 773 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 774 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 775 2000, . 777 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 778 Understanding Concerning the Technical Work of the 779 Internet Assigned Numbers Authority", RFC 2860, DOI 780 10.17487/RFC2860, June 2000, 781 . 783 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 784 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 785 . 787 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 788 6303, DOI 10.17487/RFC6303, July 2011, 789 . 791 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 792 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 793 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 794 2012, . 796 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 797 to Replace the AppleTalk Name Binding Protocol (NBP)", RFC 798 6760, DOI 10.17487/RFC6760, February 2013, 799 . 801 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 802 RFC 6761, DOI 10.17487/RFC6761, February 2013, 803 . 805 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 806 DOI 10.17487/RFC6762, February 2013, 807 . 809 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 810 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 811 7050, DOI 10.17487/RFC7050, November 2013, 812 . 814 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 815 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 816 2015, . 818 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 819 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 820 2016, . 822 [I-D.chapin-additional-reserved-tlds] 823 Chapin, L. and M. McFadden, "Additional Reserved Top Level 824 Domains", draft-chapin-additional-reserved-tlds-02 (work 825 in progress), March 2015. 827 [I-D.lewis-domain-names] 828 Lewis, E., "Domain Names", draft-lewis-domain-names-04 829 (work in progress), September 2016. 831 [SDO-CABF-INT] 832 CA/Browser Forum, "Guidance on the Deprecation of Internal 833 Server Names and Reserved IP Addresses", June 2012, 834 . 836 [SDO-ICANN-COLL] 837 Interisle Consulting Group, LLC, "Name Collisions in the 838 DNS", August 2013, 839 . 842 [SDO-ICANN-SAC090] 843 ICANN Security and Stability Advisory Committee, "SSAC 844 Advisory on the Stability of the Domain Namespace", 845 December 2016, 846 . 849 [SDO-IANA-SUDR] 850 Internet Assigned Numbers Authority, "Special-Use Domain 851 Names registry", October 2015, 852 . 855 [SDO-ICANN-DAG] 856 Internet Assigned Numbers Authority, "Special-Use Domain 857 Names registry", October 2015, 858 . 861 [CORP-SUN-NIS] 862 Sun Microsystems, "Large System and Network 863 Administration", March 1990. 865 [IETF-PRO-51] 866 Internet Engineering Task Force, "Proceedings of the 51st 867 IETF", August 2001, 868 . 870 Appendix A. Change Log. 872 -00 to -01: 874 Improved the terminology. 876 Included reference to SAC090. 878 Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of 879 names. 881 Improved background. 883 Noted that semantics may differ between resolution contexts. 885 Pointer to .home / .corp / .mail, other "toxic" names 887 Readability fixes. 889 -04 to ietf-00 891 Document adopted by WG. 893 Significant changes from CfA integrated, please refer to diff. 895 -03 to -04: 897 o Replaced 'Internet Names' with 'Domain Names' - suggestion by John 898 Levine. 900 -02 to -03: 902 o Readability fixes, small grammar updates. 904 -01 to -02: 906 o Cleaned up the abstract. 908 o Fixed the case of Internet 910 o Reference to Ed Lewis' "Domain Names" 912 o Fleshed out the problems, primarily the coordination, collisions 913 ones. 915 -00 to -01: 917 o Large refactoring, basically a rewrite. Incorporated comments, 918 removed a bunch of unneeded text, etc. 920 Authors' Addresses 922 Ted Lemon 923 Nominum, Inc. 924 800 Bridge Parkway 925 Redwood City, California 94065 926 United States of America 928 Phone: +1 650 381 6000 929 Email: ted.lemon@nominum.com 931 Ralph Droms 933 Email: rdroms.ietf@gmail.com 935 Warren Kumari 936 Google 937 1600 Amphitheatre Parkway 938 Mountain View, CA 94043 939 US 941 Email: warren@kumari.net