idnits 2.17.1 draft-ietf-dnsop-sutld-ps-08.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 524: '... "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 (August 4, 2017) is 2457 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC5226' is mentioned on line 524, but not defined ** Obsolete undefined reference: RFC 5226 (Obsoleted by RFC 8126) == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-09 -- 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) -- Duplicate reference: RFC7788, mentioned in 'RFC7788', was also mentioned in 'ERRATA-4677'. 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: February 5, 2018 6 W. Kumari 7 Google 8 August 4, 2017 10 Special-Use Domain Names Problem Statement 11 draft-ietf-dnsop-sutld-ps-08 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 February 5, 2018. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 4 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 . . . . . . . . 10 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 . . . . . . . . . . . . . . 16 72 4.2.4. Name Collision in the DNS . . . . . . . . . . . . . . 16 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 . . . . . . . . 17 78 5. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 80 7. IANA considerations . . . . . . . . . . . . . . . . . . . . . 19 81 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19 82 9. RFC Editor Considerations . . . . . . . . . . . . . . . . . . 19 83 10. Informative References . . . . . . . . . . . . . . . . . . . 19 84 Appendix A. Change Log. . . . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 87 1. Introduction 89 One of the key services required to use the Internet is name 90 resolution. Name resolution is the process of translating a symbolic 91 name into some object or set of objects to which the name refers, 92 most typically one or more IP addresses. These names are often 93 referred to as Domain Names. When reading this document, care must 94 be taken to not assume that the term Domain Name implies the use of 95 the Domain Name System [RFC1034] for resolving these names. An 96 excellent presentation on this topic can be found in Domain Names 97 [I-D.lewis-domain-names]. 99 Special-Use Domain Names [RFC6761] created an IANA registry for 100 Special-Use Domain Names [SDO-IANA-SUDR], defined policies for adding 101 to the registry, and made some suggestions about how those policies 102 might be implemented. Since the publication of RFC 6761, the IETF 103 has been asked to designate several new Special-Use Domain Names in 104 this registry. During the evaluation process for these Special-Use 105 Domain Names, the IETF encountered several different sorts of issues. 106 Because of this, the IETF has decided to investigate the problem and 107 decide if and how the RFC 6761 process can be improved, or whether it 108 should be deprecated. The IETF DSNOP working group charter was 109 extended to include conducting a review of the process for adding 110 names to the registry that is defined in RFC 6761. This document is 111 a product of that review. 113 Based on current ICANN and IETF practice, including RFC 6761, there 114 are several different types of names in the root of the Domain 115 Namespace: 117 o Reserved by the IETF for technical purposes 119 o Assigned by ICANN to the public DNS root; some names reserved by 120 the IETF for technical purposes may appear in the Global DNS root 121 for reasons pertaining to the operation of the DNS 123 o ICANN Reserved Names; names that may not be applied for as TLDs 124 (see [SDO-ICANN-DAG], Section 2.2.1.2.1, Reserved Names, 125 Section 2.2.1.4.1, Treatment of Country or Territory Names, et 126 al.) 128 o Used by other organizations without following established 129 processes 131 o Names that are unused and are available for assignment to one of 132 the previous categories 134 This document presents a list, derived from a variety of sources 135 including discussion in the IETF dnsop WG, of the problems associated 136 with the assignment of Special-Use Domain Names. The list is 137 intended to be an unfiltered compilation of issues. In support of 138 its analysis of the particular set of issues described here, the 139 document also includes descriptions of existing practice as it 140 relates to the use of domain names, a brief history of domain names, 141 and some observations by various IETF participants who have 142 experience with various aspects of the current situation. 144 2. Terminology 146 This document uses the terminology from RFC 7719 [RFC7719]. Other 147 terms used in this document are defined here: 149 Domain Name This document uses the term "Domain Name" as defined in 150 section 2 of RFC 7719 [RFC7719]. 152 Domain Namespace The set of all possible Domain Names. 154 Special-Use Domain Name A Domain Name listed in the Special-Use 155 Domain Names registry [SDO-IANA-SUDR]. 157 For the sake of brevity this document uses some abbreviations, which 158 are expanded here: 160 IANA Internet Assigned Numbers Authority 162 ICANN Internet Corporation for Assigned Names and Numbers 164 TLD Top-Level Domain, as defined in section 2 of RFC 7719 [RFC7719] 166 gTLD Generic Top-Level Domain (see section 2 of RFC 2352 [RFC2352]) 168 3. Problems associated with Special-Use Domain Names 170 This section presents a list of problems that have been identified 171 with respect to the assignment of Special-Use Domain Names. 172 Solutions to these problems, including their costs or tradeoffs, are 173 out of scope for this document. They will be covered in a separate 174 document. New problems that might be created in the process of 175 solving problems described in this document are also out of scope: 176 these problems are expected to be addressed in the process of 177 evaluating potential solutions. 179 Special-Use Domain Names exist to solve a variety of problems. This 180 document has two goals: enumerate all of the problems that have been 181 identified to which Special-Use Domain Names are a solution and 182 enumerate all of the problems that have been raised in the process of 183 trying to use RFC 6761 as it was intended. As some of those problems 184 may fall into both categories, this document makes no attempt to 185 categorize the problems. 187 There is a broad diversity of opinion about this set of problems. 188 Not every participant agrees that each of the problems enumerated in 189 this document is actually a problem. This document takes no position 190 on the relative validity of the various problems that have been 191 enumerated, nor on the organization responsible for addressing each 192 individual problem, if it is to be addressed. The sole purposes of 193 the document are to enumerate those problems, provide the reader with 194 context for thinking about them and provide a context for future 195 discussion of solutions, regardless of whether such solutions may be 196 work for IETF, ICANN, IANA or some other group. 198 This is the list of problems. This is not an ordered list, it is 199 numbered merely to facilitate referencing specific problems: 201 1. Although the IETF and ICANN have a liaison relationship through 202 which special-use allocations can be discussed, there exists no 203 formal process for coordinating these allocations (see 204 Section 4.1.3). The lack of coordination complicates the 205 management of the root of the Domain Namespace and could lead to 206 conflicts in name assignments [SDO-ICANN-SAC090]. 208 2. There is no explicit scoping as to what can constitute a 209 "technical use" [RFC2860] and what cannot, and there is also no 210 consensus within the IETF as to what this term means. 212 3. Not all developers of protocols on the internet agree that 213 authority over the entire Domain Namespace should reside solely 214 with the IETF and ICANN. 216 4. Although IETF and ICANN nominally have authority over this 217 namespace, neither organization can enforce that authority over 218 any third party who wants to just start using a subset of the 219 namespace. Such parties may observe that the IETF has never 220 asserted control or authority over what protocols are "allowed" 221 on the internet, and that the principle of "permissionless 222 innovation" suggests there should be a way for people to include 223 new uses of domain names in new protocols and applications. 225 5. Organizations do in fact sometimes use subsets of the Domain 226 Namespace without following established processes. Reasons a 227 third party might do this include: 229 1. Unaware that a process exists for assigning such names 231 2. Intended use is covered by gTLD process [SDO-ICANN-DAG], but 232 no gTLD process is ongoing 234 3. Intended use is covered by gTLD process, but the third party 235 doesn't want to pay a fee 237 4. Intended use is covered by some IETF process, but the third 238 party doesn't want to follow the process 240 5. Intended use is covered by ICANN or IETF process, but third 241 party expects that the outcome will be refusal or non-action 243 6. Unaware that a name intended to be used only locally may 244 nevertheless leak 246 7. Unaware that a name used locally with informal allocation 247 may subsequently be allocated formally, creating operational 248 problems 250 6. There is demand for more than one name resolution protocol for 251 Domain Names. Domain Names contain no metadata to indicate 252 which protocol to use to resolve them. Domain name resolution 253 APIs do not provide a way to specify which protocol to use. 255 7. When a Special-Use Domain Name is added to the Special-Use 256 Domain Names registry, not all software that processes such 257 names will understand the special use of that name. In many 258 cases, name resolution software will use the Domain Name System 259 for resolution of names not known to have a special use. 260 Consequently, any such use will result in queries for Special- 261 Use Domain Names being sent to Domain Name System authoritative 262 servers. These queries may constitute an operational problem 263 for operators of root zone authoritative name servers. These 264 queries may also inadvertently reveal private information 265 through the contents of the query, which is a privacy 266 consideration. 268 8. The RFC 6761 process is sufficiently uncertain that some 269 protocol developers have assumed they could not get a name 270 assigned; the process of assigning the first new name ('.local') 271 using the RFC 6761 process took more than ten years from 272 beginning to end: longer by a factor of ten than any other part 273 of the protocol development process (largely because this ten 274 years included time to develop the process as well as use it). 275 Other uses of the process have proceeded more smoothly, but 276 there is a reasonably justified perception that using this 277 process is likely to be slow and difficult, with an uncertain 278 outcome. 280 9. There is strong resistance within the IETF to assigning Domain 281 Names to resolution systems outside of the DNS, for a variety of 282 reasons: 284 1. Requires a mechanism for identifying which of a set of 285 resolution processes is required in order to resolve a 286 particular name. 288 2. Assertion of authority: there is a sense that the Domain 289 Namespace is "owned" by the IETF or by ICANN, and so, if a 290 name is claimed outside of that process, the person or 291 entity that claimed that name should suffer some consequence 292 that would, presumably, deter future circumvention of the 293 official process. 295 3. More than one name resolution protocol is bad, in the sense 296 that a single protocol is less complicated to implement and 297 deploy. 299 4. The semantics of alternative resolution protocols may differ 300 from the DNS protocol; DNS has the concept of RRtypes; other 301 protocols may not support RRtypes, or may support some 302 entirely different data structuring mechanism. 304 5. If there is an IETF process through which a TLD can be 305 assigned at zero cost other than time, this process will be 306 used as an alternative to the more costly process of getting 307 the name registered through ICANN. 309 6. A name might be assigned for a particular purpose when a 310 more general use of the name would be more beneficial. 312 7. If the IETF assigns a name that some third party or parties 313 believes belongs to them in some way, the IETF could become 314 embroiled in an expensive dispute with those parties. 316 10. If there were no process for assigning names for technical use 317 through the IETF, there is a concern that protocols that require 318 such names would not be able to get them. 320 11. In some cases where the IETF has made assignments through the 321 RFC 6761 process, technical mistakes have been made due to 322 misunderstandings as to the actual process that RFC 6761 323 specifies (e.g., treating the list of suggested considerations 324 for assigning a name as a set of requirements all of which must 325 be met). In other cases, the IETF has made de facto assignments 326 of Special-Use Domain Names without following the RFC 6761 327 process (see [RFC7050], [RFC7788]). 329 12. There are several Domain Name TLDs that are in use without due 330 process for a variety of purposes. The status of these names 331 need to be clarified and recorded to avoid future disputes about 332 their use [SDO-ICANN-COLL]. 334 13. In principle, the RFC 6761 process could be used to document the 335 existence of Domain Names that are not safe to assign, and 336 provide information on how those names are used in practice. 337 However, attempts to use RFC 6761 to accomplish this 338 documentation have not been successful (for example, see 339 "Additional Reserved Top Level Domains 340 [I-D.chapin-additional-reserved-tlds] and Section 4.2.7). One 341 side effect of the lack of documentation is that any mitigation 342 effect on the root name servers or on privacy considerations has 343 been missed. 345 14. A Domain Name can be identified as either a DNS name by placing 346 it in the DNS zone(s) or as a Special-Use Domain Name by adding 347 it to the IANA registry. Some names are in both places; for 348 example, some locally served zone names are in DNS zones and 349 documented in the Special-Use Domain Names registry. At 350 present, the only way a Domain Name can be added to the Special- 351 Use Domain Name registry is for the IETF to take responsibility 352 for the name and designate it for "technical use". There are 353 other potential uses for Domain Names that should be recorded in 354 the registry, but for which the IETF should not take 355 responsibility. 357 15. The IETF may in some cases see the need to document that a name 358 is in use without claiming that the use of the name is the 359 IETF's use of the name. No mechanism exists in the current 360 registry to mark names in this way. 362 16. There is no formal process during any of the review stages for a 363 document in which a check is made to ensure that the document 364 does not unintentionally violate IETF process for adding 365 special-use domain names to the registry, as was the case, for 366 example, in RFC 7788 [RFC7788]. 368 17. Use of the registry is inconsistent -- some Special-Use Domain 369 Name RFCs specifically add registry entries, some don't; some 370 specify how and whether special-use name delegations should be 371 done, some don't. 373 18. There exists no safe, non-process-violating mechanism for ad-hoc 374 assignment of Special-Use Domain Names. 376 19. It is generally assumed that protocols that need a Special-Use 377 Domain Name need a mnemonic, single-label, human-readable 378 Special-Use Domain Name, for use in user interfaces such as 379 command lines or URL entry fields. While this assumption is 380 correct in some cases, it is likely not correct in all cases; 381 for example, in applications where the DNS name is never visible 382 to a user. 384 20. RFC 6761 uses the term "Domain Name" to describe the thing for 385 which special uses are registered. This creates a great deal of 386 confusion because some readers take "Domain Name" to imply the 387 use of the DNS protocol. 389 21. The use of DNSSEC with Special-Use Domain Names is an open 390 issue. There is no consensus or guidance about how to use 391 DNSSEC with various classes of Special-Use Domain Names. 392 Considerations in the use of DNSSEC with Special-Use Domain 393 Names include: 395 1. What class of Special-Use Domain Name is under 396 consideration: non-DNS, locally served zone, other? 398 2. Does the Special-Use Domain Name require a delegation in the 399 root zone; if so, should that delegation be signed or not? 400 If there is no delegation, then this will be treated by 401 validating resolvers as a secure denial of existence for 402 that zone. This would not be appropriate for a name being 403 resolved using the DNS protocol. 405 3. A process would be required through which the IETF can cause 406 a delegation in the root zone to be instantiated. 408 4. What are the recommended practices for using DNS with the 409 specific Special-Use Domain Name? 411 The problems we have stated here represent the current understanding 412 of the authors of the document as to the complete set of problems 413 that have been identified during discussion by the working group on 414 this topic. The remainder of this document provides additional 415 context that will be needed for reasoning about these problems. 417 4. Existing Practice Regarding Special-Use Domain Names 419 There are three primary (see Section 4.1) and numerous secondary 420 (Section 4.2) documents to consider when thinking about the Special- 421 Use Domain Names process. 423 How names are resolved is ambiguous, in the sense that some names are 424 Special-Use Domain names that require special handling, and some 425 names can be resolved using the DNS protocol with no special 426 handling. 428 The assignment of Internet Names is not under the sole control of any 429 one organization. IETF has authority in some cases, but only with 430 respect to "technical uses." ICANN at present is the designated 431 administrator of the root zone, but generally not of zones other than 432 the root zone. Neither of these authorities can in any practical 433 sense exclude the practice of ad-hoc use of names. Unauthorized use 434 of domain names can be accomplished by any entity that has control 435 over one or more name servers or resolvers, in the context of any 436 hosts and services that entity operates. It can also be accomplished 437 by authors of software who decide that a Special-Use Domain Name is 438 the right way to indicate the use of an alternate resolution 439 mechanism. 441 4.1. Primary Special-Use Domain Name Documents 443 The primary documents are considered primary because they directly 444 address the IETF's past thoughts on this topic in a general way, and 445 also because they describe what the IETF does in practice. 447 4.1.1. IAB Technical Comment on the Unique DNS Root 449 This document [RFC2826] is not an IETF consensus document, and 450 appears to have been written to address a different problem than the 451 Special-Use Domain Name problem. However, it speaks directly to 452 several of the key issues that must be considered, and, coming as it 453 does from the IAB, it is rightly treated as having significant 454 authority despite not being an IETF consensus document. 456 This document should be considered required reading for IETF 457 participants who wish to express an informed opinion on the topic of 458 Special-Use Domain Names. The main points that appear relevant to 459 the Special-Use Domain Names problem are: 461 o The Internet requires a globally unique namespace: a namespace in 462 which any given name refers to the same information (has the same 463 meaning) no matter who requests that information and no matter 464 from which specific name server they request it. 466 o Private networks may operate private namespaces, with names that 467 have meanings only locally (within the private network) but still 468 require that names in the public namespace be globally unique. 470 o The Domain Name System [RFC1035] is not the only protocol that may 471 be used for resolving domain names. 473 o Users cannot be assumed to know how to distinguish between 474 symbolic references that have local meaning and references that 475 have global meaning. Users may therefore share references that 476 incorporate Domain Names with no global meaning (for example, a 477 URL of 'http://mysite.example.corp', where 'example.corp' is a 478 domain used privately and informally as described in 479 [SDO-ICANN-COLL]). 481 o Such references might refer to the object the user intends to 482 share within that user's context, but either refer to some other 483 object any recipient's context, or might not refer to any object 484 at all in a recipient's context. The effect of this reference 485 escaping the context in which it is valid is that the user's 486 intended communication will not be able to be understood by the 487 recipients of the communication. 489 o This same problem can also occur when a single user copies a name 490 from one context in which it has one meaning, into a different 491 context in which it has a different meaning -- for example copying 492 a '.onion' Domain Name out of a Tor Browser [TOR], where it has 493 meaning, and pasting this name into an ssh client that doesn't 494 support connecting over the Tor network. 496 We can summarize the advice in this document as follows: 498 o Domain Names with unambiguous global meaning are preferable to 499 Domain Names with local meaning which will be ambiguous. 500 Nevertheless both globally-meaningful and locally-special names 501 are in use and must be supported. 503 o At the time of the writing of this document the IAB was of the 504 opinion that there might well be more than one name resolution 505 protocol used to resolve Domain Names. 507 4.1.2. Special-Use Domain Names 509 The second important document is "Special-Use Domain Names" 510 [RFC6761]. RFC 6761 represents the current IETF consensus on 511 designating and recording Special-Use Domain Names. The IETF has 512 experienced problems with the designation process described in RFC 513 6761; these concerns motivate this document. Familiarity with RFC 514 6761 is a prerequisite for having an informed opinion on the topic of 515 Special-Use Domain Names. 517 RFC 6761 defines two aspects of Special-Use Domain Names: designating 518 a Domain Name to have a special purpose and registering that special 519 use in the Special-Use Domain Names registry. The designation 520 process is defined in a single sentence (RFC 6761, section 4): 522 If it is determined that special handling of a name is required in 523 order to implement some desired new functionality, then an IETF 524 "Standards Action" or "IESG Approval" specification [RFC5226] MUST 525 be published describing the new functionality. 527 This sentence requires that any designation of a Special-Use Domain 528 Name is subject to the same open review and consensus process as used 529 to produce and publish all other IETF specifications. 531 The registration process is a purely mechanical process, in which the 532 existence of the newly designated Special-Use Domain Name is 533 recorded, with a pointer to a section in the relevant specification 534 document that defines the ways in which special handling is to be 535 applied to the name. 537 RFC 6761 provided the process whereby Multicast DNS [RFC6762] 538 designated ".local" as a Special-Use Domain Name and included it in 539 the Special-Use Domain Names registry. It itself also enumerated a 540 set of names that had been previously used or defined to have special 541 uses prior to the publication of RFC 6761. Since there had been no 542 registry for these names prior to the publication of RFC 6761, the 543 documents defining these names could not have added them to the 544 registry. 546 There are at least several important points to think of with respect 547 to the RFC 6761: 549 o A Special-Use Domain Name may be a name that should be resolved 550 using the DNS protocol with no special handling. An example of 551 this is 'IN-ADDR.ARPA.' (which is an example of a Special-Use 552 Domain Name that is not a TLD). 554 o A Special-Use Domain Name may be a name that is resolved using the 555 DNS protocol, requires no special handling in the stub resolver, 556 but requires special handling in the recursive resolver. An 557 example of this would be "10.in-addr.arpa." 559 o A Special-Use Domain Name may be a name that requires special 560 handling in the stub resolver. An example would be a Special-Use 561 Top-Level Domain Name like '.local' which acts as a signal to 562 indicate that the local stub resolver should use a non-DNS 563 protocol for name resolution. 565 o The current IETF consensus (from a process perspective, not 566 necessarily from the perspective of what would be consensus if the 567 IETF were to attempt to produce a new consensus document) is that 568 all of these purposes for Special-Use Domain Names are valid. 570 The term "stub resolver" in this case does not mean "DNS protocol 571 stub resolver." The stub resolver is the entity within a particular 572 software stack that takes a question about a Domain Name and answers 573 it. One way a stub resolver can answer such a question is using the 574 DNS protocol, but it is in the stub resolver, as we are using the 575 term here, that the decision as to whether to use a protocol, and if 576 so which protocol, or whether to use a local database of some sort, 577 is made. 579 RFC 6761 does not limit Special-Use Domain Names to TLDs. However, 580 at present, all Special-Use Domain Names registered in the IANA 581 Special-Use Domain Names registry [SDO-IANA-SUDR] are either intended 582 to be resolved using the DNS protocol, or are TLDs, or both. That 583 is, at present there exist no Special-Use Domain Names which require 584 special handling by stub resolvers and which are not at the top level 585 of the naming hierarchy. 587 One point to take from this is that there is already a requirement in 588 RFC 6762 that when a stub resolver encounters the special label, 589 '.LOCAL' at the top level of a domain name, it can only use the mDNS 590 protocol to resolve that Domain Name. 592 4.1.3. MoU Concerning the Technical Work of the IANA 594 There exists a Memorandum of Understanding (MOU) [RFC2860] between 595 the IETF and ICANN (Internet Corporation for Assigned Names and 596 Numbers) which discusses how names and numbers will be managed 597 through the IANA (Internet Assigned Numbers Authority). This 598 document is important to the discussion of Special-Use Domain Names 599 because, while it delegates authority for managing the Domain Name 600 System Namespace generally to ICANN, it reserves to the IETF the 601 authority that RFC 6761 formalizes: 603 Note that (a) assignments of Domain Names for technical uses (such 604 as Domain Names for inverse DNS lookup), (b) assignments of 605 specialised address blocks (such as multicast or anycast blocks), 606 and (c) experimental assignments are not considered to be policy 607 issues, and shall remain subject to the provisions of this 608 Section 4. 610 The above text is an addendum to the following: 612 Two particular assigned spaces present policy issues in addition 613 to the technical considerations specified by the IETF: the 614 assignment of Domain Names, and the assignment of IP address 615 blocks. These policy issues are outside the scope of this MOU. 617 In general, then, the assignment of names in the DNS root zone, and 618 the management of the DNS namespace, is a function that is performed 619 by ICANN. However, the MoU specifically exempts domain names 620 assigned for technical use, and uses the example of domains used for 621 inverse DNS lookup. Both 'IN-ADDR.ARPA' and 'IP6.ARPA' are in the 622 Special-Use Domain Names registry. 624 Implicit in the MoU is the fact that the IETF and ICANN retain, 625 between them, sole authority for assigning any names from the Domain 626 Namespace. Both the IETF and ICANN have internal processes for 627 making such assignments. 629 The point here is not to say what the implications of this statement 630 in the MoU are, but rather to call the reader's attention to the 631 existence of this statement. 633 4.1.4. Liaison Statement on Technical Use of Domain Names 635 When the IETF received processing requests to add names to the 636 Special-Use Domain Name registry, as documented in 637 [I-D.chapin-additional-reserved-tlds] and 638 [I-D.grothoff-iesg-special-use-p2p-names], the IETF chartered a 639 review of the process defined in RFC 6761 for adding names to the 640 registry (as explained earlier). The IETF sent a Liaison Statement 641 [SDO-IAB-ICANN-LS] to ICANN to notify ICANN of the review, affirm 642 that the discussion would be "open and transparent to participation 643 by interested parties" and explicitly invite members of the ICANN 644 community to participate. 646 4.2. Secondary documents relating to the Special-Use Domain Name 647 question 649 In addition to these documents, there are several others with which 650 participants in this discussion should be familiar. 652 4.2.1. Multicast DNS 654 Multicast DNS [RFC6762] defines the Multicast DNS protocol, which 655 uses the '.LOCAL' Special-Use Top-Level Domain Name. Section 3 656 describes the semantics of "multicast DNS names." It is of 657 considerable historical importance to note that the -00 version of 658 this document, an individual submission, was published in July of 659 2001. This version contains substantially the same text in section 660 3, and was discussed in the DNSEXT working group at IETF 51 in August 661 of 2001[IETF-PRO-51]. The first version of this document designated 662 '.LOCAL.ARPA' as the Special-Use Domain Name. This idea was strongly 663 opposed by DNSEXT working group participants, and as a result the 664 author eventually switched to using '.LOCAL'. 666 The history of RFC 6762 is documented in substantial detail in 667 Appendix H of RFC 6762; some notable milestones include the initial 668 proposal to replace Appletalk's NBP in July 1997, the chartering of 669 the Zeroconf working group in September 1999, assignment of a 670 multicast address for link-local name discovery in April of 2000. A 671 companion requirements document, eventually published as [RFC6760] 672 was first published in September of 2001. 674 The point of mentioning these dates is so that discussions involving 675 the time when the '.LOCAL' domain was first deployed, and the context 676 in which it was deployed, may be properly informed. 678 4.2.2. The .onion Special-Use Top-Level Domain Name 680 The .onion Special-Use Top-Level Domain Name [RFC7686] is important 681 because it is the most recent IETF action on the topic of Special-Use 682 Domain Names; although it does not set new policy, the mere fact of 683 its publication is worth thinking about. 685 Two important points to consider about this document are that: 687 o The IETF gained consensus to publish it 689 o Devising a resolution to the situation was constrained by at least 690 two factors. First, there was no process for allocating special- 691 use domain names at the time that the .onion project started using 692 the name, and since at the time the scope of use of the name was 693 expected to be very constrained, the developers chose to allocate 694 it unilaterally rather than asking the IETF or some other SDO to 695 create a new process. 697 Second, for some time, the CA/Browser Forum [SDO-CABF] had been 698 issuing certificates for what they referred to as "internal 699 names." Internal names are names allocated unilaterally for use 700 in site-specific contexts. Issuing certificates for such names 701 came to be considered problematic, since no formal process for 702 testing the validity of such names existed. Consequently, CA/ 703 Browser Forum decided to phase out the use of such names in 704 certificates [SDO-CABF-INT], and set a deadline after which no new 705 certificates for such names would be issued [SDO-CABF-DEADLINE]. 706 Because the .onion domain was allocated unilaterally, this would 707 mean that certificates for subdomains of .onion could no longer be 708 issued. 710 The IETF's designation of .onion as a Special-Use Top-Level Domain 711 Name was needed to facilitate the development of a certificate 712 issuance process specific to .onion domain names 713 [SDO-CABF-BALLOT144]. 715 4.2.3. Locally Served DNS Zones 717 Locally Served DNS Zones [RFC6303] describes a particular use case 718 for zones that exist by definition, and that are resolved using the 719 DNS protocol, but that cannot have a global meaning, because the host 720 IP addresses they reference are not unique. This applies to a 721 variety of addresses, including Private IPv4 addresses [RFC1918], 722 Unique Local IPv6 Unicast Addresses [RFC4193] (in which this practice 723 was first described) and IANA-Reserved IPv4 Prefix for Shared Address 724 Space [RFC6598]. 726 This use case is distinct from the use-case for Special-Use Domain 727 Names like '.local' and '.onion' in that the names are resolved using 728 the DNS protocol (but do require extensions or exceptions to the 729 usual DNS resolution to enforce resolution in a local context rather 730 than the global DNS context). But it shares the problem that such 731 names cannot be assumed either to be unique or to be functional in 732 all contexts for all Internet-connected hosts. 734 4.2.4. Name Collision in the DNS 736 Name Collision in the DNS [SDO-ICANN-COLL] is a study commissioned by 737 ICANN that attempts to characterize the potential risk to the 738 Internet of adding global DNS delegations for names that were not 739 previously delegated in the DNS, not reserved under any RFC, but also 740 known to be (.home) or surmised to be (.corp) in significant use for 741 Special-Use-type reasons (local scope DNS, or other resolution 742 protocols altogether). 744 4.2.5. SSAC Advisory on the Stability of the Domain Namespace 746 ICANN SSAC ([SDO-ICANN-SSAC]) Advisory on the Stability of the Domain 747 Namespace [SDO-ICANN-SAC090] reports on some issues surrounding the 748 conflicting uses, interested parties and processes related to the 749 Domain Namespace. The document recommends the development of 750 collaborative processes among the various interested parties to 751 coordinate their activities related to the Domain Namespace. 753 4.2.6. Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 755 Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis 756 [RFC7050] is an example of a document that successfully used the RFC 757 6761 process to designate '.ipv4only.arpa' as a Special-Use Domain 758 Name; in this case the process worked smoothly and without 759 controversy. 761 Unfortunately, while the IETF process worked smoothly, in the sense 762 that there was little controversy or delay in approving the new use, 763 it did not work correctly: the name "ipv4only.arpa" was never added 764 to the Special-Use Domain Names registry. This appears to have 765 happened because the document did not explicitly request the addition 766 of an entry for "ipv4only.arpa" in the Special-Use Domain Name 767 registry. This is an illustration of one of the problems that we 768 have with the 6761 process: it is apparently fairly easy to miss the 769 step of adding the name to the registry. 771 4.2.7. Additional Reserved Top Level Domains 773 Additional Reserved Top Level Domains 774 [I-D.chapin-additional-reserved-tlds] is an example of a document 775 that attempted to reserve several TLDs identified by ICANN as 776 particularly at risk for collision as Special-Use Domain Names with 777 no documented use. This attempt failed. 779 Although this document failed to gain consensus to publish, the need 780 it was intended to fill still exists. Unfortunately, although a fair 781 amount is known about the use of these names, no RFC documents how 782 they are used, and why it would be a problem to delegate them. 783 Additionally, to the extent that the uses being made of these names 784 are valid, no document exists indicating when it might make sense to 785 use them, and when it would not make sense to use them. 787 RFC 7788 [RFC7788] defines the Domain Name TLD ".home" for use as the 788 default name for name resolution relative to a home network context. 789 Although, as defined in RFC 7788, ".home" is a Special-Use Domain 790 Name, RFC 7788 did not follow the process specified in RFC 6761: it 791 did not request that ".home" be added to the IANA Special-Use Domain 792 Name registry. This was recognized as a mistake, and resulted in the 793 publication of an errata, [ERRATA-4677]. Additionally, ".home" is an 794 example of an attempt to reuse a Domain Name that has already been 795 put into use for other purposes without following established 796 processes[SDO-ICANN-COLL], which further complicates the situation. 797 At the time this document was written, the IETF was developing a 798 solution to this problem. 800 5. History 802 Newcomers to the problem of resolving Domain Names may be under the 803 mistaken impression that the DNS sprang, as in the Greek legend of 804 Athena, directly from Paul Mockapetris' forehead. This is not the 805 case. At the time of the writing of the IAB technical document 806 ([RFC2826]), memories would have been fresh of the evolutionary 807 process that led to the DNS' dominance as a protocol for Domain Name 808 resolution. 810 In fact, in the early days of the Internet, hostnames were resolved 811 using a text file, HOSTS.TXT, which was maintained by a central 812 authority, the Network Information Center, and distributed to all 813 hosts on the Internet using the File Transfer Protocol (FTP) 814 [RFC0959]. The inefficiency of this process is cited as a reason for 815 the development of the DNS [RFC0882] [RFC0883] in 1983. 817 However, the transition from HOSTS.TXT to the DNS was not smooth. 818 For example, Sun Microsystems's Network Information System 819 [CORP-SUN-NIS], at the time known as Yellow Pages, was an active 820 competitor to the DNS, although it failed to provide a complete 821 solution to the global naming problem. 823 Another example was NetBIOS Name Service, also known as WINS 824 [RFC1002]. This protocol was used mostly by Microsoft Windows 825 machines, but also by open source BSD and Linux operating systems to 826 do name resolution using Microsoft's own name resolution protocol. 828 Most modern operating systems can still use the '/etc/hosts' file for 829 name resolution. Many still have a name service switch that can be 830 configured on the host to resolve some domains using NIS or WINS. 831 Most have the capability to resolve names using mDNS by recognizing 832 the special meaning of the '.local' Special-Use Top Level Domain 833 Name. 835 The Sun Microsystems model of having private domains within a 836 corporate site, while supporting the global Domain Name system for 837 off-site, persisted even after the NIS protocol fell into disuse. 838 Microsoft used to recommend that site administrators use a "private" 839 TLD for internal use, and this practice was very much a part of the 840 zeitgeist at the time (see section 5.1 of [SDO-ICANN-COLL] and 841 Appendix G of [RFC6762]). This attitude is at the root of the 842 widespread practice of simply picking an apparently-unused TLD and 843 using it for experimental purposes, which persists even at the time 844 of writing of this memo. 846 This history is being presented because discussions about Special-Use 847 Domain Names in the IETF often come down to the question of why users 848 of new name resolution protocols choose to use Domain Names, rather 849 than using some other naming concept that doesn't overlap with the 850 namespace that, in modern times is, by default, resolved using the 851 DNS. 853 The answer is that as a consequence of this long history of resolving 854 Domain Names using a wide variety of name resolution systems, Domain 855 Names are required in a large variety of contexts in user interfaces 856 and applications programming interfaces. Any name that appears in 857 such a context is a Domain Name. So developers of new name 858 resolution systems that must work in existing contexts actually have 859 no choice: they must use a Special-Use Domain Name to segregate a 860 portion of the namespace for use with their system. 862 6. Security Considerations 864 This document mentions various security and privacy considerations in 865 the text. However, this document creates no new security or privacy 866 concerns. 868 7. IANA considerations 870 This document has no actions for IANA. 872 8. Contributors 874 Mark Andrews, Stuart Cheshire, David Conrad, Paul Ebersman, Aaron 875 Falk and Suzanne Woolf all made helpful and insightful observations 876 or patiently answered questions. This should not be taken as an 877 indication that any of these folks actually agree with what the 878 document says, but their generosity with time and thought are 879 appreciated in any case. 881 Stephane Bortzmeyer, John Dickinson, Bob Harold, Paul Hoffman, Russ 882 Housley, Joel Jaeggli, Andrew McConachie, George Michaelson, Petr 883 Spacek and others provided significant review and / or useful 884 comments. 886 This document also owes a great deal to Ed Lewis' excellent work on 887 what a "Domain Name" is [I-D.lewis-domain-names]. 889 9. RFC Editor Considerations 891 The authors were unable to find dates for references 892 [SDO-CABF-DEADLINE] and [SDO-CABF]. Please fix up those references 893 as appropriate (and remove this section before publication). 895 10. Informative References 897 [CORP-SUN-NIS] 898 Sun Microsystems, "Large System and Network 899 Administration", March 1990. 901 [ERRATA-4677] 902 Internet Architecture Board, "Errata ID: 4677 (RFC7788)", 903 April 2016, . 905 [I-D.chapin-additional-reserved-tlds] 906 Chapin, L. and M. McFadden, "Additional Reserved Top Level 907 Domains", draft-chapin-additional-reserved-tlds-02 (work 908 in progress), March 2015. 910 [I-D.grothoff-iesg-special-use-p2p-names] 911 Grothoff, C., Wachs, M., hellekin, h., Appelbaum, J., and 912 L. Ryge, "Special-Use Domain Names of Peer-to-Peer 913 Systems", draft-grothoff-iesg-special-use-p2p-names-04 914 (work in progress), January 2015. 916 [I-D.lewis-domain-names] 917 Lewis, E., "Domain Names, A Case for Clarifying", draft- 918 lewis-domain-names-09 (work in progress), August 2017. 920 [IETF-PRO-51] 921 Internet Engineering Task Force, "Proceedings of the 51st 922 IETF", August 2001, 923 . 925 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 926 RFC 882, DOI 10.17487/RFC0882, November 1983, 927 . 929 [RFC0883] Mockapetris, P., "Domain names: Implementation 930 specification", RFC 883, DOI 10.17487/RFC0883, November 931 1983, . 933 [RFC0959] Postel, J. and J. Reynolds, "File Transfer Protocol", 934 STD 9, RFC 959, DOI 10.17487/RFC0959, October 1985, 935 . 937 [RFC1002] NetBIOS Working Group in the Defense Advanced Research 938 Projects Agency, Internet Activities Board, and End-to-End 939 Services Task Force, "Protocol standard for a NetBIOS 940 service on a TCP/UDP transport: Detailed specifications", 941 STD 19, RFC 1002, DOI 10.17487/RFC1002, March 1987, 942 . 944 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 945 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 946 . 948 [RFC1035] Mockapetris, P., "Domain names - implementation and 949 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 950 November 1987, . 952 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 953 and E. Lear, "Address Allocation for Private Internets", 954 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 955 . 957 [RFC2352] Vaughan, O., "A Convention For Using Legal Names as Domain 958 Names", RFC 2352, DOI 10.17487/RFC2352, May 1998, 959 . 961 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 962 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 963 2000, . 965 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 966 Understanding Concerning the Technical Work of the 967 Internet Assigned Numbers Authority", RFC 2860, 968 DOI 10.17487/RFC2860, June 2000, 969 . 971 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 972 Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005, 973 . 975 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 976 RFC 6303, DOI 10.17487/RFC6303, July 2011, 977 . 979 [RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and 980 M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address 981 Space", BCP 153, RFC 6598, DOI 10.17487/RFC6598, April 982 2012, . 984 [RFC6760] Cheshire, S. and M. Krochmal, "Requirements for a Protocol 985 to Replace the AppleTalk Name Binding Protocol (NBP)", 986 RFC 6760, DOI 10.17487/RFC6760, February 2013, 987 . 989 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 990 RFC 6761, DOI 10.17487/RFC6761, February 2013, 991 . 993 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 994 DOI 10.17487/RFC6762, February 2013, 995 . 997 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 998 the IPv6 Prefix Used for IPv6 Address Synthesis", 999 RFC 7050, DOI 10.17487/RFC7050, November 2013, 1000 . 1002 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 1003 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 1004 2015, . 1006 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1007 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1008 2015, . 1010 [RFC7788] Stenberg, M., Barth, S., and P. Pfister, "Home Networking 1011 Control Protocol", RFC 7788, DOI 10.17487/RFC7788, April 1012 2016, . 1014 [SDO-CABF] 1015 CA/Browser Forum, "CA/Browser Forum", ??? ????, 1016 . 1018 [SDO-CABF-BALLOT144] 1019 CA/Browser Forum, "Ballot 144 - Validation Rules for 1020 .onion Names", February 2015, 1021 . 1024 [SDO-CABF-DEADLINE] 1025 CA/Browser Forum, "SSL Certificates for Internal Server 1026 Names", ??? ????, . 1029 [SDO-CABF-INT] 1030 CA/Browser Forum, "Guidance on the Deprecation of Internal 1031 Server Names and Reserved IP Addresses", June 2012, 1032 . 1034 [SDO-IAB-ICANN-LS] 1035 Internet Architecture Board, "Liaison Statement from the 1036 IAB to the ICANN Board on Technical Use of Domain Names", 1037 September 2015, . 1040 [SDO-IANA-SUDR] 1041 Internet Assigned Numbers Authority, "Special-Use Domain 1042 Names registry", October 2015, 1043 . 1046 [SDO-ICANN-COLL] 1047 Interisle Consulting Group, LLC, "Name Collisions in the 1048 DNS", August 2013, 1049 . 1052 [SDO-ICANN-DAG] 1053 Internet Assigned Numbers Authority, "Special-Use Domain 1054 Names registry", October 2015, 1055 . 1058 [SDO-ICANN-SAC090] 1059 ICANN Security and Stability Advisory Committee, "SSAC 1060 Advisory on the Stability of the Domain Namespace", 1061 December 2016, 1062 . 1065 [SDO-ICANN-SSAC] 1066 ICANN Security and Stability Advisory Committee, "SSAC 1067 Advisory on the Stability of the Domain Namespace", 1068 December 2016, . 1070 [TOR] The Tor Project, "Tor", 2017, 1071 . 1073 Appendix A. Change Log. 1075 -06 to -07: 1077 o Issue #88: Bulleted list should be numbered, not unordered - 1078 Updated the list of problems to be numbered, instead of unordered. 1079 This is to allow future documents to refer to specific issues. 1081 o Misc: Removed duplicate word ("that that" -> "that") 1083 o Backfilled the "Change Log" to reflect the issues addressed 1084 between Version -05 and -06. 1086 -05 to -06: 1088 o Issue #87: Section 4.2.2: expand "certs" to "certificates" 1090 o Issue #86: Stephane Bortzmeyer: lying DNS resolvers 1092 o Issue #85: Stephane Bortzmeyer: unilateral use 1093 o Issue #84: Stephane Bortzmeyer: Use of the registry is 1094 inconsistent 1096 o Issue #83: Stephane Bortzmeyer: IETF-ICANN have a liaison 1097 relationship 1099 o Issue #82: Bob Harold: extra "be used" 1101 o Issue #81: Editorial changes from Benoit Claise AD review 1103 o Issue #80: Section 3 - Clarify citation of SDO-ICANN-COLL 1105 o Issue #79: Update reference to "Special-Use Domain Names registry" 1106 (?) 1108 o Issue #78: Section 4.2.7 - add citation of Errata correcting use 1109 of ".home" in RFC 7788 1111 o Issue #77: Section 2 - correct citation of definition of gTLD 1113 o Issue #76: Section 3 - clarify that problems are listed regardless 1114 of validity or ownership, 1116 o Issue #74, #75: Meaning versus binding (Andrew McConachie), 1117 global/local (Andrew McConachie) 1119 o Issue #73: Editorial improvements, Section 4.2.7 1121 -03 to -04: 1123 o Issue #72: Corrected original text to reflect that RFC 7050 1124 neglected to request an SUDN registry entry for "ipv4only.arpa", 1125 but any inference about the cause for the oversight would be 1126 speculation. 1128 o Issue #69: Edited Joel's suggested text. 1130 o Issue #67: Minor change to Joel's suggested text. 1132 o Issue #66: Edited second text update suggested by Joel and 1133 reverted third change back to the original text. 1135 o Issue #64: Minor changes to text suggested by Joel. 1137 o Issue #61: Minor edit based on authors' consensus in response to 1138 Joel's comment. 1140 o Addressed Joel / Benoit's AD comments. See GH issues 1141 -02 to -03 (in Github): 1143 o Passes idnits except for errors resulting from a reference to an 1144 RFC 2119 keyword and a citation of RFC 5226 with no matching 1145 reference in quoted text at line 493. 1147 o Issue #60: Add new section "6. Summary" -- Petr Spacek 1148 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/60 1150 o Issue #57: Document needs an "Security Considerations" section 1151 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/57 1153 o Numerous editorial changes for consistency; e.g. use "Special-Use 1154 Domain Names" throughout. 1156 o Issue #58: Document needs an "IANA Considerations" section 1157 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/58 1159 o Issue #39: Overlapping bullets in Section 3, with proposed 1160 restructuring -- Russ Housley https://github.com/Abhayakara/draft- 1161 tldr-sutld-ps/issues/39 1163 o Issue #55: Editorial improvement to Section 3 (4) -- John 1164 Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1165 issues/55 1167 o Issue #34: Separate two problems in paragraph that begins "No 1168 mechanism exists for adding a name to the registry...." (2 issues) 1169 -- Suzanne Woolf https://github.com/Abhayakara/draft-tldr-sutld- 1170 ps/issues/34 1172 o Issue #52: Editorial improvement to Section 3 (1) -- John 1173 Dickinson https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1174 issues/52 1176 o Issue #51: Clarification in Introduction -- John Dickinson 1177 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/51 1179 o Issue #49: Should cite https://datatracker.ietf.org/liaison/1351 1180 -- George Michaelson https://github.com/Abhayakara/draft-tldr- 1181 sutld-ps/issues/49 1183 o Issue #50: IETF precedence in Special-Use names registry -- Ted 1184 Lemon https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/50 1186 o Issue #48: 4.1.2 cites sub-domains of .ARPA arguing for special 1187 use TLD -- George Michaelson https://github.com/Abhayakara/draft- 1188 tldr-sutld-ps/issues/48 1190 o Issue #47: 4.3 should be made more prominent -- George Michaelson 1191 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/47 1193 o Issue #43: Spell out SUDN and SUTLDN rather than use acronyms -- 1194 Russ Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1195 issues/43 1197 o Issue #41: Reword bullet in Section 3 regarding Domain Name TLDs 1198 that have been commandeered, as reported in SDO-ICANN-COLL -- Russ 1199 Housley https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1200 issues/41 1202 o Issue #40: Note that time to publish spec for .local included 1203 inventing SUDN registry -- Russ Housley 1204 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/41 1206 o Issue #37: Title should be "Special-Use Domain Names Problem 1207 Statement" -- Russ Housley https://github.com/Abhayakara/draft- 1208 tldr-sutld-ps/issues/37 1210 o Issue #36: Expand on desire for Special-Use names to be human- 1211 readable -- Suzanne Woolf https://github.com/Abhayakara/draft- 1212 tldr-sutld-ps/issues/36 1214 o Issue #35: Clarify "No process exists [...]" to include both IETF 1215 process and other process -- Suzanne Woolf 1216 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/35 1218 o Issue #31: Add justification for concern about IETF's ability to 1219 assign names for technical use -- Suzanne Woolf 1220 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/31 1222 o Issue #12: Add DNSSEC to text -- John Levine 1223 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/12 1225 o Issue #6: Without a process, we just have chaos -- Stuart Cheshire 1226 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/6 1228 o Issue #32: Have assignments through RFC 6761 really had "technical 1229 mistakes"? -- Suzanne Wolff https://github.com/Abhayakara/draft- 1230 tldr-sutld-ps/issues/32 1232 o Issue #29: Add a reason to bypass external process: expectation 1233 for use of new name to be restricted to local scope -- Suzanne 1234 Wolff https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/29 1236 o Issue #27: Is "technical use" really ambiguous; too inclusive for 1237 some people and too limited for others -- Suzanne Wolff 1238 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/27 1240 o Issue #24: Replacement for "commandeer" (2 issues)-- Suzanne Wolff 1241 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/24 1243 o Issue #22: Clarify importance of the "root of the Domain 1244 Namespace" -- Suzanne Wolff https://github.com/Abhayakara/draft- 1245 tldr-sutld-ps/issues/22 1247 o Issue #21: Section 3 - clarify paragraphs 2 and 3 -- Suzanne Wolff 1248 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/21 1250 o Issue #20: Section 3: Clarify sentences beginning "Solutions to 1251 these problems..." -- Suzanne Wolff https://github.com/Abhayakara/ 1252 draft-tldr-sutld-ps/issues/20 1254 o Issue #19: Define "default" or "assumed" use of domain names to be 1255 within DNS -- Suzanne Wolff https://github.com/Abhayakara/draft- 1256 tldr-sutld-ps/issues/19 1258 o Issue #18: Cite definition of RFC 7719 and domain names draft in 1259 definition of "domain name" -- Suzanne Wolff 1260 https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/18 1262 o Issue #45: Correct usages of Tor Browser and Tor -- Russ Housley 1263 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/45) 1265 o Issue #46: Reformat citation of RFC 2860 -- Russ Housley 1266 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/46) 1268 o Issue #44: Clean up reference to SDO-ICANN-DAG in first bullet in 1269 section 3 -- Russ Housley (https://github.com/Abhayakara/draft- 1270 tldr-sutld-ps/issues/44) 1272 o Issue #42: Add reference to SDO-ICANN-SAC090 in section 4.2.5 -- 1273 Russ Housley (https://github.com/Abhayakara/draft-tldr-sutld-ps/ 1274 issues/42) 1276 o Issue #30: Leaked queries aren't an operational problem in 1277 practice -- Suzanne Wolf (https://github.com/Abhayakara/draft- 1278 tldr-sutld-ps/issues/30) 1280 o Address some of the simpler issues, including: 1282 o Issue #13: Spelling of Tor -- Jeremy Rand 1283 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/13) 1285 o Issue #14: Change SDO to "organizations" -- Suzanne Woolf 1286 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) 1288 o Issue #16: Match number of "policies" and "that policy" -- Suzanne 1289 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/16) 1291 o Issue #17: Clarify sentence beginning with "In support of the 1292 particular set of problems described here...." -- Suzanne. 1293 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/14) 1295 o Issue #23: Match number of "names" and "a TLD" -- Suzanne. 1296 (https://github.com/Abhayakara/draft-tldr-sutld-ps/issues/23) 1298 -01 to -02: 1300 o Language cleanup from Ted. 1302 -00 to -01: 1304 o Improved the terminology. 1306 o Included reference to SAC090. 1308 o Added ICANN Reserved Names (e.g .icann, .iesg, .arin) to types of 1309 names. 1311 o Improved background. 1313 o Noted that semantics may differ between resolution contexts. 1315 o Pointer to .home / .corp / .mail, other "toxic" names 1317 o Readability fixes. 1319 -04 to ietf-00 1321 o Document adopted by WG. 1323 o Significant changes from CfA integrated, please refer to diff. 1325 -03 to -04: 1327 o Replaced 'Internet Names' with 'Domain Names' - suggestion by John 1328 Levine. 1330 -02 to -03: 1332 o Readability fixes, small grammar updates. 1334 -01 to -02: 1336 o Cleaned up the abstract. 1338 o Fixed the case of Internet 1340 o Reference to Ed Lewis' "Domain Names" 1342 o Fleshed out the problems, primarily the coordination, collisions 1343 ones. 1345 -00 to -01: 1347 o Large refactoring, basically a rewrite. Incorporated comments, 1348 removed a bunch of unneeded text, etc. 1350 Authors' Addresses 1352 Ted Lemon 1353 Nominum, Inc. 1354 800 Bridge Parkway 1355 Redwood City, California 94065 1356 United States of America 1358 Phone: +1 650 381 6000 1359 Email: ted.lemon@nominum.com 1361 Ralph Droms 1363 Email: rdroms.ietf@gmail.com 1365 Warren Kumari 1366 Google 1367 1600 Amphitheatre Parkway 1368 Mountain View, CA 94043 1369 US 1371 Email: warren@kumari.net