idnits 2.17.1 draft-stw-6761ext-01.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 Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 11, 2019) is 1870 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 353, but no explicit reference was found in the text == Unused Reference: 'RFC2119' is defined on line 357, but no explicit reference was found in the text == Unused Reference: 'RFC2870' is defined on line 372, but no explicit reference was found in the text == Unused Reference: 'RFC6762' is defined on line 386, but no explicit reference was found in the text == Unused Reference: 'RFC7719' is defined on line 399, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 2870 (Obsoleted by RFC 7720) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Woolf 3 Internet-Draft March 11, 2019 4 Intended status: Informational 5 Expires: September 12, 2019 7 Guidelines for Use of the Special Use Names Registry 8 draft-stw-6761ext-01 10 Abstract 12 RFC 6761 requires that proponents document how a specific name is to 13 be treated within the DNS protocol, public database, and 14 administrative infrastructure, but doesn't provide any guidance to 15 help the community figure out whether a particular registration is 16 otherwise beneficial. This limited guidance in RFC 6761 provides 17 flexibility in standardizing the use of domain names in the modern 18 Internet outside of conventional DNS protocol or the public DNS 19 database. This flexibility has been useful from time to time but has 20 also caused significant confusion (see RFC 8244). 22 This document attempts to define guidelines for the IESG and the IETF 23 community on the interpretation of RFC 6761 and the use of the 24 special use names registry. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 12, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 2. Current SUNR Use Cases . . . . . . . . . . . . . . . . . . . 4 62 3. Guidelines for Special Use Name registration . . . . . . . . 5 63 4. The Special Case of Top-Level Domains . . . . . . . . . . . . 6 64 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 65 6. Informative References . . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 9 68 1. Introduction 70 From time to time, networking protocols need to be able to name 71 things used within the protocol, and resolve the names created or 72 referenced. Such identifiers may also need to be persistent in time, 73 across administrative and operational realms, or through other 74 transformations. Necessary operations tend to include creating, 75 modifying, and deleting names, and accessing values and relationships 76 that correspond to them. 78 It's common for protocol designers to try to use domain names as the 79 starting point for their systems of names, and the DNS as the 80 starting point for name resolution. This is completely 81 understandable-- domain names, and DNS resolution, are well- 82 established in the expectations of network users and developers, with 83 many advantages in deployment and operation. They're also well- 84 supported by fielded software and a large public database of names 85 and values, with many use cases already represented by example. 87 However, there are some risks when the protocol designer attempts to 88 re-use domain names and DNS, even (or especially) with modifications, 89 to support a specific use case or protocol design or deployment 90 constraint. These have been touched upon in several RFCs, and in the 91 evolution of DNS protocol itself and the use of domain names as new 92 needs and constraints appear. See in particular RFC 6055 ("IAB 93 Thoughts on Encodings for Internationalized Domain Names"), RFC 6950 94 ("Architectural Considerations on Application Features in the DNS"), 95 and RFC 6943 ("Issues in Identifier Comparison for Security 96 Purposes"). 98 Most recently, some of these questions have become prominent in the 99 course of requests for new entries in the special use names registry 100 (or SUNR) as established by RFC 6761 ("Special Use Domain Names"). 101 The topic raises contention in a number of areas, including risks of 102 collision between different authorities and possible confusion among 103 different uses of names within the abstract domain namespace. Issues 104 around the use of the abstract domain namespace have been considered 105 in the DNSOP WG over the last few years and are cataloged in RFC 8244 106 ("Special-Use Domain Names Problem Statement") at greater length than 107 this document will do. 109 There are compelling questions that protocol designers or software 110 developers should ask themselves about what behavior they want from 111 the names they use in the context of a new protocol or scope for 112 names. However, rather than boiling that particular ocean, this 113 document attempts the more practical task of of providing guidance to 114 the IESG and the community to determine, in broad terms, the benefits 115 and risks of a particular registration in the special use names 116 registry. 118 RFC 6761 establishes the use of domain names in ways that may be 119 separate to their use in the DNS, but it's somewhat "DNS-centric," in 120 that it doesn't question the default assumption that domain names and 121 DNS-like semantics are desirable or even necessarily acceptable for 122 new naming needs. It also doesn't discuss how one might decide 123 whether a particular string is appropriate for use as a domain name 124 in a particular protocol. The only thing it really requires is a 125 description of how the proposed reserved string should be treated as 126 "special" by DNS resolvers, domain name registrars, and so on. 128 Primarily RFC 6761 discusses how to make domain names and DNS-like 129 semantics for other networking protocols compatible with the global 130 public DNS. It's left to the protocol designer to decide whether 131 this DNS-centric focus is appropriate for their use case. 133 Trying to specify how special use domain names interact with the DNS 134 is both necessary for interoperability and helpful in thinking 135 through the proposed "special use". So a proponent of a special use 136 name might discover, in the course of specifying the "special use" 137 for the SUNR, that domain names will not meet the constraints at 138 hand. But even if domain names seem like a good fit for the problem, 139 there's also no guidance in RFC 6761 to deciding what names might or 140 might not be appropriate for the particular need. 142 The broader discussion of the general applicability of domain names 143 to new needs is useful to consider, and owes a great deal to the RFCs 144 already mentioned, especially RFC 6950, which "provides guidance to 145 application designers and application protocol designers looking to 146 use the DNS to support features in their applications." The 147 consideration there of how to structure domain names and associated 148 data is invaluable. For a different, and sometimes more 149 comprehensive, view on some of the accumulated stresses on the DNS 150 design, see also RFC 8324 ("DNS Privacy, Authorization, Special Uses, 151 Encoding, Characters, Matching, and Root Structure: Time for Another 152 Look?") 154 This document acknowledges that there may be a need to separate 155 domain names from DNS protocol in the analysis of new protocol needs. 156 For example, RFC 6950 primarily assumes that the namespace, the 157 database of instantiated names, and the protocol for lookup and 158 retrieval are inextricably linked. But more recently, some people 159 are attempting to separate the namespace from specific resolution 160 protocol or even a specific instance of a database of names (namely, 161 the global public Internet DNS). This poses a lot of potential 162 interoperability risk because assumptions about DNS and domain names 163 are so deeply embedded in the internet infrastrcuture, and it's 164 meeting with varying degrees of drama and varying degrees of success. 166 Recommended reading on the larger questions includes draft-lewis- 167 domain-names.txt, [RFC1034], [RFC2826], [RFC2860], [RFC6950], 168 [RFC6055], [RFC6943], [RFC6761], [RFC8244] and [RFC8324]However, this 169 document will consider them out of scope for the immediate problem of 170 providing guidance on the situation we're already in: RFC 6761 is an 171 IETF standards-track document, the special use names registry has 172 been defined, people want to use it, and some uses pose more risk to 173 the interoperability of the Internet than others. 175 This document is attempting to address the case where the protocol 176 designer believes that something like a domain name is suitable for 177 their protocol, but the use case can't be satisfied by "normal" DNS-- 178 the DNS wire protocol and globally-scoped domain names, resolvable in 179 the public DNS database-- so some additional analysis and 180 specification is needed. 182 2. Current SUNR Use Cases 184 Some specific use cases have arisen since the special use names 185 registry was established: 187 1. Proponents wish to reserve a name to serve a specific purpose in 188 an IETF protocol, discussed as part of protocol definition in an 189 IETF working group. Resolution of the name may be intended for a 190 limited scope (homenet) or outside of the DNS altogether (mDNS, 191 DNSSD) 193 2. Proponents wish to reserve a name as used in a protocol developed 194 outside of the IETF, in order to avoid potential collisions with 195 other uses of the namespace. Possible sources of such collisions 196 include future IETF protocols or ICANN's policies for delegation 197 of top-level domains. (.onion, RFC 7686) 199 3. Proponents wish to reserve a name from any use in the public DNS, 200 in order to support interoperability and avoid collision or abuse 201 ("localhost," or draft-chapin-additional-reserved-tlds) 203 3. Guidelines for Special Use Name registration 205 The use cases and constraints described suggest some specific 206 guidelines for the IESG and the IETF community regarding the use of 207 the special use names registry: 209 1. Location of a name in the namespace is a consideration. A 210 single-label name or "top level domain" can be attractive at 211 first glance: they can be short and human-friendly, and there's 212 no obvious need to coordinate the use of a top-level label with a 213 TLD operator by, for example, purchasing the use of a second- 214 level domain such as example.org. But the reservation of a TLD 215 also poses a unique challenge, whether the proponent is asking 216 for it to be reserved from use in the DNS root zone, or asking 217 for it to be added to the root zone: the IETF administers the 218 SUNR, but does not control the root zone. Under RFC 2860, ICANN 219 has that authority. More discussion on this point can be seen 220 below, but as a practical matter, IETF Working Groups should not 221 make such requests without compelling justification, and the IESG 222 should not advance them without asking what other options might 223 be available to satisfy relevant technical requirements. (Case: 224 home.arpa, RFC 8375) 226 1. Compatibility with an installed base might be a compelling 227 need to reserve a specific string as a single label or TLD. 228 This does impose a burden of coordination on ICANN, the IETF, 229 and the IAB, and adds to possible confusion for developers 230 and operators across the wider internet, so the bar to 231 proceeding in this way should be high. There should be 232 significant benefit to interoperability, at the very least. 233 (Case: .onion, .bit, etc.) 235 2. Preventing ICANN from delegating a name is not, by itself, a 236 compelling reason to reserve it in the SUNR. There's no 237 written policy or agreement that says it would work, and 238 ICANN may have no process or policy under which it could 239 determine whether such a reservation should be granted. 240 Risking name collision under different policies from 241 different authorities seems unwise, but so does using 242 standards action in one body to constrain policy in another. 243 (Case: home/corp/mail, draft-chapin-additional-tlds) 245 2. For names reserved as part of an IETF protocol, in a standards- 246 track RFC coming out of an IETF WG, proponents should consider 247 using .arpa (see the IAB note on home.arpa, and RFC 3172). This 248 can work whether the name is supposed to be instantiated in the 249 DNS or not, since the IAB sets policy for .arpa. (Case: 250 home.arpa) 252 3. Reserved domain names that aren't TLDs require less work for the 253 community because they don't have to be coordinated with another 254 body. All such names, however, should be carefully considered 255 regarding the characteristics discussed above: do they need to 256 exist in the public DNS, or just be valid in a limited scope, or 257 be reserved for another protocol? do they have semantic meaning 258 outside of the specific protocol or scope? do they need to be 259 human-friendly? etc. This may require adding some new questions 260 to the RFC 6761 list, which talks about how the names are treated 261 by DNS but otherwise not much about why they're being reserved or 262 how they're being used. (Case: home.arpa) 264 4. For names initially reserved or used outside of the IETF, for 265 which a proponent wants to add a special use name registry entry, 266 the bar should be just as high. For single labels in particular, 267 the IESG and the community should require both a stable 268 specification and some assurance that a one-time delegation won't 269 multiply as the protocol evolves or the community forks. This 270 may require a standards-track update to RFC 6761. 272 4. The Special Case of Top-Level Domains 274 One key question for all use cases is where in the domain name space 275 a given name should go. This is true regardless of whether the name 276 is intended for resolution in the DNS or as a "protocol switch" to 277 invoke another resolution mechanism. 279 As noted above, all of the cases described in this document are more 280 difficult if the proponents are attempting to reserve a single label 281 domain name, or "TLD". This is because the IETF delegated authority 282 some time ago to ICANN for the contents of the root zone of the DNS 283 (see RFC 2860). 285 RFC 6761 claims that the SUNR is based on a "protocol rule" with 286 unchallengeable precedence over ICANN policy. However, it's not 287 clear exactly what this means in practice. There's no process for 288 making a request to ICANN to add a TLD to the root zone, or a string 289 to the list of names ICANN commits won't be delegated, and it seems 290 likely that the effort of inventing one and coordinating it with 291 ICANN would not be justified unless there was a compelling need that 292 couldn't be met any other way. 294 ICANN has its own community and its own mechanisms for deciding what 295 names should be allowed (or not) in the DNS root zone, and with what 296 constraints. The IETF is not in a position to dictate ICANN's 297 decisions about what names to delegate in the root zone, or even 298 ICANN's policies on what names must not be delegated in the root 299 zone. It can be argued that while ICANN is not an SDO, its 300 relationship to the IETF is not unlike that of an SDO with an 301 overlapping interest in a protocol: while neither can dictate process 302 or policy to the other, an accomodation can generally be found when 303 potential conflicts appear. In the case of the IETF and ICANN, there 304 are several possible mechanisms. The simplest is probably the IETF 305 liaison to the ICANN Board of Directors, for which the IAB appoints 306 the liaison manager (https://www.iab.org/2018/02/07/call-for- 307 nominations-ietf-liaison-to-icann-board-of-directors-2/). 309 In the case of a TLD that the IETF wishes to reserve for "technical 310 use" (per RFC 2860), there's no clear, mutual understanding of what 311 it means. There's also no established guarantee that ICANN won't in 312 the future delegate that name in the public root zone for the DNS. 313 Such a commitment could be requested by the IAB via the IETF liaison 314 or some other means, but there's no assurance it would be obtained, 315 or that the reserved name would be equally useful without such a 316 commitment. 318 It may also be the case that the IETF wishes ICANN to delegate a TLD 319 in the root zone, with specific characteristics, for "technical use" 320 within the DNS-- such as the requirement seen in discussion of 321 home.arpa, originally specified as .home, that the name should exist 322 in the root zone so that DNSSEC would work as expected in local 323 environments. Again, such a request could be made, but would place 324 an even larger burden on ICANN's policies and processes than a 325 request that they commit to not delegating a name at all. There is 326 no way to project how long it would take or whether it would 327 ultimately succeed. 329 For these reasons, the bar for the IESG and the IETF community to 330 agree to request a TLD in the SUNR-- either that it should never be 331 delegated, or that it should be delegated accordingto conditions set 332 by the IETF-- should be very high indeed. The IESG SHOULD NOT make 333 such requests without a compelling reason that cannot, as a matter of 334 technical necessity, be met by a special use name elsewhere in the 335 domain name space. 337 5. Acknowledgements 339 This draft is the outcome of many conversations over many months, 340 including discussions in the DNSOP WG, the IAB, and the ICANN SSAC. 341 Particular thanks to Ed Lewis, Wendy Seltzer, Ralph Droms, Warren 342 Kumari, Lyman Chapin, Dave Thaler, Olaf Kolkman, Brian Trammell, Ted 343 Lemon, David Conrad, Andrew Sullivan, Ted Hardie, John Klensin, and 344 everyone who's expressed exasperation to the author with respect to 345 the issues discussed here. 347 6. Informative References 349 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 350 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 351 . 353 [RFC1035] Mockapetris, P., "Domain names - implementation and 354 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 355 November 1987, . 357 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 358 Requirement Levels", BCP 14, RFC 2119, 359 DOI 10.17487/RFC2119, March 1997, 360 . 362 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 363 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 364 2000, . 366 [RFC2860] Carpenter, B., Baker, F., and M. Roberts, "Memorandum of 367 Understanding Concerning the Technical Work of the 368 Internet Assigned Numbers Authority", RFC 2860, 369 DOI 10.17487/RFC2860, June 2000, 370 . 372 [RFC2870] Bush, R., Karrenberg, D., Kosters, M., and R. Plzak, "Root 373 Name Server Operational Requirements", RFC 2870, 374 DOI 10.17487/RFC2870, June 2000, 375 . 377 [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on 378 Encodings for Internationalized Domain Names", RFC 6055, 379 DOI 10.17487/RFC6055, February 2011, 380 . 382 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 383 RFC 6761, DOI 10.17487/RFC6761, February 2013, 384 . 386 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 387 DOI 10.17487/RFC6762, February 2013, 388 . 390 [RFC6943] Thaler, D., Ed., "Issues in Identifier Comparison for 391 Security Purposes", RFC 6943, DOI 10.17487/RFC6943, May 392 2013, . 394 [RFC6950] Peterson, J., Kolkman, O., Tschofenig, H., and B. Aboba, 395 "Architectural Considerations on Application Features in 396 the DNS", RFC 6950, DOI 10.17487/RFC6950, October 2013, 397 . 399 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 400 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 401 2015, . 403 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 404 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 405 October 2017, . 407 [RFC8324] Klensin, J., "DNS Privacy, Authorization, Special Uses, 408 Encoding, Characters, Matching, and Root Structure: Time 409 for Another Look?", RFC 8324, DOI 10.17487/RFC8324, 410 February 2018, . 412 Author's Address 414 Suzanne Woolf 415 39 Dodge St. #317 416 Beverly, MA 01915 417 USA 419 Email: suzworldwide@gmail.com