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