idnits 2.17.1 draft-ietf-dnsop-private-use-tld-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 564 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 08, 2020) is 1295 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 8499 (ref. 'BCP-219') (Obsoleted by RFC 9499) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Independent Submission R. Arends 3 Internet-Draft ICANN 4 Intended status: Best Current Practice J. Abley 5 Expires: April 11, 2021 Public Interest Registry 6 October 08, 2020 8 Top-level Domains for Private Internets 9 draft-ietf-dnsop-private-use-tld-00 11 Abstract 13 There are no defined private-use namespaces in the Domain Name System 14 (DNS). For a domain name to be considered private-use, it needs to 15 be future-proof in that its top-level domain will never be delegated 16 from the root zone. The lack of a private-use namespace has led to 17 locally configured namespaces with a top-level domain that is not 18 future proof. 20 The DNS needs an equivalent of the facilities provided by BCP 5 (RFC 21 1918) for private internets, i.e. a range of short, semantic-free 22 top-level domains that can be used in private internets without the 23 risk of being globally delegated from the root zone. 25 The ISO 3166 standard is used for the definition of eligible 26 designations for country-code top-level Domains. This standard is 27 maintained by the ISO 3166 Maintenance Agency. The ISO 3166 standard 28 includes a set of user-assigned code elements that can be used by 29 those who need to add further names to their local applications. 31 Because of the rules set out by ISO in their standard, it is 32 extremely unlikely that these user-assigned code elements would ever 33 conflict with delegations in the root zone under current practices. 34 This document explicitly reserves these code elements to be safely 35 used as top-level domains for private DNS resolution. 37 Status of This Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at https://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on April 11, 2021. 54 Copyright Notice 56 Copyright (c) 2020 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents 61 (https://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction 72 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains 73 3. ISO 3166-1 alpha-2 User-assigned Code Elements 74 4. Examples of Current Uses of the User-assigned Code Elements. 75 5. Private-use top-level Domains 76 6. IANA Considerations 77 7. Security Considerations 78 8. Acknowledgements 79 9. Informative References 80 Authors' Addresses 82 1. Introduction 84 In private networks where a hostname has no utility in the global 85 namespace, it is convenient to have a private-use namespace. Such 86 deployments could theoretically use sub-domains of a domain 87 registered for the specific hosting entity, though not all such 88 configurations have such a domain available. When the hostname is 89 solely used in a private network, it is not necessary that it 90 resolves globally. 92 Another situation is where applications use identifiers that are 93 similar in appearance to domain names, and may be interpreted by 94 software as domain names, but are not intended to use the global DNS 95 resolution service. Using a private-use namespace helps guard 96 against conflicts with the global DNS resolution system. 98 Note that a private-use namespace is not a subset of a registered 99 special use namespace [IANA-Special]. There is no facility to 100 register a specific label using the process defined in [RFC6761]. 101 The process in RFC 6761 requires that a label has some kind of 102 special handling in order to be considered special. A private-use 103 namespace can be considered special on a policy level, but not on a 104 technical or protocol level. 106 Many protocols outside the DNS have a defined set of elements for 107 private use, or an identifier that indicates private use, such as 108 "X-headers" MIME types [RFC2045], addresses for private internets 109 [BCP-5], the "x-" sub-tag in private-use language tags [BCP-47], 110 private-use Autonomous System Numbers [BCP-6], and private-use DNS 111 RRTypes and RCODEs [BCP-42]. 113 There is currently no such facility for the DNS namespace. A user is 114 required to resort to registering a globally unique domain where a 115 locally unique domain would suffice, or may configure a domain name 116 that is not currently delegated from the root zone. Additionally, 117 there are plenty of examples of device vendors that ship networking 118 devices with a default setting for DHCP [RFC2131] option 15 (domain 119 name) [RFC2132], containing a top-level domain that is believed to 120 not be delegated in the root zone. 122 In practice, the lack of a private-use namespace facility has led to 123 the deployment of arbitrary, unregistered, semantically meaningful 124 top-level domains, such as ".home", ".dhcp", ".lan", ".localdomain", 125 ".internal", ".dlink", ".ip" and ".corp" [ITHI]. These examples of 126 locally configured strings are derived from traffic to the ICANN 127 Managed Root Servers [IMRS] and are part of the most popular observed 128 query names [BCP-219]. 130 While these commonly chosen strings currently do not exist in the 131 root zone, there is no guarantee that these strings will not be 132 delegated in the root zone in the future. Therefore, there is no 133 guarantee that the local use of these strings (or other strings that 134 might be chosen for private use) will be stable, safe, and secure. 135 Similarly, there is no guarantee that any of these strings will be 136 deemed special-use via an application according to [RFC6761]. 138 There are many uses for private-use names. It is not feasible to 139 assign a semantically meaningful, relatively short top-level label to 140 each individual private-use of a namespace in multiple languages. 141 Similar to "X-headers" MIME types, and analogous in concept to 142 address allocation for private internets, this document defines a 143 range of abstract, two-letter labels that are aligned with the user- 144 assigned two-letter code elements in the ISO 3166-1 alpha-2 145 [ISO3166-1] standard. 147 2. The ISO 3166-1 alpha-2 and Two-Letter Top-Level Domains 149 IANA's practice of governing the delegation of ASCII two-letter 150 domain names in the DNS [STD13] root zone is to align it with 151 assignment of two-letter (known as "alpha-2") code elements in the 152 ISO 3166-1 standard [ISO3166-1]. The ISO 3166-1 standard contains 153 many categories of code elements, with the "officially assigned" and 154 some "exceptionally reserved" code elements being used in the DNS to 155 represent entities as country-code top-level domains (ccTLDs) 156 [RFC1591]. The interrelationship is documented in "ICANN and the 157 ISO, A Common Interest in ISO Standard 3166" [ICANNISO]. 159 In addition to the assigned, available, and reserved code elements, 160 there are code elements designated as "user-assigned". The intent of 161 user-assigned code elements is to provide the user with a code 162 element when no other code element satisfies the intended use. 164 3. ISO 3166-1 alpha-2 User-assigned Code Elements 166 The ISO 3166-1 standard states in section 5.2: 168 "In addition, exactly 42 alpha-2 code elements are not used in the 169 ISO 3166, AA, QM to QZ, XA to XZ, ZZ." 171 And explains in clause 8.1 "Special Provisions": 173 "Users sometimes need to extend or alter the use of country-code 174 elements for special purposes. The following provisions give 175 guidance for meeting such needs within the framework of this part 176 of ISO 3166. " 178 And finally, clause 8.1.3 "User assigned code element": 180 "If users need code elements to represent country names not 181 included in this part of ISO 3166, the series of letters AA, QM to 182 QZ, XA to XZ, and ZZ, and the series AAA to AAZ, QMA to QZZ, XAA 183 to XZZ, and ZZA to ZZZ respectively and the series of numbers 900 184 to 999 are available. NOTE Users are advised that the above 185 series of codes are not universals, those code elements are not 186 compatible between different entities." 188 As shown above, the ISO 3166-1 user-assigned alpha-2 code elements 189 are defined to be AA, QM to QZ, XA to XZ, and ZZ. The ranges ("to") 190 are alphabetic and contain only characters in the US-ASCII definition 191 [STD80]. 193 It is unlikely that the user-assigned range will change. 195 4. Examples of Current Uses of the User-assigned Code Elements. 197 Using code elements to represent an entity other than a country name 198 may appear to deviate from the intended use of the ISO 3166-1 199 standard. However, many organizations, including the IETF and the 200 ISO, have used the user-assigned range to represent entities other 201 than country names. The following list is not exhaustive but 202 illustrates the wide variety of current uses of codes within the ISO 203 3166-1 user-assigned alpha-2 range. 205 o The International Standard Recording Code (ISRC) [ISO3901] uses 206 code element "ZZ" from the User-assigned range for direct 207 registrants independent of any country. 209 o The ISO Currency Codes standard [ISO4217] uses code elements "XA" 210 to "XZ" from the user-assigned range for transactions and precious 211 metals. 213 o International Securities Identification Numbers [ISO6166] uses the 214 following code elements from the user-assigned range: 216 QS: internally used by Euroclear France 218 QT: internally used in Switzerland 220 QW: internally used in WM Datenservice Germany for historical data 222 XA: CUSIP Global Services substitute agencies 224 XB: NSD Russia substitute agencies 226 XC: WM Datenservice Germany substitute agencies 228 XD: SIX Telekurs substitute agencies 230 XF: internally assigned, non-unique numbers 232 XS: Euroclear and Clearstream international securities 234 o The International Civil Aviation Organization [ICAO] Machine 235 Readable Travel Documents standard uses code element "ZZ" from the 236 user-assigned range for UN travel documents. 238 o The World Intellectual Property Organization [WIPO] Standard 3 239 uses the following code elements from the user-assigned range: 241 QZ: Community Plant Variety Office (European Union) (CPVO). 243 XN: Nordic Patent Institute (NPI). 245 XU: International Union for the Protection of New Varieties of 246 Plants (UPOV). 248 XV: Visegrad Patent Institute (VPI) 250 XX: recommended to refer to unknown states, other entities or 251 organizations. 253 o The United Nations Code for Trade and Transport Locations 254 [UNLOCODE] uses the code element "XZ" from the user-assigned range 255 for international waters in accordance with ISO 3166-1 clause 256 8.1.3: 258 "3.2.5 In cases where no ISO 3166 country-code element is 259 available, e.g. installations in international waters or 260 international cooperation zones, the code element "XZ", available 261 for user assignment in accordance with clause 8.1.3 of ISO 262 3166-1/1997, will be used." 264 o The World Bank Country API [WORLDBANK] uses the following code 265 elements from the User-assigned range: 267 XC: Euro area 269 XD: High income 271 XE: Heavily indebted poor countries (HIPC) 273 XF: International Bank for Reconstruction and Development 275 XH: Blend 277 XI: International Development Association 279 XJ: Latin America and Caribbean (excluding high income) 281 XL: Least developed countries: UN classification 283 XM: Low income 285 XN: Lower middle income 287 XO: Low & middle income 289 XP: Middle income 291 XQ: Middle East & North Africa (excluding high income) 293 XT: Upper middle income 295 XU: North America 297 XX: Not classified 299 XY: Not Classified 301 o The Interpol Implementation data format for the interchange of 302 fingerprint, facial & scar-mark-tattoo information [INTERPOL] uses 303 code element "ZZ" from the user-assigned range as follows: 304 Destination Agency Identifier "ZZ/ALL" is reserved for 305 transactions which shall be distributed by INTERPOL AFIS to all 306 INTERPOL member states." 308 o The Certificate Authority Browser Forum Baseline Requirements for 309 the Issuance and Management of Publicly-Trusted Certificates 310 [CABForum] states that if a country is not represented by an 311 official ISO 3166-1 alpha-2 country-code, the CA may specify the 312 user-assigned code element "XX" to indicate that an official code 313 element has not been assigned. 315 o The UNICODE Common Locale Data Repository (CLDR) [UNICODE] version 316 37 uses the following code elements from the user-assigned range: 318 QO: Outlying Oceania; countries in Oceania that do not have a 319 subcontinent. 321 XA: Pseudo-Accents; special code indicating derived testing locale 322 with English + added accents and lengthened. 324 XB: Pseudo-Bidi; special code indicating derived testing locale 325 with forced RTL English. 327 ZZ: Unknown Region; used in APIs or as a replacement for invalid 328 code. 330 o The IETF Best Current Practice 47 [BCP-47] contains a section and 331 examples dedicated to private-use subtags, using code elements 332 from the user-assigned range: 334 "For example, the region subtags 'AA', 'ZZ', and those in the 335 ranges 'QM'-'QZ' and 'XA'-'XZ' (derived from the ISO 3166-1 336 alpha-2 private use codes) can be used to form a language tag. A 337 tag such as "zh-Hans-XQ" conveys a great deal of public, 338 interchangeable information about the language material" 340 o The IETF Proposed Standard "Internationalized Domain Names for 341 Applications" [RFC5890] uses the XN-- prefix. The method that was 342 used to decide on the prefix was explained in an email from the 343 IANA to the IETF IDN Working Group list [XNIDN]: 345 "The following steps will be used to select the two-character 346 code: 348 The code will be selected from among a subset of the entries on 349 the ISO 3166-1, clause 8.1.3 User-assigned alpha-2 code elements: 350 AA, QM to QZ, XA to XZ, and ZZ. The selection is limited to these 351 codes because of the following: 353 The use of ISO 3166-1 User-assigned elements removes the 354 possibility that the code will duplicate a present or future ccTLD 355 code." 357 5. Private-use top-level Domains 359 The user-assigned classification of these code elements in the ISO 360 3166-1 alpha-2 standard allows for the assumption that these code 361 elements will not risk delegation as country-code top-level Domains 362 through future assignments to represent a country or territory. To 363 quote [XNIDN]: 365 "The use of ISO 3166-1 User-assigned elements removes the 366 possibility that the code will duplicate a present or future ccTLD 367 code." 369 Using these code elements as top-level domains for the purpose of 370 private-use TLDs is in line with the intended use of these code 371 elements and follows the many examples of other standards and 372 protocols. Furthermore, they are short and free of any semantic 373 meaning. 375 This document does not recommend any specific ISO 3166-1 alpha-2 376 user-assigned code as a private use, but instead proposes that any of 377 them can be used by a network or application for private use. That 378 is, there is no attempt to choose just one of the ISO 3166-1 Alpha-2 379 user-assigned codes for use as private-use TLDs, just as other 380 organizations use multiple user-assigned codes for many internal 381 purposes. 383 Note that there may be software that treats labels beginning with XN 384 differently due to the use of the XN- prefix in internationalized 385 domain names [RFC5890]. 387 6. IANA Considerations 389 This document makes the observation that the policy of assigning 390 ccTLD labels is to align with the ISO-3166-1 alpha-2 standard 391 [RFC1591], which includes user-assigned code elements that will never 392 be assigned to a territory [ISO3166-1]. This is then consistent with 393 existing policies that those user-assigned codes will never be 394 delegated from the DNS root zone and, for that reason, will never 395 give rise to collisions with any future new TLD. 397 7. Security Considerations 399 Use of private-use identifiers of any sort almost always results in 400 unexpected collisions in practice. This has repeatedly been shown 401 for private-use addresses, private-use identifiers (such as "x- 402 headers") and private-use names in the DNS. These unexpected 403 collisions can easily have security ramifications that are well 404 beyond what the user understands. 406 8. Acknowledgements 408 This document is based on an earlier draft by Ed Lewis. David 409 Conrad, Paul Hoffman, Sion Lloyd, Alain Durand, Jaap Akkerhuis, Kal 410 Feher, Andrew Sullivan, Joe Abley, Petr Spacek, Patrick Mevzek and 411 Kim Davies have played a role. 413 9. Informative References 415 [BCP-219] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 416 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 417 January 2019, . 419 [BCP-42] Eastlake 3rd, D., "Domain Name System (DNS) IANA 420 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 421 April 2013, . 423 [BCP-47] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 424 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 425 September 2009, . 427 [BCP-5] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 428 and E. Lear, "Address Allocation for Private Internets", 429 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 430 . 432 [BCP-6] Mitchell, J., "Autonomous System (AS) Reservation for 433 Private Use", BCP 6, RFC 6996, DOI 10.17487/RFC6996, July 434 2013, . 436 [CABForum] 437 "CA/Browser Forum Baseline Requirements for the Issuance 438 and Management of Publicly-Trusted Certificates, version 439 1.6.9", March 2020, . 442 [IANA-Special] 443 "Special-Use Domain Names", n.d., 444 . 447 [ICANNISO] 448 "ICANN and the International Organization for 449 Standardization (ISO)", n.d., 450 . 453 [ICAO] "International Civil Aviation Organization, Machine 454 Readable Travel Documents, Part 3; Specifications Common 455 to all MRTDs", n.d., . 458 [IMRS] "ICANN Managed Root Server", n.d., 459 . 461 [INTERPOL] 462 "Interpol Implementation data format for the interchange 463 of fingerprint, facial & smt information", n.d., 464 . 467 [ISO3166-1] 468 "ISO 3166-1:2013 Codes for the representation of names of 469 countries and their subdivisions - Part 1: Country codes", 470 2013, . 472 [ISO3901] "Information and documentation -- International Standard 473 Recording Code (ISRC)", n.d., 474 . 476 [ISO4217] "ISO 4217; Codes for the representation of currencies and 477 funds", n.d., 478 . 480 [ISO6166] "Securities and related financial instruments -- 481 International securities identification numbering system 482 (ISIN)", n.d., . 484 [ITHI] "ICANN's Identifier Technology Health Indicator; Queries 485 to frequently leaked strings", n.d., 486 . 488 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 489 RFC 1591, DOI 10.17487/RFC1591, March 1994, 490 . 492 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 493 Extensions (MIME) Part One: Format of Internet Message 494 Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996, 495 . 497 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 498 RFC 2131, DOI 10.17487/RFC2131, March 1997, 499 . 501 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 502 Extensions", RFC 2132, DOI 10.17487/RFC2132, March 1997, 503 . 505 [RFC5890] Klensin, J., "Internationalized Domain Names for 506 Applications (IDNA): Definitions and Document Framework", 507 RFC 5890, DOI 10.17487/RFC5890, August 2010, 508 . 510 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 511 RFC 6761, DOI 10.17487/RFC6761, February 2013, 512 . 514 [STD13] Mockapetris, P., "Domain names - concepts and facilities", 515 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 516 . 518 [STD80] Cerf, V., "ASCII format for network interchange", STD 80, 519 RFC 20, DOI 10.17487/RFC0020, October 1969, 520 . 522 [UNICODE] "CLDRv37 - Unicode Common Locale Data Repository version 523 37", April 2020, 524 . 526 [UNLOCODE] 527 "United Nations Code for Trade and Transport Locations; 528 UN/LOCODE Manual", n.d., 529 . 532 [WIPO] "World Intellectual Property Organization; Recommended 533 standard on two-letter codes for the representation of 534 states, other entities and intergovernmental 535 organizations.", n.d., 536 . 539 [WORLDBANK] 540 "Worldbank API V2 Country API", n.d.. 542 [XNIDN] "Results of IANA Selection of IDNA Prefix", February 2003, 543 . 545 Authors' Addresses 547 Roy Arends 548 ICANN 550 Email: roy.arends@icann.org 552 Joe Abley 553 Public Interest Registry 554 470 Moore Street 555 London, true N6C 2C2 556 Canada 558 Email: jabley@pir.org