idnits 2.17.1 draft-adpkja-dnsop-special-names-problem-00.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 abstract seems to contain references ([RFC6761]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2015) is 3111 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 435, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 439, but no explicit reference was found in the text == Unused Reference: 'I-D.lewis-domain-names' is defined on line 465, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 469, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-01 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Abley 3 Internet-Draft Dyn, Inc. 4 Intended status: Informational P. Koch 5 Expires: April 21, 2016 DENIC 6 A. Durand 7 ICANN 8 October 19, 2015 10 Problem Statement for the Reservation of Top-Level Domains in the 11 Special-Use Domain Names Registry 12 draft-adpkja-dnsop-special-names-problem-00 14 Abstract 16 The dominant protocol for name resolution on the Internet is the 17 Domain Name System (DNS). However, other protocols exist that are 18 fundamentally different from the DNS, but which have syntactically- 19 similar namespaces. 21 When an end-user triggers resolution of a name on a system which 22 supports multiple, different protocols for name resolution, it is 23 desirable that the protocol to be used is unambiguous, and that 24 requests intended for one protocol are not inadvertently addressed 25 using another. 27 [RFC6761] introduced a framework by which, under certain 28 circumstances, a particular domain name could be acknowledged as 29 being special. This framework has been used to make top-level domain 30 reservations, that is, particular top-level domains that should not 31 be used within the DNS to accommodate parallel use of non-DNS name 32 resolution protocols by end-users and avoid the possibility of 33 namespace collisions. 35 Various challenges have become apparent with this application of the 36 guidance provided in [RFC6761]. This document aims to document those 37 challenges in the form of a problem statement, to facilitate further 38 discussion of potential solutions. 40 Status of This Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 This Internet-Draft will expire on April 21, 2016. 57 Copyright Notice 59 Copyright (c) 2015 IETF Trust and the persons identified as the 60 document authors. All rights reserved. 62 This document is subject to BCP 78 and the IETF Trust's Legal 63 Provisions Relating to IETF Documents 64 (http://trustee.ietf.org/license-info) in effect on the date of 65 publication of this document. Please review these documents 66 carefully, as they describe your rights and restrictions with respect 67 to this document. Code Components extracted from this document must 68 include Simplified BSD License text as described in Section 4.e of 69 the Trust Legal Provisions and are provided without warranty as 70 described in the Simplified BSD License. 72 Table of Contents 74 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 3. RFC6761 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 4. Architectural considerations . . . . . . . . . . . . . . . . 5 78 5. Technical considerations . . . . . . . . . . . . . . . . . . 6 79 6. Organizational considerations . . . . . . . . . . . . . . . . 7 80 6.1. Non-exhaustive list of external organizational 81 considerations . . . . . . . . . . . . . . . . . . . . . 7 82 6.2. IETF Internal considerations . . . . . . . . . . . . . . 8 83 6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 8 84 6.2.2. Technical criteria . . . . . . . . . . . . . . . . . 8 85 6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 9 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 90 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 91 10.2. Informative References . . . . . . . . . . . . . . . . . 10 92 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 11 93 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 11 94 A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 11 95 A.3. Change History . . . . . . . . . . . . . . . . . . . . . 12 96 A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 12 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 99 1. Terminology 101 Clear and unambiguous use of terminology is important for the clear 102 formulation of any problem statement. The DNS protocol suffers from 103 imprecise and overloaded terminology (e.g. see 104 [I-D.ietf-dnsop-dns-terminology]) without confusing matters further 105 with terms and concepts from other naming systems that are similar, 106 but different. 108 In the interests of clarity, the following terms used in this 109 document are to be interpreted as follows: 111 Aardvark (n): a medium-sized, burrowing, nocturnal mammal native 112 to Africa; the only living species of the order Tubulidentata. 113 See . This is a 114 placeholder. 116 Registry (n): the Special-Use Domain Names Registry created by 117 [RFC6761] and published at 120 [This section to be completed following review and refinement of the 121 rest of the text.] 123 2. Introduction 125 In recent years, using the last label of a domain name (aka TLD) as 126 switch to indicate how to treat name resolution has been experimented 127 using the framework of [RFC6761]. Examples of such switches include: 128 .example (don't resolve), .local (use mDNS), .onion (use tor), any 129 TLD registered in IANA-maintained root-zone (use DNS). 131 Such usage, which a few commenters have referred to as "protocol 132 switching," is not limited to "protocol switch" in the strict sense 133 of indicating specific protocols on the wire. It could indicate to 134 switch to another name space (eg .onion), use a different protocol 135 (eg tor, or mdns), or indicate to use a local DNS scope by not using 136 the DNS root for name resolution (eg .home in homenet) or something 137 else altogether. 139 This switch practice is not explicitly documented anywhere. Indeed, 140 the full semantics of domain names isn't really documented anywhere 141 either, although [Ed Lewis domain-names draft] is a current attempt 142 to catalog the precedents. 144 [RFC6761] defines ways to reserve domain names and is now used to 145 augment the technical exemption made in [RFC2860] (IETF-ICANN MoU): 147 "Note that (a) assignments of domain names for technical uses 148 (such as domain names for inverse DNS lookup), (b) assignments of 149 specialized address blocks (such as multicast or anycast blocks), 150 and (c) experimental assignments are not considered to be policy 151 issues, and shall remain subject to the provisions of this 152 Section 4." 154 The discussions in the DNSOP WG and the IETF Last Call processes 155 about the .onion registration in the Special Use Domain Names 156 registry (1,200 messages) have made it apparent that clarity about if 157 and how to treat this "protocol switching" practice would help a lot 158 in deciding the merit of future similar applications. One possible 159 outcome of the discussion would be to decline to recognize such usage 160 of domain names in the architecture, another one is to formalize it 161 and understand better the issues that come with it. 163 3. RFC6761 165 In Section 5, [RFC6761] describes seven questions to be answered in 166 order to provide clear guidance about how and why a particular domain 167 name is special. These seven questions can be broadly categorized as 168 follows: 170 1. impact on end-users; 172 2. impact on applications; 174 3. impact on name resolution APIs and libraries; 176 4. impact on recursive resolvers; 178 5. impact on authoritative DNS servers; 180 6. impact on DNS server operators; 182 7. impact on DNS registries and registrars. 184 Answers to these seven questions provide guidance to the 185 corresponding seven audiences on how to handle a special-use domain 186 name once it has been reserved by inclusion in the Registry. 187 However, they are inadequate for making the determination whether a 188 particular domain name qualifies as being special in the first place. 190 This memo proposes to categorize considerations related to switches 191 in 3 categories: Architectural, Technical and Organizational. This 192 memo then lists a number of questions to drive the discussion. The 193 list of issues discussed here is non-exhaustive. 195 4. Architectural considerations 197 The first thing to consider in this discussion is that not all names 198 (or domain names) are par of the Domain Name System. See [ID-lewis- 199 domain-names] for an in-depth discussion on this topic. 201 At the time of writing, three top-level domain names reserved by 202 inclusion in the Registry are used by name resolution protocols other 203 than the DNS: 205 LOCALHOST is used to refer to the host on which the name 206 resolution takes place, without reference to the DNS; 208 LOCAL is used by the Multicast DNS protocol specified in [RFC6762] 209 which is similar in some respects to the DNS, but which uses 210 different well-known port number and is limited to a particular 211 multicast scope; 213 ONION is used to construct names that designate anonymous hidden 214 services reachable via the Tor network using onion routing. 216 The three name resolution protocols described above are, to varying 217 degrees, different from the DNS, and the namespaces used in each 218 naming scheme are also different (albeit similar, in some cases). 219 The top-level label is effectively being used as a name resolution 220 protocol identifier. The lack of a more elegant way to specify a 221 name resolution protocol in (for example) a URI amounts to an 222 architectural oversight. However, it is not clear that this is still 223 a problem that can be solved; it could be argued that in the absence 224 of a more elegant alternative, a pragmatic choice to embed protocol 225 selectors as namespace tokens has effectively already been made. The 226 running code and effective consensus in how it should be used by 227 significant user bases should not be discounted. Although the 228 reservation of names in the DNS namespace can be made at any level, 229 the three examples above demonstrate use-cases for reservation at the 230 top-level, and hence that case must be considered. 232 In [RFC2826] the IAB noted that 234 "To remain a global network, the Internet requires the existence 235 of a globally unique public name space. The DNS name space is a 236 hierarchical name space derived from a single, globally unique 237 root." 239 "Maintaining a globally-unique public namespace that supports 240 different name resolution protocols is hence an architectural 241 requirement, and some facility for reservation of top-level 242 domains in the DNS is necessary." 244 If we accept the notion that the most significant label of a domain 245 name is actually a protocol switch, it implies that we are actually 246 building a catalog of all top level domains that explain which are 247 are switches. Note that such a catalog does not formally exist 248 today. It may remain a concept to guide this discussion or be 249 implemented as an actual IANA registry. In effect, it associates 250 TLDs with indications on how applications and resolvers should treat 251 them. 253 It should also be noted that there are other choice than using the 254 most significant label for a protocol switch. In particular, a 255 proposal to move those protocol switches under a specific top level 256 domain has been discussed (.ALT). If that architecture choice is 257 made, some of the questions listed in the sections bellow would 258 become moot. 260 Note: [RFC6761] mentions the reserved names could be any label in any 261 random string, not just the rightmost one (or ones). However, this 262 creates a number of complications and has not seen much support in 263 the community as of now. 265 5. Technical considerations 267 Each of the seven questions posed by [RFC6761] has the potential to 268 expose special handling of particular names in applications by a 269 particular audience. However, it is not clear what any of those 270 audiences might reasonably expect as a result of a successful request 271 to add a top-level domain to the Registry. 273 For example, reservation of a top-level domain by the IETF does not 274 guarantee that DNS queries for names within a reserved domain will 275 not be sent over the Internet. The requirements of the operators of 276 recursive resolvers in the DNS cannot be relied upon to be 277 implemented; the impact on the operators of DNS authoritative servers 278 hence cannot be reliably assumed to be zero. In the case of [I- 279 D.ietf-dnsop-onion-tld], leakage of ONION queries on the Internet 280 might lead to disclosure of private information that, in some cases, 281 might pose a risk to the personal safety of end-users. 283 At the time of writing, the [RFC6761] registry does not include 284 direct guidance for any of the seven audiences, relying instead upon 285 a reference for each entry in the Registry to the document that 286 requested its insertion. Such documents might well be opaque to many 287 readers ([RFC6762] is a seventy-page protocol specification, for 288 example, which is arguably not the most expressive way to set 289 expectations of non-technical end-users). 291 Useful reservations of top-level domains should be accompanied by 292 documentation of realistic expectations of each of the seven 293 audiences, and the evaluation of particular requests should consider 294 the practical likelihood of those expectations being met and the 295 implications if they are not. 297 Here is a non-exhaustive list of additional questions that have 298 surfaced in discussion of requests for names to be added to the 299 Special Use Names registry: 301 What does it mean to have a "non-DNS" entry in the registry 302 described above? 304 Are applications supposed to check that registry to know what to 305 do? 307 Can/Should applications do this check dynamically? 309 What if an application makes this dynamic check and realizes the 310 name contains a switch it does not know how to treat? 312 Similar questions applies to resolvers (DNS and non-DNS), what is the 313 expected behavior? 315 6. Organizational considerations 317 Organizational considerations can be broken down in two categories, 318 internal and external. 320 6.1. Non-exhaustive list of external organizational considerations 322 The policy surrounding the implementation and management of top-level 323 domains in the DNS has been developed using a multi-stakeholder 324 process convened by ICANN according to the MoU between ICANN and IETF 325 [RFC2860]. 327 Whilst discussing the particular attributes that make a domain name 328 special, [RFC6761] notes that "the act of defining such a special 329 name creates a higher-level protocol rule, above ICANN's management 330 of allocatable names on the public Internet." 332 Using top level domains as protocol switches blurs the line expressed 333 in [RFC2860] between what is policy vs what is technical. In 334 particular, if the IETF formalizes this concept in the Internet 335 architecture, coordination will be require between ICANN and IETF on 336 such names. Using the analogy described above of a catalog/registry 337 of such switches, care must be applied to make sure we do not end up 338 with 2 process streams allowed to create entries without some form of 339 synchronization 341 6.2. IETF Internal considerations 343 6.2.1. Process 345 [RFC6761] specifies the way in which "an IETF 'Standards Action' or 346 'IESG Approval' document" should present answers to the questions 347 described above (see Section 2), but does not describe the process by 348 which the answers to those questions should be evaluated. 350 For example, it is not clear who is responsible for carrying out an 351 evaluation. A document which requests additions to the Registry 352 might be performed by the IESG, by the IAB, by the DNSOP working 353 group, by an ad-hoc working group, by expert review or any 354 combination of those approaches. [RFC6761] provides no direction. 356 As an illustration of the inconsistency that has been observed 357 already, [RFC6762] was published as an AD-sponsored individual 358 submission in the INT area, and the IESG evaluation record does not 359 reveal any discussion of the reservation of the LOCAL top-level 360 domain in the DNS. [I-D.ietf-dnsop-onion-tld], however, was 361 published as a working group document through DNSOP, and an extensive 362 discussion by both the participants of DNSOP and the IESG on the 363 merits of the request took place. The evaluation process, in the 364 absence of clear direction, is demonstrably inconsistent. 366 At the time of writing, the DNSOP working group charter does not 367 clearly indicate that DNSOP is the proper venue for the evaluation to 368 be carried out, although it also says that matters regarding the 369 namespace are on topic. Also, as pointed out in section 3.2), we are 370 not dealing with a DNS-only issue, but also with an application 371 issue. It is not clear at all if a DNS-centric venue such as DNSop 372 is the right one to examine the merits of [RFC6761] candidates. 374 6.2.2. Technical criteria 376 Regardless of the actual name being proposed as protocol switch, it 377 is also not clear what technical criteria should the evaluation body 378 use to examine the merit of an application for such a reserved name/ 379 protocol switch. For example, is large scale prior deployment an 380 acceptable criteria? 382 6.2.3. Name evaluation 384 With regard to the actual choice of name, [RFC6761] is silent. The 385 answers to the seven questions are expected to tell how a name, 386 presumably already chosen outside of the process, might be handled if 387 it's determined to be a "special use" name but is silent on how to 388 choose a name or how to evaluate a specific proposed name. 390 Going back to the previous point of prior usage of the protocol, in 391 the case of LOCALHOST, LOCAL and ONION, those particular domain names 392 were already in use by a substantial population of end-users at the 393 time they were requested to be added to the Registry. Rightly or 394 not, the practical cost of a transition was argued as a justification 395 for their inclusion in the registry. However, when formulating a 396 general process for future such reservations, such prior use of 397 particular names may or may not be the approach the IETF wants to 398 choose. 400 The following questions should be discussed by the IETF: 402 Is there a need to reserve any name, as long as it is unique, or 403 is there any technical reason to reserve a particular name? 405 Are non-technical reasons to reserve a "specific" name acceptable? 407 Is demonstrated prior-usage of a specific name a valid rationale? 409 When processing gTLD applications, ICANN has a process to review 410 those to check if the proposed names are potentially offensive to 411 certain communities, have political ramifications, etc.. It is worth 412 asking if the IETF should have a similar process in place to evaluate 413 specific proposed reserved names, and, if so, how such process would 414 be implemented, and how appeals should be handled? 416 7. Security Considerations 418 This document aims to provide a problem statement that will inform 419 future work. Whilst security and privacy are fundamental 420 considerations, this document expects that that future work will 421 include such analysis, and hence no attempt is made to do so here. 423 8. IANA Considerations 425 This document has no IANA actions. 427 9. Acknowledgements 429 Your name here, etc. 431 10. References 433 10.1. Normative References 435 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 436 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 437 . 439 [RFC1035] Mockapetris, P., "Domain names - implementation and 440 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 441 November 1987, . 443 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 444 Understanding Concerning the Technical Work of the 445 Internet Assigned Numbers Authority", RFC 2860, DOI 446 10.17487/RFC2860, June 2000, 447 . 449 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 450 RFC 6761, DOI 10.17487/RFC6761, February 2013, 451 . 453 10.2. Informative References 455 [I-D.ietf-dnsop-dns-terminology] 456 Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 457 Terminology", draft-ietf-dnsop-dns-terminology-05 (work in 458 progress), September 2015. 460 [I-D.ietf-dnsop-onion-tld] 461 Appelbaum, J. and A. Muffett, "The .onion Special-Use 462 Domain Name", draft-ietf-dnsop-onion-tld-01 (work in 463 progress), September 2015. 465 [I-D.lewis-domain-names] 466 Lewis, E., "Domain Names", draft-lewis-domain-names-01 467 (work in progress), September 2015. 469 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 470 and E. Lear, "Address Allocation for Private Internets", 471 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 472 . 474 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 475 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 476 2000, . 478 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 479 DOI 10.17487/RFC6762, February 2013, 480 . 482 Appendix A. Editorial Notes 484 This section (and sub-sections) to be removed prior to publication. 486 A.1. Venue 488 An appropriate forum for discussion of this draft is for now the 489 dnsop working group. 491 A.2. Pithy Quotes from History 493 The question has arisen as to how the toplevel naming authority 494 decides who gets a toplevel name and who must get by with a non- 495 toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF 496 that perhaps the existing toplevel nameholders might vote on 497 whether the applicant for a new toplevel name should be granted, 498 with a majority needed for approval. It seems to me this might 499 produce a clique whereby whoever initially gains power will hold 500 it and prevent its "enemies" from getting in too. This will make 501 the toplevel rather less than universal. 503 (E-mail from Robert Elton Maas to the namedroppers mailing list on 9 504 November 1983) 506 My basic point is that as a world-wide network evolves it is 507 ridiculous to force people to name resources in terms of one 508 static hierarchy which very closely resembles the current 509 internetwork topology (as the current scheme does). What we are 510 eventually going to require is a distributed expert for making 511 sense out of a name someone hands it. There will be no simple 512 algorithm to be written on one page of an RFC that will suffice to 513 resolve a name. Rather, a number of heuristics will let a 514 resolver make sense out of a given name by querying other experts 515 which it suspects may be more knowledgeable about the name than it 516 is, or by forwarding a piece of mail to an expert which is at 517 least one level closer to the destination in some hierarchy. 519 (E-mail from Peter Karp to the namedroppers mailing list on 8 520 February 1984) 522 A.3. Change History 524 A.3.1. draft-adpkja-special-names-problem-00 526 Initial draft circulated for comment. 528 Authors' Addresses 530 Joe Abley 531 Dyn, Inc. 532 103-186 Albert Street 533 London, ON N6A 1M1 534 Canada 536 Phone: +1 519 670 9327 537 Email: jabley@dyn.com 539 Peter Koch 540 DENIC 542 Email: pk@denic.de 544 Alain Durand 545 ICANN 547 Email: alain.durand@icann.org