idnits 2.17.00 (12 Aug 2021) /tmp/idnits39124/draft-adpkja-dnsop-special-names-problem-02.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 669: '...f an application MUST NOT rely on name...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 20, 2016) is 2253 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1034' is defined on line 689, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 693, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 733, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-lewis-domain-names-02 -- Obsolete informational reference (is this intentional?): RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). 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: September 21, 2016 DENIC eG 6 A. Durand 7 ICANN 8 W. Kumari 9 Google 10 March 20, 2016 12 Problem Statement for the Reservation of Top-Level Domains in the 13 Special-Use Domain Names Registry 14 draft-adpkja-dnsop-special-names-problem-02 16 Abstract 18 The dominant protocol for name resolution on the Internet is the 19 Domain Name System (DNS). However, other protocols exist that are 20 fundamentally different from the DNS, and may or may not share the 21 same namespace. 23 When an end-user triggers resolution of a name on a system which 24 supports multiple, different protocols (or resolution mechanisms) for 25 name resolution, it is desirable that the protocol used is 26 unambiguous, and that requests intended for one protocol are not 27 inadvertently answered using another. 29 RFC 6761 introduced a framework by which, under certain 30 circumstances, a particular domain name could be acknowledged as 31 being special. This framework has been used twice to reserve top- 32 level domains (.local and .onion) that should not be used within the 33 DNS, to avoid the possibility of namespace collisions in parallel use 34 of non-DNS name resolution protocols. 36 Various challenges have become apparent with this application of the 37 guidance provided in RFC 6761. This document aims to document those 38 challenges in the form of a problem statement, to facilitate further 39 discussion of potential solutions. 41 Status of This Memo 43 This Internet-Draft is submitted in full conformance with the 44 provisions of BCP 78 and BCP 79. 46 Internet-Drafts are working documents of the Internet Engineering 47 Task Force (IETF). Note that other groups may also distribute 48 working documents as Internet-Drafts. The list of current Internet- 49 Drafts is at http://datatracker.ietf.org/drafts/current/. 51 Internet-Drafts are draft documents valid for a maximum of six months 52 and may be updated, replaced, or obsoleted by other documents at any 53 time. It is inappropriate to use Internet-Drafts as reference 54 material or to cite them other than as "work in progress." 56 This Internet-Draft will expire on September 21, 2016. 58 Copyright Notice 60 Copyright (c) 2016 IETF Trust and the persons identified as the 61 document authors. All rights reserved. 63 This document is subject to BCP 78 and the IETF Trust's Legal 64 Provisions Relating to IETF Documents 65 (http://trustee.ietf.org/license-info) in effect on the date of 66 publication of this document. Please review these documents 67 carefully, as they describe your rights and restrictions with respect 68 to this document. Code Components extracted from this document must 69 include Simplified BSD License text as described in Section 4.e of 70 the Trust Legal Provisions and are provided without warranty as 71 described in the Simplified BSD License. 73 Table of Contents 75 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 3. RFC 6761 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 4. Architectural Considerations . . . . . . . . . . . . . . . . 6 79 5. Technical Considerations . . . . . . . . . . . . . . . . . . 8 80 6. Organizational Considerations . . . . . . . . . . . . . . . . 9 81 6.1. External Organizational Considerations . . . . . . . . . 9 82 6.2. IETF Internal Considerations . . . . . . . . . . . . . . 10 83 6.2.1. Process . . . . . . . . . . . . . . . . . . . . . . . 10 84 6.2.2. Technical Criteria . . . . . . . . . . . . . . . . . 11 85 6.2.3. Name evaluation . . . . . . . . . . . . . . . . . . . 12 86 6.3. The ICANN process to evaluate names . . . . . . . . . . . 13 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 90 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 10.1. Normative References . . . . . . . . . . . . . . . . . . 15 92 10.2. Informative References . . . . . . . . . . . . . . . . . 15 93 Appendix A. Editorial Notes . . . . . . . . . . . . . . . . . . 16 94 A.1. Venue . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 A.2. Pithy Quotes from History . . . . . . . . . . . . . . . . 17 96 A.3. Change History . . . . . . . . . . . . . . . . . . . . . 17 97 A.3.1. draft-adpkja-special-names-problem-00 . . . . . . . . 17 98 Appendix B. Change history . . . . . . . . . . . . . . . . . . . 17 99 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 101 1. Terminology 103 Clear and unambiguous use of terminology is important for the clear 104 formulation of any problem statement. The DNS protocol suffers from 105 imprecise and overloaded terminology (for example, see [RFC7719]). 106 The use of terms and concepts from other naming systems that are 107 similar (but different) simply confuses matters further. 109 In the interests of clarity, the following terms used in this 110 document are to be interpreted as follows: 112 Registry (n): the Special-Use Domain Names Registry created by 113 [RFC6761] and published at [IANA-SPECIAL-USE]. 115 [This section to be completed following review and refinement of the 116 rest of the text.] 118 2. Introduction 120 Some systems use the last label in a name to act as a switch to a 121 different, non-DNS resolution process - examples of such switches 122 include: .local (to use mDNS) and .onion (to use Tor). This switch 123 practice is not explicitly documented anywhere, and the method for 124 accomplishing this varies by implementation. As an interesting 125 aside, the full semantics of domain names isn't really documented 126 anywhere either, although [I-D.lewis-domain-names] is a current 127 attempt to rectify this. 129 This technique of using the last label as a switch has a number of 130 properties which make it attractive to people implementing alternate 131 name resolution systems, including: 133 o The names can follow the common DNS syntax of LDH labels, 134 separated by dots. This means that these names can be entered in 135 any application which takes existing DNS names. 137 o The switch to the new resolution process can be implemented in a 138 number of ways, such as custom application code, a shim in the 139 normal DNS resolution process, or on the system's configured DNS 140 servers. 142 o The names "look" like names to users. 144 Note that [RFC6303] defines "locally served zones". The important 145 difference is that in [RFC6303], the names get registered for special 146 treatment if they are already special: they are not declared special 147 by the registration. 149 [RFC6761] defines ways to reserve domain names. This could be read 150 to augment the technical uses exemption made in [RFC2860] (also 151 called "the IETF-ICANN MoU"). [RFC2860] says: 153 "Note that (a) assignments of domain names for technical uses 154 (such as domain names for inverse DNS lookup), (b) assignments of 155 specialized address blocks (such as multicast or anycast blocks), 156 and (c) experimental assignments are not considered to be policy 157 issues, and shall remain subject to the provisions of this 158 Section 4." 160 The framework in [RFC6761] has recently been used to reserve the 161 .onion label, allowing it to be used as a switch to the Tor 162 resolution process, as described in [RFC7686]. Because the .onion 163 label in the IANA "Special-Use Domain Names" registry 164 [IANA-SPECIAL-USE], the Tor Project can be assured that there will 165 not be a .onion TLD created in the IANA rooted DNS, and thus the 166 possibility of collisions in the namespace will be avoided. 168 The discussions in the DNSOP Working Group (WG) and the IETF Last 169 Call processes for the .onion registration in the Special Use Domain 170 Names registry (1,200 messages) have made it apparent that clarity 171 about if and how to treat this "protocol switching" practice would 172 help a lot in deciding the merit of future similar applications. 174 One possible outcome of the discussion would be to decline to 175 recognize such usage of domain names in the architecture; another 176 possible outcome is to formalize it and better understand the issues 177 that come with it. 179 An additional consideration is that names which follow the DNS syntax 180 (including those which use alternate name resolutions processes to 181 the DNS) are in the same namespace as names in the DNS. This means 182 that currently both the IETF (through [RFC6761]) and ICANN are making 183 allocations or reservations from a shared namespace. If this 184 continues to be the case, in order to avoid conflict, close 185 coordination between the two organizations is necessary. 187 3. RFC 6761 189 Section 5 of [RFC6761] describes seven questions to be answered to 190 justify how and why a particular domain name is special. These seven 191 questions can be broadly categorized as follows: 193 1. impact on end-users; 195 2. impact on applications; 197 3. impact on name resolution APIs and libraries; 199 4. impact on recursive resolvers; 201 5. impact on authoritative DNS servers; 203 6. impact on DNS server operators; 205 7. impact on DNS registries and registrars. 207 The intent of those seven questions was originally to serve as the 208 justifications for why a proposed special-use registration should be 209 granted, demonstrating that it (a) provides a result that the 210 community judges to be good, and (b) the aforementioned good result 211 cannot reasonably be achieved in another way. The rough consensus 212 from significant discussion was that .onion did satisfy both (a) and 213 (b), but this was not clearly demonstrated by the answers to the 214 "seven questions". Furthermore, it is unclear if and how these 215 questions could reliably and unambiguously be used to make the 216 determination, leading to the conclusion that they are generally 217 inadequate for making the determination whether a particular domain 218 name qualifies as requiring special/different treatment. 219 Applications which follow the [RFC6761] process are likely to devolve 220 into a "beauty contest". Moreover, the answers to the seven 221 questions are not available in a machine readable form to 222 applications that want to follow [RFC6761]. 224 So the answers to these seven questions can better be seen as 225 providing guidance to the corresponding seven audiences on how to 226 handle a special-use domain name once it has been reserved by 227 inclusion in the Registry, and not as entrance filters for inclusion 228 in the registry. 230 The answers to the seven questions specify desired behavior in the 231 internet for handling a particular domain name, not the basis for 232 deciding whether the effort to implement special behavior across all 233 of those audiences is worth the cost. This indifference to costs is 234 not necessarily scalable for making future decisions about potential 235 inclusion in the registry. 237 The justification in [RFC6761] is concerned with the rationale of 238 reserving a domain name that precludes its subsequent use as a top 239 level domain name. However, the document fails to offer such a 240 rationale, and instead requires the justification of the reserved 241 name to include the provision of guidance to a number of audiences 242 (users, application developers, DNS resolver applications, DNS 243 resolution service operators, and name registries and registrars) as 244 to how to handle names that are listed in this registry. But this 245 guidance is not, in and of itself, an adequate rationale for the 246 selection of a particular name value to be reserved in this registry. 248 What is missing in [RFC6761] is the consideration of the name itself. 249 If one were to contrast the procedures relating to the admission of a 250 name to the IETF Special Use Name registry to the processes 251 associated with the New gTLD Program operated by ICANN [NEW-GTLD], 252 then it is evident that the IETF process does not admit many 253 considerations which appear to be areas of evaluation in the New gTLD 254 program. More on this in section Section 6.3. 256 This document proposes to categorize considerations related to the 257 usage of the [RFC6761] registry for protocol switches in 3 258 categories: Architectural, Technical and Organizational. This 259 document then lists a number of questions to drive the discussion. 260 The list of issues discussed here is non-exhaustive. 262 However, some people have noted that [RFC6761] describes other 263 alternative special handling aside from protocol switches. That 264 alternative special handling must be considered carefully at the time 265 of publication of the defining RFC, regardless of the nature of the 266 special use. 268 4. Architectural Considerations 270 The first thing to consider in this discussion is that not all names 271 (or domain names) are part of the Domain Name System. See 272 [I-D.lewis-domain-names] for an in-depth discussion on this topic. 274 At the time of writing, two top-level domain names reserved by 275 inclusion in the Registry went through the [RFC6761] process and are 276 used by name resolution protocols other than the DNS: 278 .local is used by the Multicast DNS protocol specified in 279 [RFC6762] which is similar in some respects to the DNS, but which 280 uses a different well-known port number and is limited to a 281 particular multicast scope; 283 .onion is used to construct names that designate services 284 reachable via the Tor network using onion routing. 286 These two name resolution protocols are, to varying degrees, 287 different from the DNS, and the namespaces used in each naming scheme 288 are also different. The top-level label is effectively being used as 289 a name resolution protocol identifier. At the core of the issue is 290 that different "strings" that look like "domain names" (i.e. are 291 within the same name space) but are not DNS names are used 292 interchangeably in the URI (or URN). 294 In particular, DNS imposes constraints on name syntax. An example of 295 such constraints is the 63 octet limit per label. Strings used in 296 the .onion domain do not have that constraint. 298 It could be argued that in the absence of a more elegant alternative, 299 a pragmatic choice to embed protocol selectors as namespace tokens 300 has effectively already been made. The running code and effective 301 consensus in how it should be used by significant user bases should 302 not be discounted. Although the reservation of names in the DNS 303 namespace can be made at any level, the two examples above 304 demonstrate use-cases for reservation at the top-level, and hence 305 that case must be considered. 307 The underlying discussion here is the tussle between the applications 308 and the network. Application architects see using special name tags 309 (such as .onion) as an easy way to get new features deployed. They 310 consider the hurdles of deploying new URI schemes such as 311 http:/onion/onion-name as too onerous and too slow to deploy for 312 their needs. Network architects worry of overloading the semantics 313 of DNS names and/or creating a name space that is larger than the DNS 314 namespace. They refer to bad precedents such as .uucp and .bitnet. 316 The fundamental point to consider here is the unicity (or 317 multiplicity) of the name space. Are we talking about one namespace 318 with different resolution protocols or independent name spaces? 320 It might it be helpful to point out that the property of interest 321 here is the assurance of uniqueness of a name, and another way of 322 thinking about the question is whether it applies across domain names 323 as people expect or need it to? None of this would matter if people 324 didn't expect names constructed according to whatever rules they're 325 following to be unique across a set of names that spans multiple 326 operating environments and resolution protocols. 328 In [RFC2826] the IAB noted that 330 "To remain a global network, the Internet requires the existence 331 of a globally unique public name space. The DNS name space is a 332 hierarchical name space derived from a single, globally unique 333 root." 335 "Maintaining a globally-unique public namespace that supports 336 different name resolution protocols is hence an architectural 337 requirement, and some facility for reservation of top-level 338 domains in the DNS is necessary." 340 If we were to accept the notion that the last label of a domain name 341 is actually a protocol switch, we are actually building a catalog of 342 all top level domains and what resolution protocol each one invokes. 343 Note that such a catalog does not formally exist today, because 344 [RFC6761] is an exception list to the general case which is supposed 345 to use regular DNS as resolution protocol. Such a catalog may remain 346 a concept to guide this discussion or be implemented as an actual 347 IANA registry [IANA-SPECIAL-USE]. In effect, it would associate TLDs 348 with indications on how applications and resolvers should treat them. 349 However, such an approach would leave open the question of not-yet- 350 defined TLDs. No resolution mechanism could be associated with those 351 in advance so that systems would have to continue to assume that such 352 names are part of the DNS. For reasons of completeness it is noted 353 that suggestions have been made to help the distinction by using 354 special labels (as in IDNs). 356 It should also be noted that there are choices for a protocol switch 357 other than reserving labels. In particular, a proposal to move those 358 protocol switches under a specific top level domain has been 359 discussed (.ALT). If that architecture choice is made, some of the 360 questions listed in the sections below would become moot. 362 Note: [RFC6761] mentions the reserved names could be any label in a 363 domain name, not just the rightmost one (or ones). However, this 364 creates a number of complications and has not seen much support in 365 the community as of now. 367 5. Technical Considerations 369 Each of the seven questions posed by [RFC6761] has the potential to 370 describe why it may be necessary for special handling of the 371 requested name(s) in applications by a particular audience. However, 372 aside from reserving the name, it is not entirely clear what any of 373 those audiences might further expect as a result of a successful 374 request to add a top-level domain to the Registry. 376 For example, reservation of a top-level domain by the IETF does not 377 guarantee that DNS queries for names within a reserved domain will 378 not be sent over the Internet. The requirements of the operators of 379 recursive resolvers in the DNS cannot be relied upon to be 380 implemented; the impact on the operators of DNS authoritative servers 381 hence cannot be reliably assumed to be zero. In the case of 382 [RFC7686], leakage of .onion queries on the Internet might lead to 383 disclosure of private information that, in some cases, might pose a 384 risk to the personal safety of end-users. 386 At the time of writing, the [RFC6761] registry does not include 387 direct guidance for any of the seven audiences, relying instead upon 388 a reference for each entry in the Registry to the document that 389 requested its insertion. Such documents might well be opaque to many 390 readers; [RFC6762] is a seventy-page protocol specification, for 391 example, which is arguably not the most effective way to set 392 expectations of non-technical end-users). 394 Useful reservations of top-level domains should be accompanied by 395 documentation of realistic expectations of each of the seven 396 audiences, and the evaluation of particular requests should consider 397 the practical likelihood of those expectations being met and the 398 implications if they are not. 400 Here is a non-exhaustive list of additional questions that have 401 surfaced in discussion of requests for names to be added to the 402 Special Use Names registry: 404 What does it mean to have a "non-DNS" entry in the registry 405 described above? 407 Are applications supposed to check that registry to know what to 408 do? 410 Can, or should, applications do this check dynamically? 412 What if an application makes this dynamic check and discovers the 413 name contains a switch it does not know how to handle? 415 Similar questions applies to resolvers (DNS and non-DNS); what is the 416 expected behavior? 418 One particular avenue of investigation would be to see if such 419 considerations could be encoded in machine understandable code in an 420 extension of the current [RFC6761] registry. 422 6. Organizational Considerations 424 This section gives two categories of organizational considerations: 425 external and internal. 427 6.1. External Organizational Considerations 429 The policy surrounding the implementation and management of top-level 430 domains in the DNS has been developed using a multi-stakeholder 431 process convened by ICANN according to the MoU between ICANN and IETF 432 [RFC2860]. It is out of scope for this document to revisit that MoU. 434 While discussing the particular attributes that make a domain name 435 special, [RFC6761] notes that "the act of defining such a special 436 name creates a higher-level protocol rule, above ICANN's management 437 of allocatable names on the public Internet." 439 [RFC2860] draws a line between what is policy and what is technical. 440 A variety of opinions have been expressed regarding whether [RFC6761] 441 blurs this line. In particular, [HUSTON] has one viewpoint on the 442 topic. As noted earlier, it is out of scope for this document to 443 analyse this issue beyond noting that such a variety of views exist. 445 Taking a different perspective, it has been argued that [RFC6761] 446 specifically extends the DNS protocol to include special treatment 447 for names in the registry, and that there's nothing in [RFC2860] at 448 all that limits the IETF's authority to change the protocol. 450 However, it should be noted that, if the IETF were to formalize the 451 concept of protocol/name switch in the Internet architecture, 452 coordination would be require between ICANN and IETF on such names. 453 Using the analogy described above of a catalog/registry of such 454 switches, care must be taken to make sure we do not end up with two 455 process streams allowed to create entries without complete 456 synchronization. 458 6.2. IETF Internal Considerations 460 6.2.1. Process 462 [RFC6761] specifies the way in which "an IETF 'Standards Action' or 463 'IESG Approval' document" should present answers to the questions 464 described above (see Section 2), but does not describe the process by 465 which the answers to those questions should be evaluated. 467 For example, it is not clear who is responsible for carrying out an 468 evaluation. A document which requests additions to the Registry 469 might be performed by the IESG, by the IAB, by the DNSOP WG, by an 470 ad-hoc working group, by expert review or any combination of those 471 approaches. [RFC6761] provides no direction. 473 As an illustration of the inconsistency that has been observed 474 already, [RFC6762] was published as an AD-sponsored individual 475 submission in the INT area, and the IESG evaluation record does not 476 reveal any discussion of the reservation of the .local top-level 477 domain in the DNS. [RFC7686], however, was published as a working 478 group document through the DNSOP WG, and an extensive discussion by 479 both the participants of the DNSOP WG and the IESG on the merits of 480 the request took place. The evaluation process, in the absence of 481 clear direction, is demonstrably inconsistent. 483 We should point to [RFC5226] and explicitly quote the definition of 484 "Standards Action" or "IESG Approval": 486 IESG Approval is not intended to be used often or as a "common 487 case"; indeed, it has seldom been used in practice during the 488 period RFC 2434 was in effect. Rather, it is intended to be 489 available in conjunction with other policies as a fall-back 490 mechanism in the case where one of the other allowable approval 491 mechanisms cannot be employed in a timely fashion or for some 492 other compelling reason. IESG Approval is not intended to 493 circumvent the public review processes implied by other policies 494 that could have been employed for a particular assignment. IESG 495 Approval would be appropriate, however, in cases where expediency 496 is desired and there is strong consensus for making the assignment 497 (e.g., WG consensus). 499 So, while it is very interesting to note that [RFC6761] was an AD 500 sponsored individual submission in spite of two active DNS related 501 WGs, [RFC6762] is probably clean: it defines the protocol and is 502 itself on standards track. 504 [RFC7686] however, while on standards track, does not define the TOR 505 protocol, so it was used to fulfill the 'standards action' 506 requirement by the letter. It contains normative references to non- 507 IETF protocols, which is noteworthy. 509 A comparison of the two "seven question forms" from [RFC6761] reveals 510 that at least the responses to questions 2, 3, and 4, differ 511 significantly while there is no defined way to communicate the 512 difference to the affected software entities. 514 An alternate view has been expressed with regard to the protocol 515 evaluation. It states that the authority belongs to the IESG to seek 516 whatever support it likes, within the established process, in making 517 standards decisions, including delegating evaluation of a specific 518 registry change proposal to a WG or a directorate. The IESG might 519 have varied what guidance it sought, but that does not constitute 520 "inconsistency" under the process. That being said, more complete 521 evaluation guidance would be helpful to the IESG and the community. 523 6.2.2. Technical Criteria 525 Regardless of the actual name being proposed as protocol and/or 526 namespace switch, it is also not clear what technical criteria the 527 evaluation body should use to examine the merit of an application for 528 such a reserved name/protocol switch. For example, is large scale 529 prior deployment an acceptable criteria? A number of people have 530 clearly answered "no" to that question as it would only encourage 531 "squatting" on names. 533 However, in the case of .local and .onion, those particular domain 534 names were already in use by a substantial population of end-users at 535 the time they were requested to be added to the Registry. Rightly or 536 not, the practical cost of a transition away from the requested 537 strings was argued as a justification for their inclusion in the 538 registry. 540 6.2.3. Name evaluation 542 With regard to the actual choice of name, [RFC6761] is silent. The 543 answers to the seven questions are expected to tell how a name, 544 presumably already chosen outside of the process, might be handled if 545 it is determined to be a "special use" name. However, it is silent 546 on how to choose a name or how to evaluate a specific proposed name. 548 Going back to the IETF process used for the evaluation of .local and 549 .onion, one might ask the following questions: 551 For example, what consideration have there been in the 552 intellectual property rights in the reservation of a name in this 553 Special Use Name registry, and what procedures should be followed 554 in the case of a dispute over the rights to use a name in this 555 manner? Also, to what extent could such a reservation of a name 556 in this Special Use Names registry be used to block competing 557 interests and/or competing technologies? What are the competition 558 and consumer issues that need to be considered if the reservation 559 of a name in this registry causes some form of exclusive access 560 and reduced competitive access, or where there is no ability for 561 consumers to exercise choice in a situation where providers 562 compete in the offering of services? 564 A related consideration is that the current process of admission 565 to the Special Use Name registry appears to admit no formal 566 assessment of environmental impact. Is the name that is proposed 567 to be entered into this registry already being used in local 568 contexts, with or without an association with DNS name resolution, 569 such that its use as a reserved name through an entry in this 570 registry, and its continued use in local contexts could cause harm 571 to users? To what extent can this impact be assessed, and what 572 level of impact is considered acceptable? 574 While the "seven questions" relate to altered behaviors by 575 specific audiences and users of names there is no explicit 576 consideration of the security in this process. Is the 577 registration of such a name a "safe" action for the IETF to take? 578 To what extent could the use of this reserved name be used in a 579 hostile or malicious manner? What measures have been taken to 580 mitigate or otherwise address such potential vulnerabilities? 582 ICANN has created an entire set of groups, organizations, committees, 583 processes and procedures to deal with the evaluation of applied for 584 new TLDs, complete with a cadre of lawyers and policy people. Unless 585 the IETF were willing to do the same, it would have a hard time 586 performing evaluation of the strings themselves, distinct from the 587 evaluation of the technology behind the name resolution system. 589 An alternate view has been expressed that such a process is not 590 necessary because the IESG is the body that makes the decision on a 591 specific name reserved by [RFC6761], and the IETF has a workable 592 appeal process to deal with any potential issues. However, looking 593 at the level of contention created in the ICANN process around the 594 choice of certain names, serious doubts have been expressed to the 595 scalability and ultimate viability of such an appeal process. 597 6.3. The ICANN process to evaluate names 599 Section 4.3 of [RFC2860] says: 601 Two particular assigned spaces present policy issues in addition 602 to the technical considerations specified by the IETF: the 603 assignment of domain names, and the assignment of IP address 604 blocks. 606 This remains as true today as when it was written (2000). Domain 607 names have a number of considerations that have complex policy issues 608 that ICANN deals with and which the IETF may not be well equipped to 609 handle. 611 The ICANN process applicant have to go through to get a name is 612 described in the applicant guide book [GUIDEBOOK], which is a 338 613 page document. It should however be noted that the current round of 614 gTLD application is closed and rules may differ in the next round if 615 and when it happens. 617 Considerations include, but are not limited to: 619 Geographical During the most recent round of new gTLD applications, 620 there were a number of applications for so call "geographic" 621 terms. These included applications for .amazon and .patagonia. 622 The .amazon application in particular was controversial - the 623 governments of Brazil and Peru requested that ICANN's Governmental 624 Advisory Committee (GAC) to issue a warning that granting .amazon 625 to Amazon would "prevent the use of this domain for purposes of 626 public interest related to the protection, promotion, and 627 awareness raising on issues related to the Amazon biome." The 628 IETF is not well suited to evaluating this sort of issue. 630 Brands / Trademark law If Wile E. Coyote approached the IETF 631 requesting that the IETF reserve .acme, a trademark held by a 632 large corporation making anvils and giant slingshots, the IETF 633 could become embroiled in trademark lawsuit - and even if the IETF 634 were not, we have enough armchair lawyers that the discussions 635 would be extremely annoying :-). Closely related to this issue is 636 "protected designation of origin (PDO)" - for example, Champagne. 638 String similarity ICANN has an entire process for evaluating the 639 string similarity / confusability between applied for (and 640 current) strings - for example, under what conditions would the 641 IETF be able to make a determination if someone attempted to use 642 [RFC6761] to reserve .c0m? 644 International Organization Names Certain names and organizations get 645 additional protection under trademark law - well known examples of 646 this are the RedCross/RedCrescent and the International Olympic 647 Committee (IOC). Whether or not this should be the case is well 648 outside anything that the IETF should have an opinion on but, 649 undoubtedly, there are many within the community who will have an 650 opinion (and will want to argue it at length). 652 Offensive Terms There are a huge range of these, from the obscure / 653 archaic (waesucks, gadsbudlikins) to the more obvious and current. 654 Certain terms are sufficiently offensive that the IETF would have 655 a hard time coming to any useful consensus (other then "Eeeew!") 657 7. Security Considerations 659 This document aims to provide a problem statement that will inform 660 future work. While security and privacy are fundamental 661 considerations, this document expects that future work will include 662 such analysis, and hence no attempt is made to do so here. See among 663 other places [SAC-057] 665 Reserving names has been presented as a way to prevent leakage into 666 the DNS. However, instructing resolvers to not forward the queries 667 (and/or by instructing authoritative servers not to respond) is not a 668 guarantee that such leakage will be prevented. The security (or 669 privacy) of an application MUST NOT rely on names not being exposed 670 to the Internet DNS resolution system. 672 8. IANA Considerations 674 This document has no IANA actions. 676 9. Acknowledgements 678 Thanks to Paul Hoffman for a large amount of editing. 680 10. References 682 10.1. Normative References 684 [IANA-SPECIAL-USE] 685 IANA, "Special-Use Domain Names", 2016, 686 . 689 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 690 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 691 . 693 [RFC1035] Mockapetris, P., "Domain names - implementation and 694 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 695 November 1987, . 697 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 698 Understanding Concerning the Technical Work of the 699 Internet Assigned Numbers Authority", RFC 2860, 700 DOI 10.17487/RFC2860, June 2000, 701 . 703 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 704 RFC 6761, DOI 10.17487/RFC6761, February 2013, 705 . 707 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 708 DOI 10.17487/RFC6762, February 2013, 709 . 711 [RFC7686] Appelbaum, J. and A. Muffett, "The ".onion" Special-Use 712 Domain Name", RFC 7686, DOI 10.17487/RFC7686, October 713 2015, . 715 10.2. Informative References 717 [GUIDEBOOK] 718 ICANN, "gTLD Application Guidebook", June 2012, 719 . 722 [HUSTON] Huston, G., "What's in a Name?", December 2015, 723 . 725 [I-D.lewis-domain-names] 726 Lewis, E., "Domain Names", draft-lewis-domain-names-02 727 (work in progress), January 2016. 729 [NEW-GTLD] 730 ICANN, "New Generic Top-Level Domains", 2016, 731 . 733 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 734 and E. Lear, "Address Allocation for Private Internets", 735 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 736 . 738 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 739 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 740 2000, . 742 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 743 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 744 DOI 10.17487/RFC5226, May 2008, 745 . 747 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, 748 RFC 6303, DOI 10.17487/RFC6303, July 2011, 749 . 751 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 752 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 753 2015, . 755 [SAC-057] ICANN Security and Stability Advisory Committee, "SSAC 756 Advisory on Internal Name Certificates", March 2013, 757 . 760 Appendix A. Editorial Notes 762 This section (and sub-sections) to be removed prior to publication. 764 A.1. Venue 766 An appropriate forum for discussion of this draft is for now the 767 DNSOP WG. 769 A.2. Pithy Quotes from History 771 The question has arisen as to how the toplevel naming authority 772 decides who gets a toplevel name and who must get by with a non- 773 toplevel name. The suggestion was made by MOCKAPETRIS@USC-ISIF 774 that perhaps the existing toplevel nameholders might vote on 775 whether the applicant for a new toplevel name should be granted, 776 with a majority needed for approval. It seems to me this might 777 produce a clique whereby whoever initially gains power will hold 778 it and prevent its "enemies" from getting in too. This will make 779 the toplevel rather less than universal. 781 (E-mail from Robert Elton Maas to the namedroppers mailing list on 9 782 November 1983) 784 My basic point is that as a world-wide network evolves it is 785 ridiculous to force people to name resources in terms of one 786 static hierarchy which very closely resembles the current 787 internetwork topology (as the current scheme does). What we are 788 eventually going to require is a distributed expert for making 789 sense out of a name someone hands it. There will be no simple 790 algorithm to be written on one page of an RFC that will suffice to 791 resolve a name. Rather, a number of heuristics will let a 792 resolver make sense out of a given name by querying other experts 793 which it suspects may be more knowledgeable about the name than it 794 is, or by forwarding a piece of mail to an expert which is at 795 least one level closer to the destination in some hierarchy. 797 (E-mail from Peter Karp to the namedroppers mailing list on 8 798 February 1984) 800 A.3. Change History 802 A.3.1. draft-adpkja-special-names-problem-00 804 Initial draft circulated for comment. 806 Appendix B. Change history 808 [ RFC Editor: Please remove this section before publication] 810 -01 to -02: 812 o A very large number of readability / grammar / reference fixes 813 from Paul Hoffman. 815 -00 to -01: 817 o Significant readability changes. 819 -00: 821 o Initial draft circulated for comment. 823 Authors' Addresses 825 Joe Abley 826 Dyn, Inc. 827 103-186 Albert Street 828 London, ON N6A 1M1 829 Canada 831 Phone: +1 519 670 9327 832 Email: jabley@dyn.com 834 Peter Koch 835 DENIC eG 836 Kaiserstrasse 75-77 837 Frankfurt 60329 838 Germany 840 Email: pk@denic.de 842 Alain Durand 843 ICANN 845 Email: alain.durand@icann.org 847 Warren Kumari 848 Google 850 Email: warren@kumari.net