idnits 2.17.1 draft-wkumari-dnsop-alt-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: ---------------------------------------------------------------------------- No issues found here. 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 (February 10, 2014) is 3718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.hoff-iesg-special-use-p2p-names' is mentioned on line 105, but not defined == Unused Reference: 'I-D.ietf-sidr-iana-objects' is defined on line 245, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-grothoff-iesg-special-use-p2p-names-01 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: August 14, 2014 Dyn 6 February 10, 2014 8 The ALT Special Use Top Level Domain 9 draft-wkumari-dnsop-alt-tld-00 11 Abstract 13 This document reserves a string to be used as a TLD label in non-DNS 14 contexts. [Ed note: By now you should be wildly confused. Go read 15 the intro / background :-P ] 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 August 14, 2014. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 3. The ALT namespace . . . . . . . . . . . . . . . . . . . . . . 3 56 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 61 7.2. Informative References . . . . . . . . . . . . . . . . . 6 62 Appendix A. Changes / Author Notes. . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Lots of protocols and systems need to name entities, and the DNS 68 "standard" of a series of labels separated with dots has become 69 common, even in systems that are not actually part of the DNS. 71 This document reserves the string "ALT" (short for Alternate) as a 72 Special Use Domain ([RFC6761]) that should be used in the right-most 73 label position to signify that this name is not rooted in the DNS, 74 and that normal registration and lookup rules do not apply. 76 1.1. Requirements notation 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [RFC2119]. 82 1.2. Terminology 84 This document assumes familiarity with DNS terms and concepts. 85 Please see [RFC1034] for background and concepts. 87 o DNS context: The namespace administered by ICANN. This is the 88 namespace / context that "normal" DNS uses. 90 o non-DNS context: Any other / alternate namespace. 92 2. Background 94 The DNS is a tree, and so has a single root. Conventionally, a name 95 immediately beneath the root is called a "Top Level Domain" or "TLD". 96 TLDs usually delegate portions of their namespace to others, who may 97 then delegate further. The hierarchical, distributed, caching nature 98 of the DNS has made it the primary resolution system on the Internet. 100 The success of the DNS means makes it a natural starting point for 101 systems that need to name entities in a non-DNS context. These name 102 resolutions occur in a namespace distinct from the DNS. A number of 103 good examples of these sorts of systems are documented in Special-Use 104 Domain Names of Peer-to-Peer Systems 105 [I-D.hoff-iesg-special-use-p2p-names] 107 In many cases, these systems build a DNS style tree parallel to the 108 global DNS administered by IANA. They often use a pseudo-TLD to 109 cause resolution in this alternate namespace, using things like 110 browser plugins, shims in the name resolution process, or simply 111 applications only use this alternate namespace. 113 In many cases the creators of these alternate namespaces have simply 114 chosen a convenient / descriptive string and started using this. 115 These new strings are "alternate" strings, and not actually 116 registered anywhere or part of the DNS. However they appear to be 117 TLDs, as they are the in the right-most position of a name. Issues 118 may arise if they are looked up in the DNS. These include: 120 o User confusion: If someone emails a link of the form foo.bar 121 .pseudo-TLD to someone who does not have the necessary software to 122 resolve names in the pseudo-TLD namespace, they may become 123 confused. 125 o Excess traffic hitting the DNS root. Lookups may leak out of the 126 pseudo-TLD namespace and end up hitting the DNS root nameservers. 128 o Collisions. If the pseudo-TLD is eventually delegated from the 129 root zone the behavior may be non-deterministic. 131 o Lack of success for the user's original goal. 133 3. The ALT namespace 135 In order to avoid the above issues we reserve the .ALT label. This 136 label should be used as a pseudo-TLD (in the right most (TLD) 137 position of a name) to signify that this is an alternate (non-DNS) 138 namespace. 140 Alternate namespaces should differentiate themselves from other 141 alternate namespaces by choosing a name and using it in the label 142 position just before the pseudo-TLD. For example, a group wishing 143 create a namespace for [TODO(?): Need something better] Friends Of 144 Olaf they may choose the string "foo" and use any set of labels under 145 foo.alt. 147 As they are in an alternate namespace they have no significance in 148 the regular DNS context and so should not be looked up in the DNS 149 context. Unfortunately simply saying that "something should not 150 happen" doesn't actually stop it from happening, so we need some 151 rules to deal with these. 153 1. Stub resolvers MAY elect not to send queries to any upstream 154 resolver for names in the ALT TLD. 156 2. Iterative resolvers SHOULD follow the advice in [RFC6303], 157 Section 3. 159 3. The root zone nameservers should either return NXDOMAIN 160 responses, or the ALT TLD should be delegated to "new style" 161 AS112 nameservers. (TODO(WK): WK, JA, BD to revive AS112 / 162 AS112-bis). 164 Groups wishing to create alternate namespaces SHOULD create their 165 alternate namespace "under" a label that names their namespace, and 166 "under" the ALT label. They SHOULD choose a label that they expect 167 to be unique / descriptive. As there is no registry for the ALT 168 namespace uniqueness is not guaranteed. 170 Currently deployed projects and protocols that are using pseudo-TLDs 171 (for example, the ".onion" pseudo-TLD (and other labels in 172 [I-D.grothoff-iesg-special-use-p2p-names]) are not expected to move 173 under the ALT TLD (but may do so if they wish; this is a common 174 resource). Rather, the ALT TLD is being reserved so that future 175 projects of a similar nature have a designated place to create 176 alternate resolution namespaces that will not conflict with the 177 regular DNS context. 179 4. IANA Considerations 181 The IANA is requested to add the ALT string to the "Special-Use 182 Domain Name" registry ([RFC6761], and reference this document. In 183 addition, the "Locally Served DNS Zones" ([RFC6303]) registry should 184 be updated to reference this document. 186 [ Ed: There are two options here. Option 1: We could ask the IANA to 187 run a "First Come First Served" registry for labels under the ALT 188 TLD. By registry I mean a "standard" IANA registry, not a registry 189 in the DNS sense of the word (IANA would publish on a webpage "Foo | 190 fred@example.com | Used for the foo project"). Option 2: This is a 191 fully uncoordinated space (in the same way that people have been 192 picking pseudo-TLDs up till now) -- pick something that, as far as 193 you know other's are not using... There are pros and cons to both -- 194 I don't want to overload the IANA, have people stage a land-grab for 195 names, or give the impression that this is a "real" TLD. Thoughts? 196 Currently we say there is no registry (Section 3), but that can be 197 changed.)] 199 5. Security Considerations 201 One of the motivators for the creation of the alt pseudo-TLD is that 202 unmanaged labels in the managed root name space are subject to 203 unexpected takeover if the manager of the root name space decides to 204 delegate the unmanaged label. 206 The unmanaged and registry-free nature of labels beneath .ALT 207 provides the opportunity for an attacker to re-use the chosen label 208 and thereby possibly compromise applications dependent on the special 209 host name. 211 6. Acknowledgements 213 The authors understand that there is much politics surrounding the 214 delegation of a new TLD and thank the ICANN liaison (and any other 215 poor sod who gets sucked into this) in advance. 217 7. References 219 7.1. Normative References 221 [I-D.grothoff-iesg-special-use-p2p-names] 222 Grothoff, C., Wachs, M., hellekin, h., and J. Appelbaum, 223 "Special-Use Domain Names of Peer-to-Peer Systems", draft- 224 grothoff-iesg-special-use-p2p-names-01 (work in progress), 225 December 2013. 227 [IANA.AS_Numbers] 228 IANA, "Autonomous System (AS) Numbers", 229 . 231 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 232 STD 13, RFC 1034, November 1987. 234 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 235 Requirement Levels", BCP 14, RFC 2119, March 1997. 237 [RFC6303] Andrews, M., "Locally Served DNS Zones", BCP 163, RFC 238 6303, July 2011. 240 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 241 RFC 6761, February 2013. 243 7.2. Informative References 245 [I-D.ietf-sidr-iana-objects] 246 Manderson, T., Vegoda, L., and S. Kent, "RPKI Objects 247 issued by IANA", draft-ietf-sidr-iana-objects-03 (work in 248 progress), May 2011. 250 Appendix A. Changes / Author Notes. 252 [RFC Editor: Please remove this section before publication ] 254 From -00 to -01. 256 o Nothing changed in the template! 258 Authors' Addresses 260 Warren Kumari 261 Google 262 1600 Amphitheatre Parkway 263 Mountain View, CA 94043 264 US 266 Email: warren@kumari.net 268 Andrew Sullivan 269 Dyn 270 150 Dow Street 271 Manchester, NH 03101 272 US 274 Email: asullivan@dyn.com