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