idnits 2.17.1 draft-wkumari-dnsop-alt-tld-04.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 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2015) is 3401 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 371, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-grothoff-iesg-special-use-p2p-names-02 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 A. Sullivan 5 Expires: July 6, 2015 Dyn 6 January 2, 2015 8 The ALT Special Use Top Level Domain 9 draft-wkumari-dnsop-alt-tld-04 11 Abstract 13 This document reserves a string (ALT) to be used as a TLD label in 14 non-DNS contexts or for names that have no meaning in a global 15 context. It also provides advice and guidance to developers 16 developing alternate namespaces. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on July 6, 2015. 35 Copyright Notice 37 Copyright (c) 2015 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 54 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 55 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. The ALT namespace . . . . . . . . . . . . . . . . . . . . . . 4 57 4. Advice to developers . . . . . . . . . . . . . . . . . . . . 6 58 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 61 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 63 8.2. Informative References . . . . . . . . . . . . . . . . . 8 64 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 8 65 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 67 1. Introduction 69 Many protocols and systems need to name entities. Names that look 70 like DNS names (a series of labels separated with dots) have become 71 common, even in systems that are not part of the global DNS. 73 This document provides a solution which should be used in most cases 74 instead of [RFC6761]. RFC6761 specifies Special Use TLDs which 75 should only be used in exceptional circumstances. 77 This document reserves the label "ALT" (short for "Alternate") as a 78 Special Use Domain ([RFC6761]). This label is intended to be used as 79 the final label (apart from the zero-length terminating label) to 80 signify that the name is not rooted in the DNS, and that normal 81 registration and lookup rules do not apply. 83 1.1. Requirements notation 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 1.2. Terminology 91 This document assumes familiarity with DNS terms and concepts. 92 Please see [RFC1034] for background and concepts. 94 o DNS context: The namespace anchored at the globally-unique DNS 95 root. This is the namespace / context that "normal" DNS uses. 97 o non-DNS context: Any other / alternate namespace. 99 o pseudo-TLD: A label that appears in a fully-qualified domain name 100 in the position of a TLD, but which is not registered in the 101 global DNS. 103 o TLD: The last visible label in either a fully-qualified domain 104 name or a name that is qualified relative to the root. See the 105 discussion in Section 2. 107 2. Background 109 The DNS is a tree, and so has a single root. Conventionally, a name 110 immediately beneath the root is called a "Top Level Domain" or "TLD". 111 TLDs usually delegate portions of their namespace to others, who may 112 then delegate further. The hierarchical, distributed and caching 113 nature of the DNS has made it the primary resolution system on the 114 Internet. 116 Domain names are terminated by a zero-length label, so the root label 117 is normally invisible. Truly fully-qualified names indicate the root 118 label explicitly, thus: "an.example.tld.". Most of the time, to save 119 typing, names are written implicitly relative to the root, thus: 120 "an.example.tld". In both of these cases, the TLD is the last label 121 that is visible in presentation format -- in this example, the string 122 "tld". (This little bit of pedantry is here because in different 123 contexts people can use the term "fully-qualified domain name" to 124 refer to either of these uses.) 126 The success of the DNS makes it a natural starting point for systems 127 that need to name entities in a non-DNS context, or that have no 128 unique meaning in a global context. These name resolutions can 129 therefore occur in a namespace distinct from the DNS. 131 In many cases, these systems build a DNS-style tree parallel to the 132 global DNS administered by IANA. They often use a pseudo-TLD to 133 cause resolution in the alternate namespace, using browser plugins, 134 shims in the name resolution process, or simply applications that 135 only use this alternate namespace. 137 In many cases the creators of these alternate namespaces have simply 138 chosen a convenient or descriptive string and started using it. 139 These new strings are "alternate" strings and are not registered 140 anywhere or part of the DNS. However they appear to be TLDs. Issues 141 may arise if they are looked up in the DNS. These include: 143 o User confusion: If someone emails a link of the form foo.bar 144 .pseudo-TLD to someone who does not have the necessary software to 145 resolve names in the pseudo-TLD namespace, the name will not 146 resolve and the user may become confused. 148 o Excess traffic hitting the DNS root: Lookups leak out of the 149 pseudo-TLD namespace and end up hitting the DNS root nameservers. 151 o Collisions: If the pseudo-TLD is eventually delegated from the 152 root zone the behavior may be non-deterministic. 154 o Lack of success for the user's original goal. 156 An alternate name resolution system might be specifically designed to 157 provide confidentiality of the looked up name, and to provide a 158 distributed and censorship resistant namespace. This goal would 159 necessarily be defeated if the queries leak into the DNS, because the 160 attempt to look up the name would be visible at least to the 161 operators of root name servers. 163 3. The ALT namespace 165 In order to avoid the above issues we reserve the ALT label. Unless 166 the name desired is globally unique, has meaning on the global 167 context and is delegated in the DNS, it should be considered an 168 alternate namespace, and follow the ALT label scheme outlined below. 169 The ALT label MAY be used in any domain name as a pseudo-TLD to 170 signify that this is an alternate (non-DNS) namespace. 172 Alternate namespaces should differentiate themselves from other 173 alternate namespaces by choosing a name and using it in the label 174 position just before the pseudo-TLD (ALT). For example, a group 175 wishing to create a namespace for Friends Of Olaf might choose the 176 string "foo" and use any set of labels under foo.alt. It is 177 RECOMMENDED that users register their usage of this string with the 178 IANA in Registry TBD, but users are not required to do so. This is 179 intended to help prevent collisions, but uniqueness is NOT 180 guaranteed. 182 As they are in an alternate namespace, they have no significance in 183 the regular DNS context and so should not be looked up in the DNS 184 context. Unfortunately simply saying that "something should not 185 happen" doesn't actually stop it from happening, so we need some 186 rules to deal with these. The ALT TLD is delegated to "new style" 187 AS112 servers, and so recursive and stub resolvers will get NXDOMAIN 188 for all queries. 190 1. Iterative resolvers SHOULD follow the advice in [RFC6303], 191 Section 3. 193 2. The ALT TLD is delegated to "new style" AS112 nameservers 194 ([I-D.ietf-dnsop-as112-dname] ), which will return NXDOMAIN for 195 all queries. 197 These rules are intended to limit how far unintentional / non-global 198 queries flow. 200 Groups wishing to create alternate namespaces SHOULD create their 201 alternate namespace "under" a label that names their namespace, and 202 "under" the ALT label. They SHOULD choose a label that they expect 203 to be unique / descriptive. They SHOULD consult the TBD registry to 204 see if anyone has published that they are already using this string, 205 and if so, would be wise to choose an alternative string or risk the 206 possibility of collisions with some other application. As there is 207 no requirement to register the use of a label in the ALT namespace, 208 uniqueness is not guaranteed. 210 Currently deployed projects and protocols that are using pseudo-TLDs 211 (for example, the ".onion" pseudo-TLD (and other labels in 212 [I-D.grothoff-iesg-special-use-p2p-names]) are encouraged but not 213 required to move under the ALT TLD. Rather, the ALT TLD is being 214 reserved so that future projects of a similar nature have a 215 designated place to create alternate resolution namespaces that will 216 not conflict with the regular DNS context. 218 A number of names other than .ALT were considered and discarded. In 219 order for this technique to be effective the names need to continue 220 to follow both the DNS format and conventions (a prime consideration 221 for alternate name formats is that they can be entered in places that 222 normally take DNS context names); this rules out using suffixes that 223 do not follow the usual letter, digit, and hyphen label convention. 224 Another proposal was that the ALT TLD instead be a reservation under 225 .arpa. This was considered, but rejected for several reasons. 227 1. We wished this to make it clear that this is not in the DNS 228 context, and .arpa clearly is. 230 2. The use of the string .ALT is intended to evoke the alt.* 231 hierarchy in Usenet. 233 3. We wanted the string to be short and easily used. 235 4. A name underneath .arpa would consume at least five additional 236 octets of the total 255 octets available in domain names, which 237 could put pressure on applications that need long machine- 238 generated names. 240 5. We are suggesting that the string .ALT get special treatment in 241 resolvers, and shim software. We are concerned that using 242 subdomains of an existing TLD (like .arpa) might end up with bad 243 implementations misconfiguring / overriding the TLD itself and 244 breaking .arpa. 246 There is a concern that if there were placed under .arpa, less 247 experienced nameserver operators may inadvertently cover .arpa. A 248 more significant concern is that the scope of the issue if the query 249 does leak, and the fact that this would then make the root of the 250 alternate naming namespace a third level domain, and not a second 251 one. A project may be willing to have a name of the form 252 example.alt, but example.alt.arpa may be not look as good. 254 4. Advice to developers 256 Often, a subdomain of an existing, owned domain may suffice. When 257 that is so, using a subdomain in the DNS is always preferable, and 258 safest in terms of not risking misuse/duplications/collisions. In 259 the rare instance in which it is NOT desirable to have the name in 260 the DNS, the .ALT namespace may be used. 262 An option would be for name resolution systems that operate outside 263 to DNS to "root" themselves under a DNS name that the project or 264 organization controls. So, for example if the Tor project controls 265 tor.example.com it could "root" their namespace under 266 onion.tor.example.com. The concept of "rooting" a non-DNS context in 267 a DNS context requires some explanation. This document tries to 268 mitigate collisions in the DNS context. This means that if a name 269 from the alternate naming system gets resolved in the DNS, it should 270 not conflict or cause unexpected behavior. By "rooting a non-DNS 271 context namespace in the DNS context, under a name controlled by the 272 project" we mean that the rightmost set of labels should, if resolved 273 in the DNS context be in a domain controlled by the developers / 274 project. This means that, in the above example the software 275 implementing the alternate namespace (browser plugins, custom stub 276 resolvers, etc) would then match on names that end in the string 277 "onion.example.com" and provide the alternate name resolution 278 (instead of matching on the strings ending in ".onion".) 280 In a number of cases the purpose of the alternate name resolution 281 system is to provide confidentiality. For these systems the above 282 advice is problematic. If the a query for one of these names (for 283 example dissident.onion.example.com (this is not a real .onion 284 address)) were to leak into the DNS the query would hit the recursive 285 resolver, and (assuming empty caches) would then hit the root, the 286 .com name servers, the example.com name servers and then the 287 onion.example.com nameservers. This means that the fact that a user 288 is resolving disident.onion.example.com would be visible to a large 289 number of people. Furthermore, the onion.example.com nameservers 290 become a good oracle to determine what names exist, and who is trying 291 to reach them. 293 For projects that are very latency sensitive, or which desire to 294 provide confidentiality we recommend rooting the alternate namespace 295 under the .ALT TLD. 297 5. IANA Considerations 299 The IANA is requested to add the ALT string to the "Special-Use 300 Domain Name" registry ([RFC6761], and reference this document. In 301 addition, the "Locally Served DNS Zones" ([RFC6303]) registry should 302 be updated to reference this document. 304 The IANA is requested to create and administer a new, first come, 305 first served registry named "ALT pseudo-TLD labels". 307 The fields in the registry should be: 309 Label: An ASCII string containing a maximum of 63 characters, using 310 only letters (a-z), digits (0-9), and hyphen (-). 312 Description: A short, textual description explaining what the label 313 is used for. 315 Reference: A link to a stable reference, such as an RFC, or contact 316 information for a person responsible for the reservation. 318 [ Ed: This section needs much cleanup - looking for something similar 319 to http://www.iana.org/assignments/address-family-numbers/address- 320 family-numbers.xhtml (with people for things that don't have RFC 321 references) ] 323 6. Security Considerations 325 One of the motivations for the creation of the alt pseudo-TLD is that 326 unmanaged labels in the managed root name space are subject to 327 unexpected takeover if the manager of the root name space decides to 328 delegate the unmanaged label. 330 The unmanaged and "registration not required" nature of labels 331 beneath .ALT provides the opportunity for an attacker to re-use the 332 chosen label and thereby possibly compromise applications dependent 333 on the special host name. 335 7. Acknowledgements 337 The authors understand that there is much politics surrounding the 338 delegation of a new TLD and thank the ICANN liaison in advance. 340 We would also like ot thank Paul Hoffman for feedback. 342 8. References 344 8.1. Normative References 346 [I-D.grothoff-iesg-special-use-p2p-names] 347 Grothoff, C., Wachs, M., hellekin, h., and J. Appelbaum, 348 "Special-Use Domain Names of Peer-to-Peer Systems", draft- 349 grothoff-iesg-special-use-p2p-names-02 (work in progress), 350 March 2014. 352 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 353 STD 13, RFC 1034, November 1987. 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 359 6303, July 2011. 361 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 362 RFC 6761, February 2013. 364 8.2. Informative References 366 [I-D.ietf-dnsop-as112-dname] 367 Abley, J., Dickson, B., Kumari, W., and G. Michaelson, 368 "AS112 Redirection using DNAME", draft-ietf-dnsop- 369 as112-dname-06 (work in progress), November 2014. 371 [I-D.ietf-sidr-iana-objects] 372 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 373 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 374 progress), May 2011. 376 Appendix A. Changes / Author Notes. 378 [RFC Editor: Please remove this section before publication ] 380 From -03 to -04 382 o Incorporated some comments from Paul Hoffman 384 From -02 to -03 386 o After discussions with chairs, made this much more generic (not 387 purely non-DNS), and some cleanup. 389 From -01 to -02 390 o Removed some fluffy wording, tightened up the language some. 392 From -00 to -01. 394 o Fixed the abstract. 396 o Recommended that folk root their non-DNS namespace under a DNS 397 namespace that they control (Joe Abley) 399 Authors' Addresses 401 Warren Kumari 402 Google 403 1600 Amphitheatre Parkway 404 Mountain View, CA 94043 405 US 407 Email: warren@kumari.net 409 Andrew Sullivan 410 Dyn 411 150 Dow Street 412 Manchester, NH 03101 413 US 415 Email: asullivan@dyn.com