idnits 2.17.1 draft-ietf-dnsop-sutld-ps-03.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 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 500: '... "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 (March 13, 2017) is 2594 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 500, 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) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-05 Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 4 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: September 14, 2017 6 W. Kumari 7 Google 8 March 13, 2017 10 Special-Use Domain Names Problem Statement 11 draft-ietf-dnsop-sutld-ps-03 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 organizations relating to Special- 21 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 September 14, 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 . . . . . . 4 60 4. Existing Practice Regarding Special-Use Domain Names . . . . 9 61 4.1. Primary Special-Use Domain Name Documents . . . . . . . . 9 62 4.1.1. IAB Technical Comment on the Unique DNS Root . . . . 9 63 4.1.2. Special-Use Domain Names . . . . . . . . . . . . . . 11 64 4.1.3. MoU Concerning the Technical Work of the IANA . . . . 12 65 4.1.4. Liaison Statement on Technical Use of Domain 66 Names . . . . . . . . . . . . . . . . . . . . . . . . 13 67 4.2. Secondary documents relating to the Special-Use 68 Domain Name question . . . . . . . . . . . . . . . . . . 14 69 4.2.1. Multicast DNS . . . . . . . . . . . . . . . . . . . . 14 70 4.2.2. The .onion Special-Use Top-Level Domain Name . . . . 14 71 4.2.3. Locally Served DNS Zones . . . . . . . . . . . . . . 15 72 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 15 73 4.2.5. SSAC Advisory on the Stability of the Domain 74 Namespace . . . . . . . . . . . . . . . . . . . . . . 15 75 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address 76 Synthesis . . . . . . . . . . . . . . . . . . . . . . 16 77 4.2.7. Additional Reserved Top Level Domains . . . . . . . . 16 78 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9. Informative References . . . . . . . . . . . . . . . . . . . 19 83 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 22 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 86 1. Introduction 88 One of the key services required to use the Internet is name 89 resolution. Name resolution is the process of translating a symbolic 90 name into some object or set of objects to which the name refers, 91 most typically one or more IP addresses. These names are often 92 referred to as Domain Names. When reading this document, care must 93 be taken to not assume that the term Domain Name implies the use of 94 the Domain Name System [RFC1034] for resolving these names. An 95 excellent presentation on this topic can be found in Domain Names 96 [I-D.lewis-domain-names]. 98 Special-Use Domain Names [RFC6761] created an IANA registry for 99 Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding 100 to the registry, and made some suggestions about how those policies 101 might be implemented. Since the publication of RFC 6761, the IETF 102 has been asked to designate several new Special-Use Domain Names in 103 this registry. During the evaluation process for these Special-Use 104 Domain Names, the IETF encountered several different sorts of issues. 105 Because of this, the IETF has decided to investigate the problem and 106 decide if and how the RFC 6761 process can be improved, or whether it 107 should be deprecated. 109 Based on current ICANN and IETF practice, including RFC 6761, there 110 are several different types of names in the root of the Domain 111 Namespace: 113 o Reserved by the IETF for technical purposes 115 o Assigned by ICANN to the public DNS root; some names reserved by 116 the IETF for technical purposes may appear in the Global DNS root 117 for reasons pertaining to the operation of the DNS 119 o ICANN Reserved Names; names that may not be applied for as TLDs 120 (see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names, 121 Section 2.2.1.4.1, Treatment of Country or Territory Names, et 122 al.) 124 o Used by other organizations without following established 125 processes 127 o Names that are unused and are available for assignment to one of 128 the previous categories 130 This document presents a list, believed to be complete, of the 131 problems associated with the assignment of Special-Use Domain Names. 132 In support of its analysis of the particular set of issues described 133 here, the document also includes descriptions of existing practice as 134 it relates to the use of domain names, a brief history of domain 135 names, and some observations by various IETF participants who have 136 experience with various aspects of the current situation. 138 2. Terminology 140 This document uses the terminology from RFC 7719 [RFC7719]. Other 141 terms used in this document are defined here: 143 Domain Name This document uses the term "Domain Name" as defined in 144 section 2 of RFC 7719 [RFC7719]. 146 Domain Namespace The set of all possible Domain Names. 148 Special-Use Domain Name A Domain Name listed in the Special-Use 149 Domain Names registry. 151 For the sake of brevity this document uses some abbreviations, which 152 are expanded here: 154 IANA Internet Assigned Numbers Authority 156 ICANN Internet Corporation for Assigned Names and Numbers 158 TLD Top-Level Domain, as defined in in section 2 of RFC 7719 159 [RFC7719] 161 gTLD Generic Top-Level Domain, as defined in in section 2 of RFC 162 7719 [RFC7719] 164 3. Problems associated with Special-Use Domain Names 166 This section presents a list of problems that have been identified 167 with respect to the assignment of Special-Use Domain Names. 168 Solutions to these problems, including their costs or tradeoffs, are 169 out of scope for this document. They will be covered in a separate 170 document. New problems that might be created in the process of 171 solving problems described in this document are also out of scope: 172 these problems are expected to be addressed in the process of 173 evaluating potential solutions. 175 Special-Use Domain Names exist to solve a variety of problems. This 176 document has two goals: enumerate all of the problems that have been 177 identified to which Special-Use Domain Names are a solution and 178 enumerate all of the problems that have been raised in the process of 179 trying to use RFC 6761 as it was intended. As some of those problems 180 may fall into both categories, this document makes no attempt to 181 categorize the problems. 183 There is a broad diversity of opinion about this set of problems. 184 Not every participant agrees that each of the problems enumerated in 185 this document is actually a problem. This document takes no position 186 on the relative validity of the various problems that have been 187 enumerated. Its focused purposes are to enumerate those problems, 188 provide the reader with context for thinking about them and provide a 189 context for future discussion of solutions. 191 This is the list of problems: 193 o No formal coordination process exists between the IETF and ICANN 194 as they follow their respective name assignment processes (see 195 Section 4.1.3). The lack of coordination complicates the 196 management of the root of the Domain Namespace and could lead to 197 conflicts in name assignments [SDO-ICANN-SAC090]. 199 o There is no explicit scoping as to what can constitute a 200 "technical use" [RFC2860] and what cannot, and there is also no 201 consensus within the IETF as to what this term means. 203 o Not all developers of protocols on the internet agree that 204 authority over the entire Domain Namespace should reside solely 205 with the IETF and ICANN. 207 o Although IETF and ICANN nominally have authority over this 208 namespace, neither organization can enforce that authority over 209 any third party who wants to just start using a subset of the 210 namespace. Such parties may observe that the IETF has never 211 asserted control or authority over what protocols are "allowed" on 212 the internet, and that the principle of "permissionless 213 innovation" suggests there should be a way for people to include 214 new uses of domain names in new protocols and applications. 216 o Organizations do in fact sometimes use subsets of the Domain 217 Namespace without following established processes. Reasons a 218 third party might do this include: 220 * Unaware that a process exists for assigning such names 222 * Intended use is covered by gTLD process [SDO-ICANN-DAG], but no 223 gTLD process is ongoing 225 * Intended use is covered by gTLD process, but the third party 226 doesn't want to pay a fee 228 * Intended use is covered by some IETF process, but the third 229 party doesn't want to follow the process 231 * Intended use is covered by ICANN or IETF process, but third 232 party expects that the outcome will be refusal or non-action 234 * Unaware that a name intended to be used only locally may 235 nevertheless leak 237 * Unaware that a name used locally with informal allocation may 238 subsequently be allocated formally, creating operational 239 problems 241 o There is demand for more than one name resolution protocol for 242 Domain Names. Domain Names contain no metadata to indicate which 243 protocol to use to resolve them. Domain name resolution APIs do 244 not provide a way to specify which protocol to use. 246 o When a Special-Use Domain Name is added to the Special-Use Domain 247 Names registry, not all software that processes such names will 248 understand the special use of that name. In many cases, name 249 resolution software will use the Domain Name System for resolution 250 of names not known to have a special use. Consequently, any such 251 use will result in queries for Special-Use Domain Names being sent 252 to Domain Name System authoritative servers. These queries may 253 constitute an operational problem for operators of root zone 254 authoritative name servers. These queries may also inadvertently 255 reveal private information through the contents of the query, 256 which is a privacy consideration. 258 o The RFC 6761 process is sufficiently uncertain that some protocol 259 developers have assumed they could not get a name assigned; the 260 process of assigning the first new name ('.local') using the RFC 261 6761 process took more than ten years from beginning to end: 262 longer by a factor of ten than any other part of the protocol 263 development process (largely because this ten years included time 264 to develop the process as well as use it). Other uses of the 265 process have proceeded more smoothly, but there is a reasonably 266 justified perception that using this process is likely to be slow 267 and difficult, with an uncertain outcome. 269 o There is strong resistance within the IETF to assigning Domain 270 Names to resolution systems outside of the DNS, for a variety of 271 reasons: 273 * Requires a mechanism for identifying which of a set of 274 resolution processes is required in order to resolve a 275 particular name. 277 * Assertion of authority: there is a sense that the Domain 278 Namespace is "owned" by the IETF or by ICANN, and so, if a name 279 is claimed outside of that process, the person or entity that 280 claimed that name should suffer some consequence that would, 281 presumably, deter future circumvention of the official process. 283 * More than one name resolution protocol is bad, in the sense 284 that a single protocol is less complicated to implement and 285 deploy. 287 * The semantics of alternative resolution protocols may differ 288 from the DNS protocol; DNS has the concept of RRtypes; other 289 protocols may not support RRtypes, or may support some entirely 290 different data structuring mechanism. 292 * If there is an IETF process through which a TLD can be assigned 293 at zero cost other than time, this process will be used as an 294 alternative to the more costly process of getting the name 295 registered through ICANN. 297 * A name might be assigned for a particular purpose when a more 298 general use of the name would be more beneficial. 300 * If the IETF assigns a name that some third party or parties 301 believes belongs to them in some way, the IETF could become 302 embroiled in an expensive dispute with those parties. 304 o If there were no process for assigning names for technical use 305 through the IETF, there is a concern that protocols that require 306 such names would not be able to get them. 308 o In some cases where the IETF has made assignments through the RFC 309 6761 process, technical mistakes have been made due to 310 misunderstandings as to the actual process that RFC 6761 specifies 311 (e.g., treating the list of suggested considerations for assigning 312 a name as a set of requirements all of which must be met). In 313 other cases, the IETF has made de facto assignments of Special-Use 314 Domain Names without following the RFC 6761 process. 316 o There are several Domain Name TLDs that are in use without due 317 process for a variety of purposes [SDO-ICANN-COLL]. The status of 318 these names need to be clarified and recorded to avoid future 319 disputes about their use. 321 o In principle, the RFC 6761 process could be used to document the 322 existence of Domain Names that are not safe to assign, and provide 323 information on how those names are used in practice. However, 324 attempts to use RFC 6761 to accomplish this documentation have not 325 been successful (for example, see "Additional Reserved Top Level 326 Domains [I-D.chapin-additional-reserved-tlds] and Section 4.2.7). 327 One side effect of the lack of documentation is that any 328 mitigation effect on the root name servers or on privacy 329 considerations has been missed. 331 o A Domain Name can be identified as either a DNS name by placing it 332 in the DNS zone(s) or as a Special-Use Domain Name by adding it to 333 the IANA registry. Some names are in both places; for example, 334 some locally served zone names are in DNS zones and documented in 335 the Special-Use Domain Names registry. At present, the only way a 336 Domain Name can be added to the Special-Use Domain Name registry 337 is for the IETF to take responsibility for the name and designate 338 it for "technical use". There are other potential uses for Domain 339 Names that should be recorded in the registry, but for which the 340 IETF should not take responsibility. 342 o The IETF may in some cases see the need to document that a name is 343 in use without claiming that the use of the name is the IETF's use 344 of the name. No mechanism exists in the current registry to mark 345 names in this way. 347 o There is no formal mechanism that ensures that we check to make 348 sure that a document being considered for publication does not 349 unintentionally violate the IETF process for adding Special-Use 350 Domain Names to the registry (e.g., RFC 7788 [RFC7788]). 352 o Use of the registry is inconsistent--some Special-Use Domain Name 353 RFCs specify registry entries, some don't; some specify 354 delegation, some don't. 356 o There exists no safe, non-process-violating mechanism for ad-hoc 357 assignment of Special-Use Domain Names. 359 o It is generally assumed that protocols that need a Special-Use 360 Domain Name need a mnemonic, single-label, human-readable Special- 361 Use Domain Name, for use in user interfaces such as command lines 362 or URL entry fields. While this assumption is correct in some 363 cases, it is likely not correct in all cases; for example, in 364 applications where the DNS name is never visible to a user. 366 o RFC 6761 uses the term "Domain Name" to describe the thing for 367 which special uses are registered. This creates a great deal of 368 confusion because some readers take "Domain Name" to imply the use 369 of the DNS protocol. 371 o The use of DNSSEC with Special-Use Domain Names is an open issue. 372 There is no consensus or guidance about how to use DNSSEC with 373 various classes of Special-Use Domain Names. Considerations in 374 the use of DNSSEC with Special-Use Domain Names include: 376 * What class of Special-Use Domain Name is under consideration: 377 non-DNS, locally served zone, other? 379 * Does the Special-Use Domain Name require a delegation in the 380 root zone; if so, should that delegation be signed or not? If 381 there is no delegation, then this will be treated by validating 382 resolvers as a secure denial of existence for that zone. This 383 would not be appropriate for a name being resolved using the 384 DNS protocol. 386 * A process would be required through which the IETF can cause a 387 delegation in the root zone to be instantiated. 389 * What are the recommended practices for using DNS with the 390 specific Special-Use Domain Name? 392 The problems we have stated here represent the current understanding 393 of the authors of the document as to the complete set of problems 394 that have been identified during discussion by the working group on 395 this topic. The remainder of this document provides additional 396 context that will be needed for reasoning about these problems. 398 4. Existing Practice Regarding Special-Use Domain Names 400 There are three primary and numerous secondary documents to consider 401 when thinking about the Special-Use Domain Names process. 403 How names are resolved is ambiguous, in the sense that some names are 404 Special-Use Domain names that require special handling, and some 405 names can be resolved using the DNS protocol with no special 406 handling. 408 The assignment of Internet Names is not under the sole control of any 409 one organization. IETF has authority in some cases, but only with 410 respect to "technical uses." ICANN at present is the designated 411 administrator of the root zone, but generally not of zones other than 412 the root zone. And neither of these authorities can in any practical 413 sense exclude the practice of ad-hoc use of names. This can be done 414 by any entity that has control over one or more name servers or 415 resolvers, in the context of any hosts and services that that entity 416 operates. It can also be done by authors of software who decide that 417 a Special-Use Domain Name is the right way to indicate the use of an 418 alternate resolution mechanism. 420 4.1. Primary Special-Use Domain Name Documents 422 The primary documents are considered primary because they directly 423 address the IETF's past thoughts on this topic in a general way, and 424 also because they describe what the IETF does in practice. Only one 425 of these documents is an IETF consensus document. 427 4.1.1. IAB Technical Comment on the Unique DNS Root 429 This document [RFC2826] is not an IETF consensus document, and 430 appears to have been written to address a different problem than the 431 Special-Use Domain Name problem. However, it speaks directly to 432 several of the key issues that must be considered, and of course 433 coming as it does from the IAB, it is rightly treated as having 434 significant authority despite not being an IETF consensus document. 436 This document should be considered required reading for IETF 437 participants who wish to express an informed opinion on the topic of 438 Special-Use Domain Names. The main points that appear relevant to 439 the Special-Use Domain Names problem are: 441 o The Internet requires a globally unique namespace 443 o Private networks may operate private namespaces, but still require 444 that names in the public namespace be globally unique. 446 o The Domain Name System [RFC1035] is not the only protocol that may 447 be used for resolving domain names. 449 o Users cannot be assumed to know how to distinguish between 450 symbolic references that have local meaning and references that 451 have global meaning. Users may therefore share references that 452 incorporate Domain Names with no global meaning (for example, a 453 URL of 'http://mysite.example.corp', where 'example.corp' is a 454 domain used privately and informally as described in 455 [SDO-ICANN-COLL]). 457 o Such references might refer to the object the user intends to 458 share within that user's context, but either refer to some other 459 object any recipient's context, or might not refer to any object 460 at all in a recipient's context. The effect of this is that the 461 user's intended communication will not be able to be understood by 462 the recipients of the communication. 464 o This same problem can also occur simply because a single user 465 copies a name from one context in which it has one meaning, into a 466 different context in which it has a different meaning-- for 467 example copying a '.onion' Domain Name out of a Tor Browser [TOR], 468 where it has meaning, and pasting this name into an ssh client 469 that doesn't support connecting over the Tor network. 471 To boil this down even further, we can take the following advice from 472 this document: 474 o Domain Names with unambiguous global meaning are preferable to 475 Domain Names with local meaning which will be ambiguous. 476 Nevertheless both globally-meaningful and locally-special names 477 are in use and must be supported. 479 o At the time of the writing of this document the IAB was of the 480 opinion that there might well be more than one name resolution 481 protocol used to resolve Domain Names. 483 4.1.2. Special-Use Domain Names 485 The second important document is "Special-Use Domain Names" 486 [RFC6761]. RFC 6761 represents the current IETF consensus on 487 designating and recording Special-Use Domain Names. The IETF has 488 experienced problems with the designation process described in RFC 489 6761; these concerns motivate this document. Again, familiarity with 490 RFC 6761 is a prerequisite for having an informed opinion on the 491 topic of Special-Use Domain Names. 493 RFC 6761 defines two aspects of Special-Use Domain Names: designating 494 a Domain Name to have a special purpose and registering that special 495 use in the Special-Use Domain Names registry. The designation 496 process is defined in a single sentence (RFC 6761, section 4): 498 If it is determined that special handling of a name is required in 499 order to implement some desired new functionality, then an IETF 500 "Standards Action" or "IESG Approval" specification [RFC5226] MUST 501 be published describing the new functionality. 503 This sentence implies that any designation of a Special-Use Domain 504 Name is subject to the same open review and consensus process as used 505 to produce and publish all other IETF specifications. 507 The registration process is a purely mechanical process, in which the 508 existence of the newly designated Special-Use Domain Name is 509 recorded, with a pointer to a section in the relevant specification 510 document that defines the ways in which special handling is to be 511 applied to the name. 513 RFC 6761 provided the process whereby Multicast DNS [RFC6762] 514 designated ".local" as a Special-Use Domain Name and included it in 515 the Special-Use Domain Names registry. It itself also enumerated a 516 set of names that had been previously used or defined to have special 517 uses prior to the publication of RFC 6761. Since there had been no 518 registry for these names prior to the publication of RFC 6761, the 519 documents defining these names could not have added them to the 520 registry. 522 There are at least several important points to think of with respect 523 to the RFC 6761: 525 o A Special-Use Domain Name may be a name that should be resolved 526 using the DNS protocol with no special handling. An example of 527 this is 'IN-ADDR.ARPA.' (which is an example of a Special-Use 528 Domain Name that is not a TLD). 530 o A Special-Use Domain Name may be a name that is resolved using the 531 DNS protocol, requires no special handling in the stub resolver, 532 but requires special handling in the recursive resolver. An 533 example of this would be "10.in-addr.arpa." 535 o A Special-Use Domain Name may be a name that requires special 536 handling in the stub resolver. An example would be a Special-Use 537 Top-Level Domain Name like '.local' which acts as a signal to 538 indicate that the local stub resolver should use a non-DNS 539 protocol for name resolution. 541 o The current IETF consensus (from a process perspective, not 542 necessarily from the perspective of what would be consensus if the 543 IETF were to attempt to produce a new consensus document) is that 544 all of these purposes for Special-Use Domain Names are valid. 546 The term "stub resolver" in this case does not mean "DNS protocol 547 stub resolver." The stub resolver is the entity within a particular 548 software stack that takes a question about a Domain Name and answers 549 it. One way a stub resolver can answer such a question is using the 550 DNS protocol, but it is in the stub resolver, as we are using the 551 term here, that the decision as to whether to use a protocol, and if 552 so which protocol, or whether to use a local database of some sort, 553 is made. 555 RFC 6761 does not limit Special-Use Domain Names to TLDs. However, 556 at present, all Special-Use Domain Names registered in the IANA 557 Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended 558 to be resolved using the DNS protocol, or are TLDs, or both. That 559 is, at present there exist no Special-Use Domain Names which require 560 special handling by stub resolvers and which are not at the top level 561 of the naming hierarchy. 563 One point to take from this is that there is already a requirement in 564 RFC 6762 that when stub resolvers encounter the special label, 565 '.LOCAL' at the top level of a domain name, they can only use the 566 mDNS protocol be used for resolving that Domain Name. 568 4.1.3. MoU Concerning the Technical Work of the IANA 570 There exists a Memorandum of Understanding [RFC2860] between the IETF 571 and ICANN (Internet Corporation for Assigned Names and Numbers) which 572 discusses how names and numbers will be managed through the IANA 573 (Internet Assigned Numbers Authority). This document is important to 574 the discussion of Special-Use Domain Names because, while it 575 delegates authority for managing the Domain Name System Namespace 576 generally to ICANN, it reserves to the IETF the authority that RFC 577 6761 formalizes: 579 Note that (a) assignments of Domain Names for technical uses (such 580 as Domain Names for inverse DNS lookup), (b) assignments of 581 specialised address blocks (such as multicast or anycast blocks), 582 and (c) experimental assignments are not considered to be policy 583 issues, and shall remain subject to the provisions of this 584 Section 4. 586 The above text is an addendum to the following: 588 Two particular assigned spaces present policy issues in addition 589 to the technical considerations specified by the IETF: the 590 assignment of Domain Names, and the assignment of IP address 591 blocks. These policy issues are outside the scope of this MOU. 593 In general, then, the assignment of names in the DNS root zone, and 594 the management of the DNS namespace, is a function that is performed 595 by ICANN. However, the MoU specifically exempts domain names 596 assigned for technical use, and uses the example of domains used for 597 inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the 598 Special-Use Domain Names registry. 600 Implicit in the MoU is the fact that the IETF and ICANN retain, 601 between them, sole authority for assigning any names from the Domain 602 Namespace. Both the IETF and ICANN have internal processes for 603 making such assignments. 605 The point here is not to say what the implications of this statement 606 in the MoU are, but rather to call the reader's attention to the 607 existence of this statement. 609 4.1.4. Liaison Statement on Technical Use of Domain Names 611 As a result of processing requests to add names to the Special-Use 612 Domain Name registry, as documented in 613 [I-D.chapin-additional-reserved-tlds] and 614 [I-D.grothoff-iesg-special-use-p2p-names], the IAB initiated a review 615 of the process defined in RFC 6761 for adding names to the registry. 616 This review was identified as in the charter of the IETF DNSOP 617 working group, and the review has been conducted in that working 618 group. The Liaison Statement [SDO-IAB-ICANN-LS] notified ICANN of 619 the review, affirmed that the discussion would be "open and 620 transparent to participation by interested parties" and explicitly 621 invited members of the ICANN community to participate. 623 This document is a product of the IETF DNSOP working group review of 624 the registry process in RFC 6761. 626 4.2. Secondary documents relating to the Special-Use Domain Name 627 question 629 In addition to these documents, there are several others with which 630 participants in this discussion should be familiar. 632 4.2.1. Multicast DNS 634 Multicast DNS [RFC6762] defines the Multicast DNS protocol, which 635 uses the '.LOCAL' Special-Use Top-Level Domain Name. Section 3 636 describes the semantics of "multicast DNS names." It is of 637 considerable historical importance to note that the -00 version of 638 this document, an individual submission, was published in July of 639 2001. This version contains substantially the same text in section 640 3, and was discussed in the DNSEXT working group at IETF 51 in August 641 of 2001[IETF-PRO-51]. The first version of this document designated 642 '.LOCAL.ARPA' as the Special-Use Domain Name. This idea was strongly 643 opposed by DNSEXT working group participants, and as a result the 644 author eventually switched to using '.LOCAL'. 646 The history of RFC 6762 is documented in substantial detail in 647 Appendix H; some notable milestones include the initial proposal to 648 replace Appletalk's NBP in July 1997, the chartering of the Zeroconf 649 working group in September 1999, assignment of a multicast address 650 for link-local name discovery in April of 2000. A companion 651 requirements document, eventually published as [RFC6760] was first 652 published in September of 2001. 654 The point of mentioning these dates is so that discussions involving 655 the time when the '.LOCAL' domain was first deployed, and the context 656 in which it was deployed, may be properly informed. 658 4.2.2. The .onion Special-Use Top-Level Domain Name 660 The .onion Special-Use Top-Level Domain Name [RFC7686] is important 661 because it is the most recent IETF action on the topic of Special-Use 662 Domain Names; although it does not set new policy, the mere fact of 663 its publication is worth thinking about. 665 Two important points to consider about this document are that: 667 o The IETF gained consensus to publish it 669 o The situation was somewhat forced, both by the fact of its 670 unilateral use by The Tor Project without following the RFC 6761 671 process, and because a deadline had been set by the CA/Browser 672 Forum [SDO-CABF-INT] after which all .onion PKI certificates would 673 expire and no new certificates would be issued, unless the .onion 674 Special-Use Top-Level Domain Name were to be recognized by the 675 IETF. 677 4.2.3. Locally Served DNS Zones 679 Locally Served DNS Zones [RFC6303] describes a particular use case 680 for zones that exist by definition, and that are resolved using the 681 DNS protocol, but that cannot have a global meaning, because the host 682 IP addresses they reference are not unique. This applies to a 683 variety of addresses, including Private IPv4 addresses [RFC1918], 684 Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice 685 was first described) and IANA-Reserved IPv4 Prefix for Shared Address 686 Space [RFC6598]. 688 This use case is distinct from the use-case for Special-Use Domain 689 Names like '.local' and '.onion' in that the names are resolved using 690 the DNS protocol (but do require extensions or exceptions to the 691 usual DNS resolution to enforce resolution in a local context rather 692 than the global DNS context). But it shares the problem that such 693 names cannot be assumed either to be unique or to be functional in 694 all contexts for all Internet-connected hosts. 696 4.2.4. Name Collision in the DNS 698 Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by 699 ICANN that attempts to characterize the potential risk to the 700 Internet of adding global DNS delegations for names that were not 701 previously delegated in the DNS, not reserved under any RFC, but also 702 known to be (.home) or surmised to be (.corp) in significant use for 703 Special-Use-type reasons (local scope DNS, or other resolution 704 protocols altogether). 706 4.2.5. SSAC Advisory on the Stability of the Domain Namespace 708 SSAC Advisory on the Stability of the Domain Namespace 709 [SDO-ICANN-SAC090] reports on some issues surrounding the conflicting 710 uses, interested parties and processes related to the Domain 711 Namespace. The document recommends the development of collaborative 712 processes among the various interested parties to coordinate their 713 activities related to the Domain Namespace. 715 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 717 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 718 [RFC7050] is an example of a document that successfully used the RFC 719 6761 process to designate '.ipv4only.arpa' as a Special-Use Domain 720 Name; in this case the process worked smoothly and without 721 controversy. 723 Unfortunately, while the IETF process worked smoothly, in the sense 724 that there was little controversy or delay in approving the new use, 725 it did not work correctly: the name 'ipv4only.arpa' was never added 726 to the Special-Use Domain Names registry. This appears to have 727 happened because the IAB was able to simply add the name to the .ARPA 728 zone, which the IAB administers. This is an illustration of one of 729 the problems that we have with the 6761 process: it is apparently 730 fairly easy to miss the step of adding the name to the registry. 732 4.2.7. Additional Reserved Top Level Domains 734 Additional Reserved Top Level Domains 735 [I-D.chapin-additional-reserved-tlds] is an example of a document 736 that attempted to reserve several TLDs identified by ICANN as 737 particularly at risk for collision as Special-Use Domain Names with 738 no documented use. This attempt failed. 740 Although this document failed to gain consensus to publish, the need 741 it was intended to fill still exists. Unfortunately, although a fair 742 amount is known about the use of these names, no document exists that 743 documents how they are used, and why it would be a problem to 744 delegate them. Additionally, to the extent that the uses being made 745 of these names are valid, no document exists indicating when it might 746 make sense to use them, and when it would not make sense to use them. 748 RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the 749 default name for name resolution relative to a home network context. 750 Although, as defined in RFC 7788, ".home" is a Special-Use Domain 751 Name, RFC 7788 did not follow the process in RFC 6761 and request the 752 addition of ".home" to the IANA Special-Use Domain Name registry. 753 Additionally, ".home" is an example of an attempt to reuse a Domain 754 Name that has already been put into use for other purposes without 755 following established processes[SDO-ICANN-COLL], which further 756 complicates the situation. At the time this document was written, 757 the IETF was developing a solution to this problem. 759 5. History 761 Newcomers to the problem of resolving Domain Names may be under the 762 mistaken impression that the DNS sprang, as in the Greek legend of 763 Athena, directly from Paul Mockapetris' forehead. This is not the 764 case. At the time of the writing of the IAB technical document, 765 memories would have been fresh of the evolutionary process that led 766 to the DNS' dominance as a protocol for Domain Name resolution. 768 In fact, in the early days of the Internet, hostnames were resolved 769 using a text file, HOSTS.TXT, which was maintained by a central 770 authority, the Network Information Center, and distributed to all 771 hosts on the Internet using the File Transfer Protocol (FTP) 772 [RFC0959]. The inefficiency of this process is cited as a reason for 773 the development of the DNS [RFC0882] [RFC0883] in 1983. 775 However, the transition from HOSTS.TXT to the DNS was not smooth. 776 For example, Sun Microsystems's Network Information System 777 [CORP-SUN-NIS], at the time known as Yellow Pages, was an active 778 competitor to the DNS, although it failed to provide a complete 779 solution to the global naming problem. 781 Another example was NetBIOS Name Service, also known as WINS 782 [RFC1002]. This protocol was used mostly by Microsoft Windows 783 machines, but also by open source BSD and Linux operating systems to 784 do name resolution using Microsoft's own name resolution protocol. 786 Most modern operating systems can still use the '/etc/hosts' file for 787 name resolution. Many still have a name service switch that can be 788 configured on the host to resolve some domains using NIS or WINS. 789 Most have the capability to resolve names using mDNS by recognizing 790 the special meaning of the '.local' Special-Use Top Level Domain 791 Name. 793 The Sun Microsystems model of having private domains within a 794 corporate site, while supporting the global Domain Name system for 795 off-site, persisted even after the NIS protocol fell into disuse. 796 Microsoft used to recommend that site administrators use a "private" 797 TLD for internal use, and this practice was very much a part of the 798 zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and 799 Appendix G of [RFC6762]). This attitude is at the root of the 800 widespread practice of simply picking an unused TLD and using it for 801 experimental purposes, which persists even at the time of writing of 802 this memo. 804 This history is being presented because discussions about Special-Use 805 Domain Names in the IETF often come down to the question of why users 806 of new name resolution protocols choose to use Domain Names, rather 807 than using some other naming concept that doesn't overlap with the 808 namespace that, in modern times is, by default, resolved using the 809 DNS. 811 The answer is that as a consequence of this long history of resolving 812 Domain Names using a wide variety of name resolution systems, Domain 813 Names are required in a large variety of contexts in user interfaces 814 and applications programming interfaces. Any name that appears in 815 such a context is a Domain Name. So developers of new name 816 resolution systems that must work in existing contexts actually have 817 no choice: they must use a Special-Use Domain Name to segregate a 818 portion of the namespace for use with their system. 820 6. Security Considerations 822 This document mentions various security and privacy considerations in 823 the text. However, this document creates no new security or privacy 824 concerns. 826 7. IANA considerations 828 This document has no actions for IANA. 830 8. Contributors 832 This document came about as a result of conversations that occurred 833 in the conference hotel lobby, the weekend before IETF 95, when the 834 original author, Ted Lemon, was trying to come up with a better 835 problem statement. Stuart Cheshire, Mark Andrews, David Conrad, Paul 836 Ebersman and Aaron Falk all made helpful and insightful observations 837 or patiently answered questions. This should not be taken as an 838 indication that any of these folks actually agree with what the 839 document says, but their generosity with time and thought are 840 appreciated in any case. 842 Ralph started out as an innocent bystander, but discussion with him 843 was the key motivating factor in the writing of this document, and he 844 agreed to co-author it without too much arm-twisting. Warren spent a 845 lot of time working with us on this document after it was first 846 published, and joined as an author in order to make sure that the 847 work got finished; without him the -01 and -02 versions might not 848 have happened. 850 This document also owes a great deal to Ed Lewis' excellent work on 851 what a "Domain Name" is [I-D.lewis-domain-names]. 853 9. Informative References 855 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 856 RFC 882, DOI 10.17487/RFC0882, November 1983, 857 . 859 [RFC0883] Mockapetris, P., "Domain names: Implementation 860 specification", RFC 883, DOI 10.17487/RFC0883, November 861 1983, . 863 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 864 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 865 . 867 [RFC1002] NetBIOS Working Group in the Defense Advanced Research 868 Projects Agency, Internet Activities Board, and End-to-End 869 Services Task Force, "Protocol standard for a NetBIOS 870 service on a TCP/UDP transport: Detailed specifications", 871 STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, 872 . 874 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 875 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 876 . 878 [RFC1035] Mockapetris, P., "Domain names - implementation and 879 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 880 November 1987, . 882 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 883 and E. Lear, "Address Allocation for Private Internets", 884 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 885 . 887 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 888 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 889 2000, . 891 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 892 Understanding Concerning the Technical Work of the 893 Internet Assigned Numbers Authority", RFC 2860, 894 DOI 10.17487/RFC2860, June 2000, 895 . 897 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 898 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 899 . 901 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 902 RFC 6303, DOI 10.17487/RFC6303, July 2011, 903 . 905 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 906 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 907 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 908 2012, . 910 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 911 to Replace the AppleTalk Name Binding Protocol (NBP)", 912 RFC 6760, DOI 10.17487/RFC6760, February 2013, 913 . 915 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 916 RFC 6761, DOI 10.17487/RFC6761, February 2013, 917 . 919 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 920 DOI 10.17487/RFC6762, February 2013, 921 . 923 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 924 the IPv6 Prefix Used for IPv6 Address Synthesis", 925 RFC 7050, DOI 10.17487/RFC7050, November 2013, 926 . 928 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 929 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 930 2015, . 932 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 933 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 934 2015, . 936 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 937 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 938 2016, . 940 [I-D.chapin-additional-reserved-tlds] 941 Chapin, L. and M. McFadden, "Additional Reserved Top Level 942 Domains", draft-chapin-additional-reserved-tlds-02 (work 943 in progress), March 2015. 945 [I-D.grothoff-iesg-special-use-p2p-names] 946 Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and 947 L. Ryge, "Special-Use Domain Names of Peer-to-Peer 948 Systems", draft-grothoff-iesg-special-use-p2p-names-04 949 (work in progress), January 2015. 951 [I-D.lewis-domain-names] 952 Lewis, E., "Domain Names", draft-lewis-domain-names-05 953 (work in progress), February 2017. 955 [SDO-CABF-INT] 956 CA/Browser Forum, "Guidance on the Deprecation of Internal 957 Server Names and Reserved IP Addresses", June 2012, 958 . 960 [SDO-ICANN-COLL] 961 Interisle Consulting Group, LLC, "Name Collisions in the 962 DNS", August 2013, 963 . 966 [SDO-ICANN-SAC090] 967 ICANN Security and Stability Advisory Committee, "SSAC 968 Advisory on the Stability of the Domain Namespace", 969 December 2016, 970 . 973 [SDO-IANA-SUDR] 974 Internet Assigned Numbers Authority, "Special-Use Domain 975 Names registry", October 2015, 976 . 979 [SDO-ICANN-DAG] 980 Internet Assigned Numbers Authority, "Special-Use Domain 981 Names registry", October 2015, 982 . 985 [SDO-IAB-ICANN-LS] 986 Internet Architecture Board, "Liaison Statement from the 987 IAB to the ICANN Board on Technical Use of Domain Names", 988 September 2015, . 991 [CORP-SUN-NIS] 992 Sun Microsystems, "Large System and Network 993 Administration", March 1990. 995 [IETF-PRO-51] 996 Internet Engineering Task Force, "Proceedings of the 51st 997 IETF", August 2001, 998 . 1000 [TOR] The Tor Project, "Tor", 2017, 1001 . 1003 Appendix A. Change Log. 1005 -02 to -03 (in Github): 1007 Passes idnits except for errors resulting from a reference to an 1008 RFC 2119 keyword and a citation of RFC 5226 with no matching 1009 reference in quoted text at line 493. 1011 Issue #57: Document needs an "Security Considerations" section 1012 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57 1014 Numerous editorial changes for consistency; e.g. use "Special-Use 1015 Domain Names" throughout. 1017 Issue #58: Document needs an "IANA Considerations" section 1018 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58 1020 Issue #39: Overlapping bullets in Section 3, with proposed 1021 restructuring -- Russ Housley https://github.com/Abhayakara/draft- 1022 tldr-sutld-ps/issues/39 1024 Issue #55: Editorial improvement to Section 3 (4) -- John 1025 Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1026 issues/55 1028 Issue #34: Separate two problems in paragraph that begins "No 1029 mechanism exists for adding a name to the registry...." (2 issues) 1030 -- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld- 1031 ps/issues/34 1033 Issue #52: Editorial improvement to Section 3 (1) -- John 1034 Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1035 issues/52 1037 Issue #51: Clarification in Introduction -- John Dickinson 1038 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51 1039 Issue #49: Should cite https://datatracker.ietf.org/liaison/1351 1040 -- George Michaelson https://github.com/Abhayakara/draft-tldr- 1041 sutld-ps/issues/49 1043 Issue #50: IETF precedence in Special-Use names registry -- Ted 1044 Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50 1046 Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special 1047 use TLD -- George Michaelson https://github.com/Abhayakara/draft- 1048 tldr-sutld-ps/issues/48 1050 Issue #47: 4.3 should be made more prominent -- George Michaelson 1051 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47 1053 Issue #43: Spell out SUDN and SUTLDN rather than use acronyms -- 1054 Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1055 issues/43 1057 Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs 1058 that have been commandeered, as reported in SDO-ICANN-COLL -- Russ 1059 Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1060 issues/41 1062 Issue #40: Note that time to publish spec for .local included 1063 inventing SUDN registry -- Russ Housley 1064 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41 1066 Issue #37: Title should be "Special-Use Domain Names Problem 1067 Statement" -- Russ Housley https://github.com/Abhayakara/draft- 1068 tldr-sutld-ps/issues/37 1070 Issue #36: Expand on desire for Special-Use names to be human- 1071 readable -- Suzanne Woolf https://github.com/Abhayakara/draft- 1072 tldr-sutld-ps/issues/36 1074 Issue #35: Clarify "No process exists [...]" to include both IETF 1075 process and other process -- Suzanne Woolf 1076 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35 1078 Issue #31: Add justification for concern about IETF's ability to 1079 assign names for technical use -- Suzanne Woolf 1080 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31 1082 Issue #12: Add DNSSEC to text -- John Levine 1083 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12 1085 Issue #6: Without a process, we just have chaos -- Stuart Cheshire 1086 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6 1087 Issue #32: Have assignments through RFC 6761 really had "technical 1088 mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft- 1089 tldr-sutld-ps/issues/32 1091 Issue #29: Add a reason to bypass external process: expectation 1092 for use of new name to be restricted to local scope -- Suzanne 1093 Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29 1095 Issue #27: Is "technical use" really ambiguous; too inclusive for 1096 some people and too limited for others -- Suzanne Wolff 1097 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27 1099 Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff 1100 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24 1102 Issue #22: Clarify importance of the "root of the Domain 1103 Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft- 1104 tldr-sutld-ps/issues/22 1106 Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff 1107 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21 1109 Issue #20: Section 3: Clarify sentences beginning "Solutions to 1110 these problems..." -- Suzanne Wolff https://github.com/Abhayakara/ 1111 draft-tldr-sutld-ps/issues/20 1113 Issue #19: Define "default" or "assumed" use of domain names to be 1114 within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft- 1115 tldr-sutld-ps/issues/19 1117 Issue #18: Cite definition of RFC 7719 and domain names draft in 1118 definition of "domain name" -- Suzanne Wolff 1119 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18 1121 Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley 1122 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45) 1124 Issue #46: Reformat citation of RFC 2860 -- Russ Housley 1125 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46) 1127 Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in 1128 section 3 -- Russ Housley (https://github.com/Abhayakara/draft- 1129 tldr-sutld-ps/issues/44) 1131 Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 -- 1132 Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1133 issues/42) 1134 Issue #30: Leaked queries aren't an operational problem in 1135 practice -- Suzanne Wolf (https://github.com/Abhayakara/draft- 1136 tldr-sutld-ps/issues/30) 1138 Address some of the simpler issues, including: 1140 Issue #13: Spelling of Tor -- Jeremy Rand 1141 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13) 1143 Issue #14: Change SDO to "organizations" -- Suzanne Woolf 1144 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) 1146 Issue #16: Match number of "policies" and "that policy" -- Suzanne 1147 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16) 1149 Issue #17: Clarify sentence beginning with "In support of the 1150 particular set of problems described here...." -- Suzanne. 1151 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) 1153 Issue #23: Match number of "names" and "a TLD" -- Suzanne. 1154 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23) 1156 -01 to -02: 1158 Language cleanup from Ted. 1160 -00 to -01: 1162 Improved the terminology. 1164 Included reference to SAC090. 1166 Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of 1167 names. 1169 Improved background. 1171 Noted that semantics may differ between resolution contexts. 1173 Pointer to .home / .corp / .mail, other "toxic" names 1175 Readability fixes. 1177 -04 to ietf-00 1179 Document adopted by WG. 1181 Significant changes from CfA integrated, please refer to diff. 1183 -03 to -04: 1185 o Replaced 'Internet Names' with 'Domain Names' - suggestion by John 1186 Levine. 1188 -02 to -03: 1190 o Readability fixes, small grammar updates. 1192 -01 to -02: 1194 o Cleaned up the abstract. 1196 o Fixed the case of Internet 1198 o Reference to Ed Lewis' "Domain Names" 1200 o Fleshed out the problems, primarily the coordination, collisions 1201 ones. 1203 -00 to -01: 1205 o Large refactoring, basically a rewrite. Incorporated comments, 1206 removed a bunch of unneeded text, etc. 1208 Authors' Addresses 1210 Ted Lemon 1211 Nominum, Inc. 1212 800 Bridge Parkway 1213 Redwood City, California 94065 1214 United States of America 1216 Phone: +1 650 381 6000 1217 Email: ted.lemon@nominum.com 1219 Ralph Droms 1221 Email: rdroms.ietf@gmail.com 1222 Warren Kumari 1223 Google 1224 1600 Amphitheatre Parkway 1225 Mountain View, CA 94043 1226 US 1228 Email: warren@kumari.net