idnits 2.17.1 draft-wkumari-dnsop-alt-tld-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 : ---------------------------------------------------------------------------- == 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 (July 4, 2014) is 3578 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 291, 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: January 5, 2015 Dyn 6 July 4, 2014 8 The ALT Special Use Top Level Domain 9 draft-wkumari-dnsop-alt-tld-02 11 Abstract 13 This document reserves a string (ALT) to be used as a TLD label in 14 non-DNS contexts. It also provides advice / guidance to developers 15 developing alternate namespaces. 17 Status of This Memo 19 This Internet-Draft is submitted in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF). Note that other groups may also distribute 24 working documents as Internet-Drafts. The list of current Internet- 25 Drafts is at http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 This Internet-Draft will expire on January 5, 2015. 34 Copyright Notice 36 Copyright (c) 2014 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 2 53 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. The ALT namespace . . . . . . . . . . . . . . . . . . . . . . 4 56 4. Advice to developers . . . . . . . . . . . . . . . . . . . . 5 57 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 58 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 59 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 60 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 8.1. Normative References . . . . . . . . . . . . . . . . . . 6 62 8.2. Informative References . . . . . . . . . . . . . . . . . 7 63 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 7 64 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 66 1. Introduction 68 Many protocols and systems need to name entities. Names that look 69 like DNS names (a series of labels separated with dots) have become 70 common, even in systems that are not part of the DNS. 72 This document reserves the string "ALT" (short for "Alternate") as a 73 Special Use Domain ([RFC6761]) that should be used in the right-most 74 label position to signify that this name is not rooted in the DNS, 75 and that normal registration and lookup rules do not apply. 77 1.1. Requirements notation 79 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 80 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 81 document are to be interpreted as described in [RFC2119]. 83 1.2. Terminology 85 This document assumes familiarity with DNS terms and concepts. 86 Please see [RFC1034] for background and concepts. 88 o DNS context: The namespace administered by ICANN. This is the 89 namespace / context that "normal" DNS uses. 91 o non-DNS context: Any other / alternate namespace. 93 2. Background 95 The DNS is a tree, and so has a single root. Conventionally, a name 96 immediately beneath the root is called a "Top Level Domain" or "TLD". 97 TLDs usually delegate portions of their namespace to others, who may 98 then delegate further. The hierarchical, distributed and caching 99 nature of the DNS has made it the primary resolution system on the 100 Internet. 102 The success of the DNS makes it a natural starting point for systems 103 that need to name entities in a non-DNS context. These name 104 resolutions occur in a namespace distinct from the DNS. A number of 105 good examples of these sorts of systems are documented in Special-Use 106 Domain Names of Peer-to-Peer Systems 107 [I-D.grothoff-iesg-special-use-p2p-names]. 109 In many cases, these systems build a DNS style tree parallel to the 110 global DNS administered by IANA. They often use a pseudo-TLD to 111 cause resolution in this alternate namespace, using browser plugins, 112 shims in the name resolution process, or simply applications that 113 only use this alternate namespace. 115 In many cases the creators of these alternate namespaces have simply 116 chosen a convenient / descriptive string and started using this. 117 These new strings are "alternate" strings, and not actually 118 registered anywhere or part of the DNS. However they appear to be 119 TLDs, as they are the in the right-most position of a name. Issues 120 may arise if they are looked up in the DNS. These include: 122 o User confusion: If someone emails a link of the form foo.bar 123 .pseudo-TLD to someone who does not have the necessary software to 124 resolve names in the pseudo-TLD namespace, they may become 125 confused. 127 o Excess traffic hitting the DNS root. Lookups may leak out of the 128 pseudo-TLD namespace and end up hitting the DNS root nameservers. 130 o Collisions: If the pseudo-TLD is eventually delegated from the 131 root zone the behavior may be non-deterministic. 133 o Lack of success for the user's original goal. 135 A significant number of these alternate name resolution systems are 136 specifically designed to provide confidentiality of the looked up 137 name, and provide a distributed and censorship resistant namespace. 138 For example, the Tor project use of .onion is intended to provide a 139 confidential and alternate name resolution process. This goal may be 140 defeated if the queries leak into the DNS, for example if a Tor user 141 shares a link with a friend who isnt using the Tor browser. 143 3. The ALT namespace 145 In order to avoid the above issues we reserve the .ALT label. This 146 label should be used as a pseudo-TLD (in the right most (TLD) 147 position of a name) to signify that this is an alternate (non-DNS) 148 namespace. 150 Alternate namespaces should differentiate themselves from other 151 alternate namespaces by choosing a name and using it in the label 152 position just before the pseudo-TLD. For example, a group wishing 153 create a namespace for Friends Of Olaf they may choose the string 154 "foo" and use any set of labels under foo.alt. 156 As they are in an alternate namespace they have no significance in 157 the regular DNS context and so should not be looked up in the DNS 158 context. Unfortunately simply saying that "something should not 159 happen" doesn't actually stop it from happening, so we need some 160 rules to deal with these. 162 1. Stub resolvers MAY elect not to send queries to any upstream 163 resolver for names in the ALT TLD. 165 2. Iterative resolvers SHOULD follow the advice in [RFC6303], 166 Section 3. 168 3. The root zone nameservers should either return NXDOMAIN 169 responses, or the ALT TLD should be delegated to "new style" 170 AS112 nameservers. 172 Groups wishing to create alternate namespaces SHOULD create their 173 alternate namespace "under" a label that names their namespace, and 174 "under" the ALT label. They SHOULD choose a label that they expect 175 to be unique / descriptive. As there is no registry for the ALT 176 namespace uniqueness is not guaranteed. 178 Currently deployed projects and protocols that are using pseudo-TLDs 179 (for example, the ".onion" pseudo-TLD (and other labels in 180 [I-D.grothoff-iesg-special-use-p2p-names]) are not expected to move 181 under the ALT TLD (but may do so if they wish; this is a common 182 resource). Rather, the ALT TLD is being reserved so that future 183 projects of a similar nature have a designated place to create 184 alternate resolution namespaces that will not conflict with the 185 regular DNS context. 187 A number of names other than .ALT were considered and discarded. In 188 order for this technique to be effective the names need to continue 189 to followed the DNS format (a prime consideration for alternate name 190 formats be that they can be entered in places that normally take DNS 191 context names), this rules out using suffixes that are not themselves 192 DNS labels. Another proposal was that the ALT TLD instead be a 193 reservation under .arpa. This was considered, but rejected because 194 of we are suggesting that this be served as an [RFC6303] and that 195 recursive operators configure themselves to serve empty authoritative 196 zones for the reserved labeled. There is a concern that if there 197 were placed under .arpa less experienced nameserver operators may 198 inadvertently cover .arpa. A more significant concern is that the 199 scope of the issue if the query does leak, and the fact that this 200 would then make the root of the alternate naming namespace a third 201 level domain, and not a second one. A project may be willing to have 202 a name of the form example.alt, but example.alt.arpa may be not look 203 as good [TODO: Better wording here. Don't want to say "vanity" ! ] 205 4. Advice to developers 207 An option would be for name resolution systems that operate outside 208 to DNS to "root" themselves under a DNS name that the project or 209 organization controls. So, for example if the Tor project controls 210 tor.example.com it could "root" their namespace under 211 onion.tor.example.com. The concept of "rooting" a non-DNS context in 212 a DNS context requires some explanation. This document tries to 213 mitigate collisions in the DNS context. This means that if a name 214 from the alternate naming system gets resolved in the DNS, it should 215 not conflict or cause unexpected behavior. By "rooting a non-DNS 216 context namespace in the DNS context, under a name controlled by the 217 project" we mean that the rightmost set of labels should, if resolved 218 in the DNS context be in a domain controlled by the developers / 219 project. This means that, in the above example the software 220 implementing the alternate namespace (browser plugins, custom stub 221 resolvers, etc) would then match on names that end in the string 222 "onion.example.com" and provide the alternate name resolution 223 (instead of matching on the strings ending in ".onion".) 225 In a number of cases the purpose of the alternate name resolution 226 system is to provide confidentiality. For these systems the above 227 advice is problematic. If the a query for one of these names (for 228 example dissident.onion.example.com (this is not a real .onion 229 address)) were to leak into the DNS the query would hit the recursive 230 resolver, and (assuming empty caches) would then hit the root, the 231 .com name servers, the example.com name servers and then the 232 onion.example.com nameservers. This means that the fact that a user 233 is resolving disident.onion.example.com would be visible to a large 234 number of people. Furthermore, the onion.example.com nameservers 235 become a good oracle to determine what names exist, and who is trying 236 to reach them. 238 For projects that are very latency sensitive, or which desire to 239 provide confidentiality we recommend rooting the alternate namespace 240 under the .ALT TLD. 242 5. IANA Considerations 244 The IANA is requested to add the ALT string to the "Special-Use 245 Domain Name" registry ([RFC6761], and reference this document. In 246 addition, the "Locally Served DNS Zones" ([RFC6303]) registry should 247 be updated to reference this document. 249 6. Security Considerations 251 One of the motivations for the creation of the alt pseudo-TLD is that 252 unmanaged labels in the managed root name space are subject to 253 unexpected takeover if the manager of the root name space decides to 254 delegate the unmanaged label. 256 The unmanaged and registry-free nature of labels beneath .ALT 257 provides the opportunity for an attacker to re-use the chosen label 258 and thereby possibly compromise applications dependent on the special 259 host name. 261 7. Acknowledgements 263 The authors understand that there is much politics surrounding the 264 delegation of a new TLD and thank the ICANN liaison (and any other 265 poor sod who gets sucked into this) in advance. 267 8. References 269 8.1. Normative References 271 [I-D.grothoff-iesg-special-use-p2p-names] 272 Grothoff, C., Wachs, M., hellekin, h., and J. Appelbaum, 273 "Special-Use Domain Names of Peer-to-Peer Systems", draft- 274 grothoff-iesg-special-use-p2p-names-02 (work in progress), 275 March 2014. 277 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 278 STD 13, RFC 1034, November 1987. 280 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 281 Requirement Levels", BCP 14, RFC 2119, March 1997. 283 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 284 6303, July 2011. 286 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 287 RFC 6761, February 2013. 289 8.2. Informative References 291 [I-D.ietf-sidr-iana-objects] 292 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 293 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 294 progress), May 2011. 296 Appendix A. Changes / Author Notes. 298 [RFC Editor: Please remove this section before publication ] 300 From -01 to -02 302 o Removed some fluffy wording, tightened up the language some. 304 From -00 to -01. 306 o Fixed the abstract. 308 o Recommended that folk root their non-DNS namespace under a DNS 309 namespace that they control (Joe Abley) 311 Authors' Addresses 313 Warren Kumari 314 Google 315 1600 Amphitheatre Parkway 316 Mountain View, CA 94043 317 US 319 Email: warren@kumari.net 321 Andrew Sullivan 322 Dyn 323 150 Dow Street 324 Manchester, NH 03101 325 US 327 Email: asullivan@dyn.com