idnits 2.17.1 draft-sullivan-dns-class-useless-03.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. -- The draft header indicates that this document updates RFC6895, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 8, 2016) is 2849 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 1883 (Obsoleted by RFC 2460) -- Obsolete informational reference (is this intentional?): RFC 1886 (Obsoleted by RFC 3596) -- Obsolete informational reference (is this intentional?): RFC 5205 (Obsoleted by RFC 8005) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IETF A. Sullivan 3 Internet-Draft Dyn, Inc. 4 Updates: 6895 (if approved) July 8, 2016 5 Intended status: Best Current Practice 6 Expires: January 9, 2017 8 The DNS Is Not Classy: DNS Classes Considered Useless 9 draft-sullivan-dns-class-useless-03 11 Abstract 13 Domain Name System Resource Records are identified in part by their 14 class. The class field is not effective, and it is not used the way 15 it appears to have been intended. This memo suspends additions to 16 the DNS class registry pending greater clarity on how classes might 17 be used, and until such clarification requires those defining new 18 RRTYPEs to define them for all classes. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on January 9, 2017. 37 Copyright Notice 39 Copyright (c) 2016 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Classes in the Domain Name System . . . . . . . . . . . . . . 2 55 2. Why classes are not as useful as they might be . . . . . . . 3 56 2.1. Matching rules are class-independent . . . . . . . . . . 3 57 2.1.1. Really parallel trees . . . . . . . . . . . . . . . . 4 58 2.2. Not all RRTYPEs are careful about class . . . . . . . . . 5 59 2.3. The DNS RRTYPE registry and meaning . . . . . . . . . . . 6 60 2.4. A new class requires new delegations . . . . . . . . . . 6 61 3. DNS classes are effectively vestigial . . . . . . . . . . . . 7 62 4. New RRTYPEs are for all classes . . . . . . . . . . . . . . . 7 63 5. Security considerations . . . . . . . . . . . . . . . . . . . 7 64 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 65 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 8 68 8.2. Informative References . . . . . . . . . . . . . . . . . 8 69 Appendix A. Discussion Venue . . . . . . . . . . . . . . . . . . 9 70 Appendix B. Change History . . . . . . . . . . . . . . . . . . . 9 71 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 10 73 1. Classes in the Domain Name System 75 The Domain Name System (DNS) [RFC1034] [RFC1035] includes two types 76 of division: one by class, and one by "cuts". As [RFC1034] says, 78 The database for any class is organized, delegated, and maintained 79 separately from all other classes. Since, by convention, the name 80 spaces are the same for all classes, the separate classes can be 81 thought of as an array of parallel namespace trees. Note that the 82 data attached to nodes will be different for these different 83 parallel classes. The most common reasons for creating a new 84 class are the necessity for a new data format for existing types 85 or a desire for a separately managed version of the existing name 86 space. 88 As of this writing, there are only three "ordinary" classes assigned. 89 Class 1 is the Internet or IN class. Class 3 is the Chaos or CH 90 class. Class 4 is the Hesiod or HS class. Class 2 is noted in 91 [RFC1035] as the CSNET or CS class, but the current registry (at 92 ) no longer includes the assignment. 95 There are two other assigned classes; these have special purposes. 96 Class 255, ANY or *, matches any class [RFC1035]. Class 254, NONE, 97 is used in [RFC2136] to specify certain kinds of operations on 98 RRsets. 100 Of the ordinary classes, only IN is found in common use on the 101 Internet today. Class CH is now sometimes used to carry certain 102 kinds of name server metadata. It seems new classes might have been 103 useful for a number of features that have been delivered in some 104 other way. Yet classes have not been used, which might suggest that 105 classes are less useful than they otherwise appear to be. (It is 106 also worth observing that classes divide the database, and not the 107 namespace itself. In other words, classes are part of the 108 implementation of the DNS and not a natural feature of domain names 109 as such.) In some ways, the motivations for classes are made clearer 110 by reading [RFC0882] along with the other DNS specifications. 112 Nevertheless, from time to time someone comes up with a suggestion 113 for why a new class would solve some problem or other. The purpose 114 of this memo is to offer some considerations for those contemplating 115 such innovation. 117 2. Why classes are not as useful as they might be 119 There are four (or, depending on how one counts, five) problems that 120 make classes less useful than they might be. First, the rules for 121 name matching are independent of the class. Second, specification of 122 resource record types has not always attended to the handling of 123 types across classes; this makes new classes of (at best) uncertain 124 utility. Third, the DNS RRTYPE registry does not have a way of 125 indicating significant differences in meaning for the same type among 126 different classes. 128 Apart from those technical problems, there is an administrative 129 problem. The Internet name space starts from a common root, which 130 means that any resolver needs to start from the same bootstrap 131 mechanism no matter what classes it uses. But in order for that to 132 work, any new class would need to be delegated from the existing root 133 name servers, or else a new set of policies about how to select the 134 alternative roots would be required. A wrinkle (or possibly a 135 separate problem) is that some possible uses of classes appear not 136 really to require a shared global root. (For instance, it is not 137 clear that Hesiod names really needed to be part of the global 138 namespace.) 140 2.1. Matching rules are class-independent 142 As noted in Section 1, classes are intended to divide the DNS into 143 separate trees. The class field does not, however, affect the 144 matching rules for names, so as a practical matter the namespace is 145 primary. 147 The issue is made plain by considering the matching algorithm for 148 name servers, described in [RFC1034] section 4.3.2. Suppose there 149 are two (imaginary) classes, EG and IE. Imagine, further, that the 150 same name has different RDATA in each class: 152 example.com EG CNAME example.net 154 example.com IE CNAME example.org 156 In principle, the above should work because, as noted in Section 1, 157 each class is supposed to be "delegated separately". Therefore, when 158 the name server for example.com in class EG receives the query for 159 example.com, it already knows which class database to search; 160 similarly for example.com in class IE. 162 Yet while the class delegations are defined to be separate, there is 163 no way to ensure that the NS record RDATA for example.com in class 164 IE, and the NS record RDATA for example.com in class EG, are always 165 different. Indeed, if the different classes of name space are truly 166 managed separately, but the name space is by convention parallel, it 167 would not be surprising that some name server ended up authoritative 168 for the same name in different classes. In [RFC1034], section 3.6.1, 169 there is an example that appears to contain two classes from the same 170 master file and for the same name. This illustrates the principle 171 that the same name server could be authoritative for the same name in 172 different classes. Note that the example might be a mistake, since 173 according to [RFC1035], section 5.2, all entries in a master file for 174 a zone should have the same class. In any case, it is plain that the 175 name is primary, and having matched the name one can then select data 176 according to the class. But this means that the matching rules for 177 names cannot differ across classes, and that makes classes less 178 useful for extending DNS capabilities than they might at first seem. 180 Once one describes the resolution pattern this way, and given that 181 the IN class is so widely used and other classes so rarely, it is not 182 too surprising that some naive implementations simply assume IN for 183 every resource record. That assumption, of course, makes the class 184 division in the DNS again less useful. 186 2.1.1. Really parallel trees 188 It appears that the notion of "parallel namespace trees" is stronger 189 than one might have hoped if one wanted to use classes to do 190 something new in the DNS. When one considers how classes are treated 191 in [RFC1034] and [RFC1035] and their predecessors, that parallelism 192 becomes less surprising. The examples are all of alternative 193 networking systems to the Internet. Moreover, [RFC1034] says, 194 "Because we want the name space to be useful in dissimilar networks 195 and applications, we provide the ability to use the same name space 196 with different protocol families or management." 198 If one thinks of classes as simply the way to resolve the same name 199 depending on which sort of networking technology is being used, a 200 strong expectation of completely parallel trees is not surprising. 201 Indeed, in an environment of many different networking and 202 internetworking technologies, it would have been surprising if, when 203 one changed network technologies, a name referred to a completely 204 different target system. At the same time, parallel namespace trees 205 are not formally required. 207 Since the time when the DNS was defined, Internet technology has 208 largely won out over other network technologies. In addition, the 209 last time a fundamentally new networking technology was introduced to 210 the Internet (with IPv6 in [RFC1883]), the designers treated it as 211 just another part of the IN class (and introduced the AAAA record, in 212 [RFC1886]). So, the reason for the class field in the first place 213 has withered away; and, when the opportunity came to use classes in 214 their originally intended way, the designers of the technology 215 decided not to use them. 217 2.2. Not all RRTYPEs are careful about class 219 RRTYPEs can either be class-independent, or else they can return very 220 different data depending on the class in question. Not every RRTYPE 221 specification is clear about its definition under various classes. 222 For instance, the original specification of type 55, HIP, appears not 223 to state the class(es) for which it is defined [RFC5205]. The 224 specification of LOC, type 29 (in [RFC1876]), says that the type is 225 defined for classes other than IN, but also says, "The semantics of 226 such use are not defined by this memo." 228 One might argue that this issue is resolved by [RFC3597], because it 229 specifies that an unknown class and type combination is to be handled 230 as unknown. Formally, of course, that means that every type can be 231 handled regardless of class. But it would appear to reduce the 232 utility of classes yet further, by increasing the probability that 233 many RRs in every class except IN will be treated as unknown. For 234 the purposes of resolution, that might not matter. But 235 administrators and users will be reluctant to embrace a class that 236 does not have good input and validation tools -- a problem that 237 already vexes adoption of new RRTYPEs in class IN. 239 2.3. The DNS RRTYPE registry and meaning 241 Some RRTYPEs are defined in a class-dependent way. For instance, the 242 A record (type 1) is defined in [RFC1035] to be for class IN only. 243 In [RFC1034], section 3.6, the A record is also defined for class CH. 244 Perhaps unfortunately, the IANA registry for RRTYPEs (at 245 ) does not include an indicator for 247 the class(es) in which the RRTYPE is defined. 249 It appears, therefore, that the "meaning" field of an RRTYPE 250 definition is required to be class-independant, even though the RDATA 251 for a given type may vary dramatically. For instance, in the case of 252 the A record the RDATA is either a 32-bit IPv4 address or else a 253 domain name and a 16-bit octal address. Across classes, even the 254 number of fields may differ for the same type. 256 This appears to be yet more evidence for the "strict parallelism" 257 explanation in Section 2.1.1. At the same time, [RFC1034] is not 258 perfectly clear that a data type must have the same meaning in every 259 class, and [RFC6895] does not contain clear instructions on the 260 topic. Moreover, given the vastly different RDATA allowable for the 261 same type across classes it is hard to be certain what is entailed by 262 says that they all "have the same meaning", unless there is a strict 263 requirement that a class only ever differs based on the underlying 264 network technology. 266 Therefore, if classes were to be used for purposes other than 267 alternative low-level network technologies, the RRTYPE registry ought 268 to be altered to indicate the meaning of a type in each class for 269 which the type is defined. Such an alteration appears to be of 270 questionable value given the overwhelming dominance of the IN class. 272 2.4. A new class requires new delegations 274 The Internet's DNS system is part of the common name space of the 275 Internet, and that common name space starts from a common root (see 276 [RFC2826] for the arguments about why this must be true). In order 277 to provide for the resolution of a new class, the root name servers 278 would need to respond to resolution requests for that class and 279 provide the delegation data. Current policies about domain name 280 delegation in the root zone appear to apply to the IN class, and it 281 is not clear where responsibility would lie for the policies about a 282 new class. At the very least, a new policy of this sort would need 283 to be worked out for any use where a class had truly global scope. 285 Alternatively, it is possible to imagine resolvers using a different 286 set of root servers for different classes of query. Such a solution 287 merely moves the policy problem around, for it would be necessary to 288 develop policies about root server systems for new classes whenever 289 names in some class need to be resolvable in a globally-unambiguous 290 way. 292 3. DNS classes are effectively vestigial 294 Given the considerations above, it is far from obvious that DNS 295 classes are likely to be useful in the future. At the very least, in 296 order that they could become useful, a number of clarifications to 297 the DNS protocol and operation specifications would be necessary. 299 In the interests of encouraging interoperation, therefore, additions 300 to the DNS CLASS registry (at ) are suspended 302 until such clarifications are forthcoming. New class definitions 303 henceforth will require standards action. 305 Designers of new name systems should consider the design of classes 306 in the DNS. If a similar feature is desirable, its design needs to 307 be at least clearer and possibly different in order to be useful. 308 Given the the way the DNS has managed to thrive without really using 309 classes, however, it would be worth asking whether the feature is 310 useful at all. 312 4. New RRTYPEs are for all classes 314 As long as the DNS CLASS registry suspension is in effect, new RRTYPE 315 allocations are required to be defined in a class-independent way. 317 5. Security considerations 319 This memo creates no new security issues. It might be argued that it 320 could in principle reduce security issues by eliminating a potential 321 source for confusion on the Internet, but classes are so little used 322 that there is probably no improvement in practice. 324 6. IANA Considerations 326 IANA is hereby requested to update the Domain Name System (DNS) 327 Parameters registry as follows: 329 o Update the DNS CLASSes sub-registry to add a reference to this 330 document. 332 o Update the DNS CLASSes sub-registry Registration Procedures field 333 to "Standards Action" for decimal classes 1-65279 inclusive. 335 o Add this document to the Resource Record (RR) TYPEs sub-registry 336 references. 338 7. Acknowledgements 340 The author appreciates comments and observations from Mark Andrews, 341 Rob Austein, Ray Bellis, Stephane Bortzmeyer, Avri Doria, John 342 Klensin, Shane Kerr, Warren Kumari, Ed Lewis, Mukund Sivaraman, Paul 343 Vixie, and Lixia Zhang. 345 8. References 347 8.1. Normative References 349 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 350 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 351 April 2013, . 353 8.2. Informative References 355 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 356 RFC 882, DOI 10.17487/RFC0882, November 1983, 357 . 359 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 360 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 361 . 363 [RFC1035] Mockapetris, P., "Domain names - implementation and 364 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 365 November 1987, . 367 [RFC1876] Davis, C., Vixie, P., Goodwin, T., and I. Dickinson, "A 368 Means for Expressing Location Information in the Domain 369 Name System", RFC 1876, DOI 10.17487/RFC1876, January 370 1996, . 372 [RFC1883] Deering, S. and R. Hinden, "Internet Protocol, Version 6 373 (IPv6) Specification", RFC 1883, DOI 10.17487/RFC1883, 374 December 1995, . 376 [RFC1886] Thomson, S. and C. Huitema, "DNS Extensions to support IP 377 version 6", RFC 1886, DOI 10.17487/RFC1886, December 1995, 378 . 380 [RFC2136] Vixie, P., Ed., Thomson, S., Rekhter, Y., and J. Bound, 381 "Dynamic Updates in the Domain Name System (DNS UPDATE)", 382 RFC 2136, DOI 10.17487/RFC2136, April 1997, 383 . 385 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the 386 Unique DNS Root", RFC 2826, DOI 10.17487/RFC2826, May 387 2000, . 389 [RFC3597] Gustafsson, A., "Handling of Unknown DNS Resource Record 390 (RR) Types", RFC 3597, DOI 10.17487/RFC3597, September 391 2003, . 393 [RFC5205] Nikander, P. and J. Laganier, "Host Identity Protocol 394 (HIP) Domain Name System (DNS) Extensions", RFC 5205, 395 DOI 10.17487/RFC5205, April 2008, 396 . 398 Appendix A. Discussion Venue 400 This Internet-Draft is discussed on the IAB Internet Names and 401 Identifiers Program public list: inip-discuss@iab.org. 403 Appendix B. Change History 405 Note to RFC Editor: this section should be removed prior to 406 publication as an RFC. 408 00: 410 * Initial version 412 01: 414 * Clarify the distinction between database and domain names as 415 such 417 * Address question of closing registry 419 * Minor fixes of text 421 02: 423 * Eliminate argument from class position in message 425 * Sharpen argument from primacy of matching rules 427 * Note network-technology history of class. 429 * Change to status: update 6895 and close class registry 431 03: 433 * Incorporate feedback from DNSOP meeting at IETF 95 435 * Step back from closing registry: "suspend" registration until 436 the specification is clearer about how classes work 438 * Call for clarification of classes 440 Author's Address 442 Andrew Sullivan 443 Dyn, Inc. 444 150 Dow St 445 Manchester, NH 03101 446 U.S.A. 448 Email: asullivan@dyn.com