idnits 2.17.1 draft-wkumari-dnsop-internal-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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 2, 2017) is 2488 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-dnsop-sutld-ps-06 == Outdated reference: A later version (-25) exists of draft-ietf-dnsop-alt-tld-08 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP W. Kumari 3 Internet-Draft Google 4 Intended status: Informational July 2, 2017 5 Expires: January 3, 2018 7 The .internal TLD. 8 draft-wkumari-dnsop-internal-00 10 Abstract 12 It has become clear that many users would like to use the DNS 13 resolution system for names which do not have meaning in the global 14 context but do have meaning in a context internal to their network. 15 This document reserves the string ".internal" for this purpose. 17 [ Ed note: Text inside square brackets ([]) is additional background 18 information, answers to frequently asked questions, general musings, 19 etc. They will be removed before publication. RFC Editor: Please 20 remove these before publication. ] 22 [ This document is being collaborated on in Github at: 23 https://github.com/wkumari/draft-wkumari-dnsop-internal. The most 24 recent version of the document, open issues, etc should all be 25 available here. The authors (gratefully) accept pull requests ] 27 [ Ed note: This document is intended to drive discussion. It is 28 clear that there has been a desire for an "RFC 1918-style" TLD for a 29 long time; in its absence, people have just started using whatever 30 seemed convenient. This document requests that the allocation of 31 .internal for this use. There is no existing process for this - some 32 of the purpose of this document is to explore the process 33 implications. ] 35 Status of This Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on January 3, 2018. 51 Copyright Notice 53 Copyright (c) 2017 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 69 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 70 2. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 3 71 3. Why not use ? . . . . . . . . . . . . . . . . 4 72 3.1. Why not use .alt? . . . . . . . . . . . . . . . . . . . . 4 73 3.2. Why not use something.arpa? . . . . . . . . . . . . . . . 5 74 3.3. Why not use .local? . . . . . . . . . . . . . . . . . . . 5 75 3.4. Why not use .example? . . . . . . . . . . . . . . . . . . 5 76 4. DNSSEC Considerations . . . . . . . . . . . . . . . . . . . . 5 77 4.1. Scenario 1 - No DNSSEC, .internal not delegated . . . . . 6 78 4.2. Scenario 2 - DNSSEC, .internal not delegated . . . . . . 6 79 4.3. Scenario 3 - DNSSEC, .internal delegated . . . . . . . . 6 80 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 81 5.1. Domain Name Reservation Considerations . . . . . . . . . 7 82 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 83 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 84 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 85 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 86 8.2. Informative References . . . . . . . . . . . . . . . . . 9 87 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 9 88 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 90 1. Introduction 92 Over the years, a number of strings have been used as pseudo-TLDs for 93 namespaces that are disjoint (or separate) from the "global DNS" 94 namespace. Common examples of these include .home and .corp. See 95 [I-D.chapin-additional-reserved-tlds], [I-D.ietf-dnsop-sutld-ps] for 96 more background information on this issue. The 98 [I-D.ietf-dnsop-sutld-ps] document discusses the issues in depth, and 99 should be considered required reading for understanding this 100 document. 102 The [I-D.ietf-dnsop-alt-tld] document reserves a string to be used as 103 a pseudo-TLD for non-DNS resolution contexts. However, it is clear 104 that there is a significant use case for a similar string to be used 105 for namespaces which are resolved using the DNS protocol, but which 106 do not have a meaning in the global DNS context. 108 There is no way to prevent users from simply picking a string (such 109 as .home) and starting to use it for internal use. Unfortunately, 110 although these strings are supposed to only be used internally, there 111 is ample evidence that they often leak into the global DNS, sometimes 112 causing technical issues for the user of the no-longer internal name. 114 This document requests allocation of a string to be used as a pseudo- 115 TLD for namespaces that are not part of the global DNS, but are meant 116 to be resolved with the DNS protocol. A reasonable analogy is that 117 this is to names as [RFC1918] is to IP addresses. Such a reservation 118 should alleviate pollution, such as junk queries at the root, and 119 potential collisions with other users of the namespace. 121 Note that there was a discussion of the .homenet delegation in the 122 HOMENET WG, and the resulting decision was to *not* request that the 123 name be delegated as a TLD for the IETF's use. This document has 124 significant similarities to the .homenet case, but also significant 125 differences. These include (in no particular order) the fact that 126 the use case is significant broader, and that there is no urgency to 127 the request and does not delay or create uncertainty for any protocol 128 work. 130 1.1. Requirements notation 132 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 133 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 134 document are to be interpreted as described in [RFC2119]. 136 2. Use cases 138 The ".internal" TLD can be used for any purpose where a non-global 139 DNS name is needed. 141 This includes creating a namespace "behind" a Customer Premises 142 Equipment (CPE). For example, the Belkin company used ".belkin" for 143 this. British Telecom used ".home", and shipped devices named 144 "bthomehub.home" [BT_HOME_HUB]). Additionally, internal resolution 145 systems like Microsoft Active Directory have documentation that 146 suggests (or previously suggested) that administrators use ".corp" 147 for these cases. 149 The .internal TLD is intended to address some of the issues 150 documented in the Special-Use Domain Names Problem Statement 151 [I-D.ietf-dnsop-sutld-ps] specifically (from the list in Section 3): 153 5.3: Intended use is covered by gTLD process, but the third party 154 doesn't want to pay a fee. 156 5.4: Intended use is covered by some IETF process, but the third 157 party doesn't want to follow the process. 159 5.6: Unaware that a name intended to be used only locally may 160 nevertheless leak 162 5.7: Unaware that a name used locally with informal allocation may 163 subsequently be allocated formally, creating operational problems. 165 18 There exists no safe, non-process-violating mechanism for ad-hoc 166 assignment of Special-Use Domain Names. 168 Other use cases for .internal include its use in testing, 169 prototyping, and benchmarking. Researchers have often needed to set 170 up a fake root and namespace in order to test something, and have 171 needed an arbitrarily chosen a name for a piece of network equipment 172 which it not connected to the Internet. 174 3. Why not use ? 176 The IANA "Special Use Names" registry [IANA.SUN] already contains 177 some names which, it could be argued, already meet this need. 178 Unfortunately, many of these names (such as ".example") are either 179 reserved for a specific use case, or are semantically unsuitable (for 180 example, a CPE manufacturer would likely not find "Open a browser and 181 connect to 'router.invalid'" acceptable). 183 This section discusses why existing strings in the Special-Use Domain 184 Names registry ([IANA.SUN]) are not appropriate. 186 3.1. Why not use .alt? 188 The proposed .alt presudo-TLD is specifically only for use as a 189 pseudo-TLD for non-DNS resolution contexts. At one point .alt was 190 being considered both for DNS and non-DNS resolution contexts, but, 191 after much discussion it was decided that the DNSSEC implications 192 (and desired behavior) meant that .alt should be reserved 193 specifically for non-DNS resolution. 195 3.2. Why not use something.arpa? 197 This is indeed an interesting idea. I suspect that it fails the 198 semantically desirable / understandable case, but is definitely worth 199 further discussion. It may also cause issues when server operators 200 override part of the .arpa domain in order to instantiate 201 something.arpa. 203 3.3. Why not use .local? 205 .local is already in wide use and has special handling implemented 206 for handing .local names. See [RFC6762] Section 22.1 Subsection 3, 207 4, 5. 209 3.4. Why not use .example? 211 .example, .example.[com|net|org] may indeed be appropriate. 212 Unfortunately, the hard part of all of this is not the selection and 213 adding of a name to the "Special Use Names" registry, but rather 214 deciding if this should be done and, if so, the process to interact 215 with ICANN in order to achieve the delegation. 217 4. DNSSEC Considerations 219 The .internal TLD would be an unsigned TLD, as there is no (clean) 220 way to sign it. 222 This particular topic received much discussion during the "Should 223 .alt be used for DNS, or only non-DNS resolution" discussions, and 224 was the cause of much confusion and misunderstandings. Much of this 225 revolved around why it is important to have an insecure DNSSEC 226 delegation for a name which is added to the Locally-Served DNS Zones 227 ( [IANA.LocallyServed] ) registry, or any other case where a name is 228 instantiated. It is briefly covered here, but interested readers 229 should review the DNSOP mailing list archive for more details. 231 Take the following figure: 233 +-----------+ +----------+ 234 .-------. | | | Stub | 235 ( Root <-----| Resolver <---------| Resolver | 236 `-------' +-----------+ +----------+ 237 A B C 239 The user has just purchased a new CPE, which creates an internal 240 namespace called .internal, and responds to lookups for 241 router.interal with its (internal) management IP address (another 242 example would be a corporate user at an organization which has 243 created a private internal namespace disconnected from the public, 244 global DNS). The CPE hands out addresses using DHCP, and lists 245 itself as the DNS server. 247 The user follows the instructions included in the box, and enters 248 "http://router.internal" into a web browser. This causes a DNS 249 lookup to be sent from the user's stub to the recursive resolver. 250 The recursive resolver correctly identifies that this is query is for 251 itself, and so responds with an answer saying "router.internal is 252 192.168.0.1". 254 4.1. Scenario 1 - No DNSSEC, .internal not delegated 256 In this scenario, the .internal name has not been added to the root 257 zone, and the user's stub resolver *does not* perform DNSSEC 258 validation. The stub receives the response, performs no validation, 259 and so trust the answer and connects. The user is happy. This is 260 the current behavior for non-DNSSEC validating stubs. 262 4.2. Scenario 2 - DNSSEC, .internal not delegated 264 In this scenario, the .internal name has not been added to the root 265 zone, and the user's stub resolver *does* perform DNSSEC validation. 266 (Note that it is believed that validating stubs are currently rare.) 267 The stub receives the response, and begins DNSSEC validation. As the 268 .internal TLD has not been added to the root zone, DNSSEC 269 Authenticated Denial of Existence proves that the .internal TLD does 270 not exist (currently there is an NSEC record proving that nothing 271 exists between .intel and .international). This resulting outcome is 272 a DNSSEC "bogus" answer, the user is unable to connect, and becomes 273 frustrated. This is the current behavior for DNSSEC validating 274 stubs. 276 4.3. Scenario 3 - DNSSEC, .internal delegated 278 In this scenario, the .internal name has been added to the DNS root 279 zone, with an insecure delegation to AS112 (by "insecure delegation" 280 we mean that that there is no DS record for .internal in the root 281 zone; the .internal domain is unsigned). The stub receives the 282 response, and performs DNSSEC validation. As .internal has been 283 delegated, there is an (insecure) entry in the root zone, proving 284 that the .internal TLD exists. As it is an insecure delegation, the 285 validating stub is perfectly happy to accept the "router.internal is 286 192.168.0.1" response, the user connects to their router, and 287 everyone is happy. 289 5. IANA Considerations 291 This document requests that the .internal TLD be assigned to the IANA 292 (similar to the way that .example is) and a DNSSEC insecure 293 delegation (that is, a delegation with no DS records) be inserted 294 into the root-zone, delegated to blackhole-[12].iana.org. 296 [Editor's note: This is not something which the IANA currently has 297 the authority to do. This fact was extensively discussed during the 298 .homenet discussions. This text in the IANA considerations should be 299 considered a placeholder for "what someone needs to do if this gets 300 IETF consensus". If there is consensus that the reservation of 301 .internal makes sense, there will need to be some process design 302 before implementation. Such a process might be similar to "the IESG 303 asks the IAB to request ICANN to consider the reservation / 304 delegation of this string". ICANN does not currently have a process 305 for handling requests like these, and so will also likely need to 306 design a process for this. It is possible that either process might 307 not be designed and this will fail. It is also possible that the 308 IETF makes a request and ICANN does not make the delegation. ] 310 5.1. Domain Name Reservation Considerations 312 [ Ed: This section is to satisfy the requirement in Section 5 of 313 RFC6761. This document is intended to spark a discussion, there is 314 currently no process for the IETF / IAB to request that ICANN 315 delegate a TLD for special use, and simply adding .internal to the 316 "Special-Use Domain Name" registry ([IANA.SUN]) does not accomplish 317 this. I have decided to fill in the RFC6761 "questions" simply to 318 clarify the expected behavior. This entire section needs to be 319 removed before publication. ] 321 The string ".internal." is special in the following ways: 323 1. Users may know that strings that end in .internal behave 324 differently to normal DNS names. They may expect that names of 325 the form .internal refer to resources internal to 326 their network / enterprise / similar. 328 2. Writers of application software not required to perform any 329 special handing for .internal names. They are resolved normally, 330 using the DNS. 332 3. Writers of name resolution APIs and libraries are not expected to 333 perform special handling. 335 4. Caching DNS servers MAY recognize these names as special. By 336 default they should answer them locally (using "Locally Served 337 Zones"), but may be configured to forward them to authoritative 338 servers. 340 5. Authoritative DNS servers SHOULD NOT recognize these names as 341 special and should not perform any special handling with them, 342 unless they wish to instantiate an internal namespace, in which 343 case they can choose to simply create any names within .internal 344 that they want. Names are "local" to the network, and only have 345 meaning within that network. 347 6. DNS server operators SHOULD be aware that queries for names 348 ending in .internal are not part of the global, IANA DNS, and 349 were leaked into the global DNS. This information may be useful 350 for support or debugging purposes. 352 7. DNS Registries/Registrars MUST NOT grant requests to register 353 ".internal" names in the normal way to any person or entity. 354 These ".internal" names are defined by protocol specification to 355 be nonexistent, and they fall outside the set of names available 356 for allocation by registries/registrars. 358 6. Security Considerations 360 This section will certainly be filled in later as the discussion 361 progresses. 363 7. Acknowledgements 365 The authors wish to thank Steve Crocker, Wes Hardaker, David 366 Lawrence, Suzanne Woolf, and many others on the DNSOP mailing list. 368 The author would like to especially think Paul Hoffman for creating a 369 Pull Request. 371 8. References 373 8.1. Normative References 375 [I-D.ietf-dnsop-sutld-ps] 376 Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 377 Names Problem Statement", draft-ietf-dnsop-sutld-ps-06 378 (work in progress), June 2017. 380 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 381 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 382 RFC2119, March 1997, 383 . 385 8.2. Informative References 387 [BT_HOME_HUB] 388 IANA, "I have problems connecting 5GHz and dual band 389 devices wirelessly to the BT Hub", 390 . 393 [I-D.chapin-additional-reserved-tlds] 394 Chapin, L. and M. McFadden, "Additional Reserved Top Level 395 Domains", draft-chapin-additional-reserved-tlds-02 (work 396 in progress), March 2015. 398 [I-D.ietf-dnsop-alt-tld] 399 Kumari, W. and A. Sullivan, "The ALT Special Use Top Level 400 Domain", draft-ietf-dnsop-alt-tld-08 (work in progress), 401 March 2017. 403 [IANA.LocallyServed] 404 IANA, "Locally Served DNS Zones", 405 . 408 [IANA.SUN] 409 IANA, "Special-Use Domain Names", 410 . 413 [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., 414 and E. Lear, "Address Allocation for Private Internets", 415 BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, 416 . 418 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 419 DOI 10.17487/RFC6762, February 2013, 420 . 422 Appendix A. Changes / Author Notes. 424 [RFC Editor: Please remove this section before publication ] 426 -00 428 o This document was originally started in late 2014 / early 2015, 429 but languished until being revived in June 2017. 431 Author's Address 433 Warren Kumari 434 Google 435 1600 Amphitheatre Parkway 436 Mountain View, CA 94043 437 US 439 Email: warren@kumari.net