idnits 2.17.1 draft-sullivan-draft-sullivan-namespaces-and-dns-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 14, 2014) is 3717 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Sullivan 3 Internet-Draft Dyn 4 Intended status: Informational February 14, 2014 5 Expires: August 18, 2014 7 By Any Other Name: Considerations on DNS, Other Naming Protocols, and 8 the Hierarchical Domain Name Space 9 draft-sullivan-draft-sullivan-namespaces-and-dns-00 11 Abstract 13 You should probably not read this. It's not done. 15 Not every domain name is intended to appear in the global DNS. It is 16 also possible that not everything that looks like a domain name is 17 intended to be one. Regardless of whether a given name is intended 18 to appear in the DNS, such names often turn up in domain name slots. 19 When choosing a naming scheme that is not intended to be part of the 20 global DNS, it is necessary to understand the architectural 21 implications of using domain names or a domain-name-like syntax. 23 Status of This Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on August 18, 2014. 40 Copyright Notice 42 Copyright (c) 2014 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 58 2. PseudoTLDs, Real Names . . . . . . . . . . . . . . . . . . . 3 59 3. Is a Common Namespace a Good Idea? . . . . . . . . . . . . . 4 60 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 62 6. Informative References . . . . . . . . . . . . . . . . . . . 5 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 65 1. Introduction 67 Not every domain name appears in the global DNS, and many domain 68 names are not intended for use in the global DNS. At the very least, 69 as [RFC6590] acknowledges, it is only pragmatic to recognize the 70 existence of split-horizon DNS deployments; these often include so- 71 called "private names". 73 At the same time, as [RFC2826] is at pains to say, the global DNS 74 requires a globally unique public name space. This means that the 75 set of labels near the root of the tree need to be shared by 76 everyone, or the root itself becomes suspect. Private namespaces are 77 fine, but not if they conflict with the public namespace. 79 Some recent developments have revealed the deep tension in this 80 approach to the namespace. Three factors in particular seem to be 81 important. 83 First, while historically the DNS root zone was mostly stable and 84 changed quite slowly when it did change, the decision to expand the 85 root zone dramatically does away with that historic stability. More 86 than a thousand new TLDs are expected in the root zone as of this 87 writing. In some cases, the changes make old assumptions about what 88 is or is not a top-level domain obsolete; but in any case, the new 89 root zone management policy makes keeping static lists of TLDs even 90 worse than it used to be. 92 Second, the arrival of IDNA in the root zone means that protocols 93 that rely on plain UTF-8 labels in the DNS may lead to ambiguous 94 results, if the IDNA version of a zone and the "raw UTF-8" version of 95 a zone become somehow unsynchronized. While from the DNS point of 96 view, these zones are unrelated to one another, from any user's point 97 of view the zones should be the same thing. 99 Finally, and perhaps most importantly, a number of protocols have 100 emerged that use either domain names, or else strings that appear to 101 be just like domain names in most contexts, without relying on the 102 public DNS. (There is an argument to be made that in at least some 103 cases these names are not domain names, because they do not actually 104 have the same restrictions. They may not, for example, restrict 105 length to 63 octets per label. For the purposes of the present 106 discussion, this distinction makes no difference.) For the present 107 purpose, the most interesting of these cases are the ones which use 108 so-called pseudo-top-level-domains (pseudoTLDs) to call out that a 109 namespace has been shifted out of the DNS space and into some other 110 protocol. 112 These different threads suggest that some careful thinking about name 113 spaces is in order. This text, alas, is not that; indeed, at the 114 moment it's little more than a jumble of ill-organized thoughts 115 around this topic, and groping towards some coherence. But I hope to 116 initiate some thoughts about whether domain names, and the domain 117 name system, provide the right foundation for future name space use. 119 2. PseudoTLDs, Real Names 121 The idea of a pseudoTLD is fetching. With such a top level domain 122 (TLD), one uses the right-most label of a domain name as a sort of 123 protocol shifter, to indicate that while the namespace is still the 124 same domain name space, the name is not to be looked up in the DNS. 125 This strategy is not novel. For instance, Multicast DNS [RFC6762] 126 uses the "local" TLD as such an indicator. Prior to the registration 127 of local as a Special-Use Domain Name [RFC6761], local was a 128 pseudoTLD. 130 In the era of a dynamic DNS root zone, the idea that pseudoTLDs can 131 be used safely without co-ordination with the public root zone is a 132 delusion. If a given pseudo use for a TLD takes off, it seems likely 133 that there will be commercial pressures in favour of registration of 134 the pseudoTLD in the root zone (i.e. as a "real" TLD) in an effort to 135 gain automatic traffic. At the same time, some of the pseudoTLDs 136 appear to be attempts to undermine the operation of the existing root 137 either with alternative resolution systems riding atop the DNS 138 (sometimes with claims about additional security or privacy as a 139 concomitant benefit). 141 None of the issues with pseudoTLDs would matter, except that the 142 expansion of the root zone has itself been fraught with political 143 disagreements, and disputes about the costs of registrations. There 144 have also been the sorts of commercial tensions apparent whenever a 145 scarce resource is divided up by commercial means. 147 At least some of the pseudoTLDs could as easily be accommodated in a 148 tree elsewhere in the DNS. These cases would still be candidates for 149 the Special-Use Domain Name registration; it is not clear why these 150 cases need a top-level domain. This issue may be a red herring, 151 however. 153 3. Is a Common Namespace a Good Idea? 155 The basic issue that we are facing is not collisions with the DNS 156 root namespace. It is obvious that we could reserve chunks of the 157 DNS namespace for private use in exactly the way number spaces do 158 this (e.g., [RFC6890]). The deeper architectural question is why, if 159 there is such desire to do away with the limitations of the DNS, such 160 systems start from the premise that the DNS and its namespace are the 161 right foundation. Oddly, the design of the DNS would appear to 162 suggest another approach. 164 Conceptually [RFC1034], the DNS name space is divided up not only by 165 name, but also by class. As a practical matter, on the Internet only 166 the IN class is used. But in principle, the DNS design permits a 167 given namespace to be classed such that the same name could have 168 completely different RDATA at every owner name, for the same RRTYPE, 169 in each of two different classes. 171 Unfortunately, because of the way CNAME is defined, the DNS classes 172 do not really work. CNAME processing does not restart the processing 173 of a given name in a given class, but rather restarts the processing 174 of a name alone. For that reason, two DNS classes are not really 175 completely separate name spaces. 177 The resort to a pseudoTLD as a kind of shift bit to indicate a new 178 resolution protocol signifies that what is really wanted is a new 179 resolution class. We have been down this road before. The use of 180 so-called underscore labels in DNS names as a mechanism for 181 subdividing space under a TXT RRTYPE was in effect an attempt to lift 182 the burden of deploying a new RRTYPE. In that case, however, the 183 desire was to publish data in the existing global DNS, without the 184 hassle of making the global DNS work the way it was supposed to (by 185 making it easy to deploy new RRTYPEs). 187 The present case, of alternative name resolution systems, is 188 different. In this case, new resolution libraries all use the 189 pseudoTLD as a trigger to spring into action. The pseudoTLD isn't 190 there for compatibility with the DNS; some proposals are in fact 191 inimical to the DNS. Instead, the DNS name space pattern is used 192 because it is familiar. This seems a poor reason to use an old- 193 fashioned naming system that does not even support its own entire 194 feature set. And the fact that the pseudoTLDs are a flag that new 195 resolution systems need to be used suggests that in fact new code to 196 be deployed across systems is acceptable in these cases. If true, 197 that means that the traditional argument in favour of retaining the 198 DNS -- its existing universal deployment -- is lost. After all, if 199 the new naming system does not work except for those who have 200 installed the new system, what reason is there to saddle the new 201 system with the compromises (and long, crufty history) of the DNS? 203 The above suggests that a better goal would be to undertake the 204 design of an improved naming system, incorporating lessons from the 205 DNS as well as ideas from the new naming technologies and proposal. 207 4. IANA Considerations 209 This memo makes no requests of IANA. 211 5. Security Considerations 213 The security implications of the foregoing are as yet unknown. 215 6. Informative References 217 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 218 STD 13, RFC 1034, November 1987. 220 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 221 Unique DNS Root", RFC 2826, May 2000. 223 [RFC6590] Falk, J. and M. Kucherawy, "Redaction of Potentially 224 Sensitive Data from Mail Abuse Reports", RFC 6590, April 225 2012. 227 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 228 RFC 6761, February 2013. 230 [RFC6762] Cheshire, S. and M. Krochmal, "Multicast DNS", RFC 6762, 231 February 2013. 233 [RFC6890] Cotton, M., Vegoda, L., Bonica, R., and B. Haberman, 234 "Special-Purpose IP Address Registries", BCP 153, RFC 235 6890, April 2013. 237 Author's Address 239 Andrew Sullivan 240 Dyn 241 150 Dow St. 242 Manchester, NH 03101 243 U.S.A. 245 Email: asullivan@dyn.com