idnits 2.17.1 draft-klensin-dns-function-considerations-05.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 (December 21, 2017) is 2316 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3596' is defined on line 1156, but no explicit reference was found in the text -- No information found for draft-hoffman-simplednsjsonn - is the name correct? -- Obsolete informational reference (is this intentional?): RFC 810 (Obsoleted by RFC 952) -- Obsolete informational reference (is this intentional?): RFC 882 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 883 (Obsoleted by RFC 1034, RFC 1035) -- Obsolete informational reference (is this intentional?): RFC 974 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2671 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 2673 (Obsoleted by RFC 6891) -- Obsolete informational reference (is this intentional?): RFC 3490 (Obsoleted by RFC 5890, RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 3491 (Obsoleted by RFC 5891) -- Obsolete informational reference (is this intentional?): RFC 7706 (Obsoleted by RFC 8806) -- Obsolete informational reference (is this intentional?): RFC 7719 (Obsoleted by RFC 8499) -- Obsolete informational reference (is this intentional?): RFC 7816 (Obsoleted by RFC 9156) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft December 21, 2017 4 Intended status: Informational 5 Expires: June 24, 2018 7 DNS Privacy, Authorization, Special Uses, Encoding, Characters, 8 Matching, and Root Structure: Time for Another Look? 9 draft-klensin-dns-function-considerations-05 11 Abstract 13 The basic design of the Domain Name System was completed almost 30 14 years ago. The last half of that period has been characterized by 15 significant changes in requirements and expectations, some of which 16 either require changes to how the DNS is used or that can be 17 accommodated only poorly or not at all. This document asks the 18 question of whether it is time to either redesign and replace the DNS 19 to match contemporary requirements and expectations (rather than 20 continuing to try to design and implement incremental patches that 21 are not fully satisfactory) or to draw some clear lines about 22 functionality that is not really needed or that should be performed 23 in some other way. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on June 24, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 4 61 3. Warts and Tensions With The Current DNS . . . . . . . . . . . 5 62 3.1. Multi-type Queries . . . . . . . . . . . . . . . . . . . 5 63 3.2. Matching Part I: Case Sensitivity in Labels and Other 64 Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3. Matching Part II: Non-ASCII ("internationalized") Domain 66 Name Labels . . . . . . . . . . . . . . . . . . . . . . . 6 67 3.4. Matching Part III: Label Synonyms, Equivalent Names, and 68 Variants . . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 9 70 3.6. Alternate Name Spaces for Public Use in the DNS 71 Framework: The CLASS Problem . . . . . . . . . . . . . . 9 72 3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 9 73 3.8. Private Name Spaces and Special Names . . . . . . . . . . 10 74 3.9. Alternate Query or Response Encodings . . . . . . . . . . 11 75 3.10. Distribution and Management of Root Servers . . . . . . . 11 76 3.11. Identifiers Versus Brands and Other Convenience Names . . 12 77 3.12. A Single Hierarchy with a Centrally-controlled Root . . . 13 78 3.13. Newer Application Protocols, New Requirements, and DNS 79 Evolution . . . . . . . . . . . . . . . . . . . . . . . . 13 80 3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 14 81 3.13.2. Extensions and Deployment Pressures -- The TXT 82 RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 14 83 3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 15 84 3.14. Scaling of Reputation and Other Ancillary Information . . 16 85 3.15. Tensions among transport, scaling and content . . . . . . 17 86 4. The Inverse Lookup Requirement . . . . . . . . . . . . . . . 18 87 5. Internet Scale, Function Support, and Incremental Deployment 19 88 6. Searching and the DNS - An Historical Note . . . . . . . . . 19 89 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 93 10.1. Normative References . . . . . . . . . . . . . . . . . . 21 94 10.2. Informative References . . . . . . . . . . . . . . . . . 21 95 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 27 96 A.1. Changes from version -00 (2017-06-02) to -01 . . . . . . 28 97 A.2. Changes from version -01 (2017-06-06) to -02 . . . . . . 28 98 A.3. Changes from version -02 (2017-06-19) to -03 . . . . . . 28 99 A.4. Changes from version -03 (2017-06-26) to -04 . . . . . . 28 100 A.5. Changes from version -04 (2017-10-05) to -05 . . . . . . 29 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 29 103 1. Introduction 105 This document explores contemporary expectations of the Internet's 106 domain system (DNS) and compares them to the assumptions and 107 properties of the DNS design, including both those documented in the 108 RFC Series, an important early paper by the principal author of the 109 original RFCs [Mockapetris-1988], and a certain amount of oral 110 tradition. It is primarily intended to ask the question of whether 111 the differences are causing enough stresses on the system, stresses 112 that cannot be resolved satisfactorily by further patching, that the 113 Internet community should be considering designing a new system, one 114 that is better adapted to current needs and expectations, and 115 developing a deployment and transition strategy for it. For those 116 (perhaps the majority of us) for whom actually replacing the DNS is 117 too radical to be realistic, the document may be useful in two other 118 ways. It may provide a foundation for discussing what functions the 119 DNS should not be expected to support and how those functions can be 120 supported in other ways, perhaps via an intermediate system that then 121 calls on the DNS or by using some other type of database technology 122 for some set of functions while leaving the basic DNS functions 123 intact. Or it may provide a basis for "better just get used to that 124 and the way it works" discussions to replace fantasies about what the 125 DNS might do in some alternate reality. 127 There is a key design or philosophical question associated with the 128 analysis in this document that the document does not address. It is 129 whether changes to perceived requirements to DNS functionality as 130 described here are, in most respects, evolutionary or whether many of 131 them are instances of trying to utilize the DNS for new requirements 132 because it exists and is already deployed independent of whether the 133 DNS is really appropriate or not. The latter might be an instance of 134 a problem often described in the IETF as "when all you have is a 135 hammer, everything looks like a nail". 137 Other recent work, including a short article by Vint Cerf [Cerf2017], 138 has discussed an overlapping set of considerations from a different 139 perspective, reinforcing the view that it may be time to ask 140 fundamental questions about the evolution and future of the DNS. 142 While this document does not assume deep technical or operational 143 knowledge of the DNS, it does assume some knowledge and at least 144 general familiarity with the concepts of RFC 1034 [RFC1034] and RFC 145 1035 [RFC1035] and the terminology discussed in RFC 7719 [RFC7719] 146 and elsewhere. Although some of the comments it contains might be 147 taken as hints or examples of different ways to think about the 148 design issues, it makes no attempt to explore, much less offer a 149 tutorial on, alternate naming systems or database technologies. 151 It is perhaps worth noting that, while the perspective is different 152 and more than a dozen years have passed, many of the issues discussed 153 in this document were analyzed and described (most of them with more 154 extensive explanations) in a 2005 US National Research Council report 155 [NRC-Signposts]. 157 Readers should note that several references are to obsolete 158 documents. That was done because they are intended to show the 159 documents and dates that introduced particular features or concepts. 160 When current versions are intended, they are referenced. 162 2. Background and Hypothesis 164 The domain name system (DNS) [RFC1034] was designed starting in the 165 early 1980s [RFC0799] [RFC0881] [RFC0882] [RFC0883] with the main 166 goal of replacing the flat, centrally-administered, host table system 167 [RFC0810] [RFC0952] [RFC0953] with a hierarchical, administratively- 168 distributed, system. The DNS design included some features that, 169 after initial implementation and deployment, were judged to be 170 unworkable and either replaced (e.g., the mail destination (MD) and 171 mail forwarder (MF) approach [RFC0882] that were replaced by the MX 172 approach [RFC0974]), abandoned (e.g., the mechanism for using email 173 local parts as labels described in RFC 1034 Section 3.3), or 174 deprecated (e.g., the WKS RR TYPE [RFC1123]). Newer ideas and 175 requirements have identified a number of other features, some of 176 which were less developed than others. Of course the original 177 designers could not anticipate everything that has come to be 178 expected of the DNS in the last 30 years. 180 In recent years, demand for new and extended services and uses of the 181 DNS have, in turn, led to proposals for DNS extensions or changes of 182 various sorts. Some have been adopted, including a model for 183 negotiating extended functionality [RFC2671], others were found to be 184 impracticable, and still others continue to be under consideration. 185 A few features of the original DNS specification, such as the CLASS 186 property and label types, have also been suggested to be so badly 187 specified that they should be deprecated [Sullivan-Class]. 189 Unlike earlier changes such as the IDNA mechanisms for better 190 incorporating non-ASCII labels without modifying the DNS structure 191 itself [RFC3490] [RFC5890], some recent proposals require or strongly 192 suggest changes to APIs, formats, or interfaces by programs that need 193 to retrieve information from the DNS or interpret that information. 194 Differences between the DNS architecture and the requirements that 195 imply those proposals suggest that it may be time to stop patching 196 the DNS or trying to extend it in small increments, but to consider 197 moving some functionality elsewhere or development of a new system 198 that better meets today's needs and a transition strategy to it. 200 The next section of this document discusses a number of issues with 201 the current DNS design that could appropriately be addressed by a 202 different and newer design model. In at least some cases, changing 203 the model and protocols could bring significant benefits to the 204 Internet and/or its administration. 206 This document is not a proposal for a new protocol. It is intended 207 to stimulate thought about how far we want to try to push the 208 existing DNS, to examine whether expectations of it are already 209 exceeding its plausible capabilities, and to start discussion of a 210 redesign or alternatives to one if the time for that decision has 211 come. 213 3. Warts and Tensions With The Current DNS 215 As suggested above, there are many signs that the DNS is incapable of 216 meeting contemporary expectations of how it should work and 217 functionality it should support. Some of those expectations are 218 unrealistic under any imaginable circumstances; others are impossible 219 (or merely problematic) in the current DNS structure but could be 220 accommodated in a redesign. These are examples, rather than a 221 comprehensive list, and do not appear in any particular order. 223 3.1. Multi-type Queries 225 The DNS does not gracefully support multi-type queries.The current 226 case where this problem rears its head involves attempts at solutions 227 that return both TYPE A (IPv4) and type AAA (IPv6) addresses 228 collectively. The problem was originally seen with "QTYPE=MAILA" 229 [RFC0882] for the original MA and MD RRTYPEs, an experience that 230 strongly suggests that some very careful thinking about cache effects 231 (and possibly additional DNS changes) would be needed. Other 232 solutions might seem equally or more plausible. What they, including 233 "two types of addresses", probably have in common is that they 234 illustrate stresses on the system and that changing the DNS to deal 235 with those stresses, is not straightforward or likely to be problem- 236 free. 238 3.2. Matching Part I: Case Sensitivity in Labels and Other Anomalies 240 The DNS specifications assume that labels are octet strings and 241 octets with the high bit zero have seven-bit ASCII codes in the 242 remaining bits. They require that, when a domain name used in a 243 query is matched to one stored in the database, those ASCII 244 characters be interpreted in a case-independent way, i.e., upper and 245 lower case letters are treated as equivalent (digits and symbols are 246 not affected) [RFC4343]. For non-ASCII octets, i.e., octets in 247 labels with the first bit turned on, there are no assumptions about 248 the character coding used, much less any rules about character case 249 equivalence -- strings must be compared by matching bits in sequence. 250 Even though the current model for handling non-ASCII (i.e., 251 "internationalized") domain name labels (IDNs) [RFC5890] (and see 252 Section 3.3 below) encodes information so the DNS is not directly 253 affected, the notion that some characters in labels are handled in a 254 case-insensitive way and that others are case-sensitive (or that 255 upper case must be prohibited entirely as IDNA does) has caused a 256 good deal of confusion and resentment. Those concerns and complaints 257 about inconsistent behavior and mishandling (or suboptimal handling) 258 of case relationships for some languages have not been mitigated by 259 repeated explanations that the relationships between "decorated" 260 lower-case characters and their upper-case equivalents are often 261 sensitive to language and locality and therefore not deterministic 262 with information available to DNS servers. 264 3.3. Matching Part II: Non-ASCII ("internationalized") Domain Name 265 Labels 267 Quite independent of the case-sensitivity problem, one of the 268 fundamental properties of Unicode [Unicode] is that some abstract 269 characters can be represented in multiple ways, such as by a single, 270 precomposed, code point or by a base code point followed by one or 271 more code points that specify combining characters. While Unicode 272 Normalization can be used to eliminate many (but not all) of those 273 distinctions for comparison (matching) purposes, it is best applied 274 during matching rather than by changing one string into another. The 275 first version of IDNA ("IDNA2003") made the choice to change strings 276 during processing for either storage or retrieval [RFC3490] 277 [RFC3491]; the second ("IDNA2008") required that all strings be 278 normalized and that upper case characters are not allowed at all 279 [RFC5891]. Neither is optimal, if only because, independent of where 280 they are changed if they are changed at all, transforming the strings 281 themselves implies that the input string in an application may not be 282 the same as the string used in processing and perhaps later display. 284 It would almost certainly be preferable, and more consistent with 285 Unicode recommendations, to use normalization (and perhaps other 286 techniques if they are appropriate) at matching time rather than 287 altering the strings at all, even if there were still only a single 288 matching algorithm, i.e., normalization were added to the existing 289 ASCII-only case folding. However, even Unicode's discussion of 290 normalization [Unicode-UAX15] indicates that there are special, 291 language-dependent, cases (the most commonly-cited example is the 292 dotless "i" (U+0131)). Not only does the DNS lack any information 293 about languages that could be used in a mapping algorithm, but, as 294 long as there is a requirement that there be only one mapping 295 algorithm for the entire system, that information could not be used 296 even if it were available. One could imagine a successor system that 297 would use information stored at nodes in the hierarchy to specify 298 different matching rules for subsidiary nodes (or equivalent 299 arrangements for non-hierarchical systems). It is not clear whether 300 that would be a good idea, but it certainly is not possible with the 301 DNS as we know it. 303 3.4. Matching Part III: Label Synonyms, Equivalent Names, and Variants 305 As the initial phases of work on IDNs started to conclude, it became 306 obvious that the nature and evolution of human language and writing 307 systems required treating some names as "the same as" others. The 308 first important example of this involved the relatively recent effort 309 to simplify the Chinese writing system, thereby creating a 310 distinction between "Simplified" and "Traditional" Chinese even 311 though the meaning of the characters remained the same in almost all 312 cases (in so-called ideographic character sets, characters have 313 meaning rather than exclusively representing sounds). A joint effort 314 among the relevant country code top level domain (TLD) registries and 315 some other interested parties produced a set of recommendations for 316 dealing with the issues with that script [RFC3743] and introduced the 317 concept of "variant" characters and domain names. 319 However, when names are seen as having meanings, rather than merely 320 being mnemonics, especially when they represent brands or the 321 equivalent, or when spelling for a particular written language is not 322 completely standardized, demands to treat different strings as exact 323 equivalents are obvious and inevitable. As a trivial English- 324 language example, it is widely understood that "colour" and "color" 325 represent the same word, so does that imply that, if they are used as 326 DNS labels in domain names all of whose other labels are identical, 327 the two domain names should be treated as identical? Examples for 328 other languages or writing systems, especially ones in which some or 329 all markings that distinguish characters or words by sound or tone or 330 that change the pronunciation of words are optional, are often more 331 numerous and more problematic than national spelling differences in 332 English, but they are harder to explain to those unfamiliar with 333 those other languages or writing systems (and hard to illustrate in 334 ASCII-only Internet-Drafts and RFCs). Although approximations are 335 possible, the DNS cannot handle that requirement: not only do its 336 aliasing mechanisms (CNAME, DNAME, and various proposals for newer 337 and different types of aliasing [DNS-Aliases] [DNS-BNAME], not 338 provide a strong enough binding, but the ability to use those aliases 339 from a subtree controlled by one administrative entity to that of 340 another one implies that there is little or no possibility of the 341 owner (in either the DNS sense or the registrar-registrant one) of a 342 particular name to control the synonyms for it. Some of that issue 343 can be dealt with at the application level, e.g., by redirects in web 344 protocols, but taking that approach, which is the essential 345 characteristic of "if both names belong to the same owner, everything 346 is ok" approaches, results in names being handled in inconsistent 347 ways in different protocols. 349 A different way of looking at part of this issue (and, to some 350 degree, of the one discussed above in Section 3.3) is that these 351 perceived equivalences and desired transformations are context- 352 dependent, but the DNS resolution process is not [RFC6912]. 354 Similar problems arise as people notice that some characters are 355 easily mistaken for others and that might be an opportunity for user 356 confusion and attacks. Commonly-cited examples include the Latin and 357 Cyrillic script "a" characters, which are identical [CACM-Homograph], 358 the characters in many scripts that look like open circles or 359 vertical or horizontal lines, and even the Latin script letter "l" 360 and the European digit "1", but examples abound in other scripts and 361 combinations of scripts as well. The most common proposed solution 362 within the DNS context has been to treat these cases, as well as 363 those involving orthographic variations, as "variants" (but variants 364 different from the system for Chinese characters mentioned above) and 365 either ban all but one (or a few) of the possible labels from the DNS 366 (possibly on a first come first served basis) or by ensuring that any 367 collection of such strings that are delegated as assigned to the same 368 ownership (see above). Neither solution is completely satisfactory: 369 if all but one string is excluded, users who guess at a different 370 form, perhaps in trying to transcribe characters from written or 371 printed form, don't find what they are looking for and, as pointed 372 out above, "same ownership" is sufficient only with carefully- 373 designed and administered applications protocol support and sometimes 374 not then. 376 Some of these issues are discussed at more length in an ICANN report 377 [ICANN-VIP]. 379 3.5. Query Privacy 381 There has been growing concern in recent years that DNS queries occur 382 in clear text on the public Internet and that, if those queries can 383 be intercepted, they can expose a good deal of information about 384 interests and contacts that could compromise individual privacy. 385 While a number of proposals, including query name minimization 386 [RFC7816] and running DNS over an encrypted tunnel [RFC7858], have 387 been made to mitigate that problem, they all appear to share the 388 common properties of security patches rather than designed-in 389 security or privacy mechanisms. While experience may prove otherwise 390 once (and if) they are widely deployed, it does not appear that any 391 of them are as satisfactory as a system with query privacy designed 392 in might be. More general tutorials on this issue have appeared 393 recently [Huston2017a]. 395 3.6. Alternate Name Spaces for Public Use in the DNS Framework: The 396 CLASS Problem 398 The DNS standards include specification of a CLASS value to "identify 399 a protocol family or instance of a protocol" [RFC 1034, Section 3.6 400 and elsewhere]. While CLASS was used effectively in the early days 401 of the DNS to manage different protocol families within the same 402 administrative environment, recent attempts to use it to either 403 partition the DNS namespace in other ways such as for non-ASCII names 404 (partially to address the issues in Section 3.2 Section 3.3) or to 405 use DNS mechanisms for entirely different namespaces have exposed 406 fundamental problems with the mechanism [Sullivan-Class]. Perhaps 407 the most fundamental of those problems is disagreement about whether 408 multiple CLASSes were intended to exist within a given zone (with 409 records within RRSETs) or whether different CLASSes implied different 410 zones. Different implementations make different assumptions 411 [Faltstrom-2004] [Vixie-20170704]. These problems have led to 412 recommendations that it be dropped entirely [Sullivan-Class], but 413 discussions on the IETF list and in WGs in mid-2017 made it clear 414 that there is no clear consensus on that matter. 416 3.7. Loose Synchronization 418 The DNS model of master and slave servers, with the latter initiating 419 updates based on expiration interval values, and local caches with 420 updates based on TTL values, depends heavily on an approach that has 421 come to be called "loose synchronization", i.e., that there can be no 422 expectation that all of the servers that might reasonably answer a 423 query will have exactly the same data unless those data have been 424 unchanged for a rather long period. Put differently, if some or all 425 of the records associated with a particular node in the DNS 426 (informally, a fully-qualified domain name (FQDN)) change, one cannot 427 expect those changes to be propagated immediately. 429 That model has worked rather well since the DNS was first deployed, 430 protecting the system from requirements for mechanisms that are 431 typical where simultaneous update of multiple systems is needed. 432 Such mechanisms include elaborate locking, complex update procedures 433 and handshaking, or journaling. As has often been pointed out with 434 the Internet, implementation and operational complexity are often the 435 enemy of stability, security, and robustness. Loose synchronization 436 has helped keep the DNS as simple and robust as possible. 438 A number of recent ideas about using the DNS to store data for which 439 important changes occur very rapidly are, however, largely 440 incompatible with loose synchronization. Efforts to use very short 441 (or zero) refresh times (in SOA records for slave updates from 442 masters) and TTLs (for caches) to simulate nearly-simultaneous 443 updating may work up to a point but appear to impose very heavy loads 444 on servers and distribution mechanisms that were not designed to 445 accommodate that style of working. Similar observations can be made 446 about attempts to use the NOTIFY extension [RFC1996] or dynamic, 447 "server-push", updating rather than the traditional DNS mechanisms. 448 While the NOTIFY and push mechanisms normally provide refresh times 449 and update mechanisms faster than those specified in RFC 1034 and 450 1035, they imply that a "master" server must know the identities of 451 (and have good connectivity to all of) its slaves. That defeats at 452 least some of the advantages associated with stealth slaves, 453 particularly those associated with reduction of query traffic across 454 the Internet. Those mechanisms do nothing for cache updates: unless 455 servers keep track of the source of every query for names associated 456 with a specific zone and then somehow notify the query source 457 systems, the only alternative to having information that might be 458 obsolete stored in caches is to use very short or zero TTLs so the 459 cached data time out almost immediately after being stored (or are 460 not stored at all), requiring a new query to an authoritative server 461 each time a resolver attempts to look up a name. 463 3.8. Private Name Spaces and Special Names 465 Almost since the DNS was first deployed, there have been situations 466 in which it is desirable to use DNS-like names, and often DNS 467 resolution mechanisms or modifications of them, with name spaces for 468 which globally-available and consistent resolution using the public 469 DNS is either unfeasible or undesirable (and for which the use of 470 CLASS is not an appropriate mechanism). The need to isolate names 471 and addresses on LANs from the public Internet, typically via "split 472 horizon" approaches, is one example of this requirement although 473 often not recognized as such. Another example that has generated a 474 good deal of controversy involves "special names" -- labels or 475 pseudo-labels, often in TLD positions, that signal that the full name 476 should not be subject to normal DNS resolution or other processing 477 [RFC6761] [RFC8244]. 479 Independent of troublesome policy questions about who should allocate 480 such names and the procedures to be used, they almost inherently 481 require either a syntax convention to identify them (there actually 482 was such a convention, but it was abandoned many years ago and there 483 is no plausible way to re-institute it) or tables of such names that 484 are known to, and kept updated on, every resolver on the Internet, at 485 least if spurious queries to the root servers are to be avoided. 487 If the DNS were to be redesigned and replaced, we could recognize 488 this requirement as part of the design and handle it much better than 489 it is possible to handle it today. 491 3.9. Alternate Query or Response Encodings 493 The DNS specifies formats for queries and data responses, based on 494 the state of the art and best practices at the time it was designed. 495 Recent work has suggested that there would be significant advantages 496 to supporting at least a description of the DNS messages in one or 497 more alternate formats, such as JSON [Hoffman-DNS-JSON] 498 [Hoffman-SimpleDNS-JSON]. While that work has been carefully done to 499 avoid requiring changes to the DNS, much of the argument for having 500 such a JSON-based description format could easily be turned into an 501 argument that, if the DNS were being revised, that format might be 502 preferable as a more direct alternative to having DNS queries and 503 responses in the original form. 505 3.10. Distribution and Management of Root Servers 507 The DNS model requires a collection of root servers that hold, at 508 minimum, information about top-level domains. Over the years, that 509 requirement has evolved from a technically fairly minor function, 510 normally carried out as a service to the broader Internet community 511 and its users and systems, to a subject that is intensely 512 controversial with regard to control of those servers, including how 513 they should be distributed and where they should be located. While a 514 number of mechanisms, most recently including making the information 515 more local [RFC7706], have been proposed and one (anycast [RFC7094]) 516 is in very active use to mitigate some of the real and perceived 517 problems, it seems obvious that a DNS successor, designed for today's 518 global Internet and perceived requirements, could handle these 519 problems in a technically more appropriate and less controversial 520 way. Some additional discussion of the issues involved appears in a 521 recent paper [Huston2017b]. 523 3.11. Identifiers Versus Brands and Other Convenience Names 525 A key design element of the original network object naming systems 526 for the ARPANET, largely inherited by the DNS, was that the names, 527 while expected to be mnemonic, were identifiers and their being 528 highly distinguishable and not prone to ambiguity was important. 529 That led to restrictive rules about what could appear in a name. 530 Those restrictions originated with the host table and even earlier 531 [RFC0236] [RFC0247] and came to the DNS (largely via SMTP) as the 532 "preferred syntax" [RFC 1034 Section 3.5] or what we now often call 533 the letter-digit-hyphen (LDH) rule. Similar rules to make 534 identifiers easier to use, less prone to ambiguity, or less likely to 535 interfere with syntax occur frequently in more formal languages. For 536 example, almost every programming language has restrictions on what 537 can appear in an identifier and Unicode provides general 538 recommendations about identifier composition [Unicode-USA31]. Both 539 are quite restrictive as compared to the number of characters and 540 total number of strings that can be written using that character 541 coding system. 543 That model, which originally prohibited labels starting with digits 544 in order to avoid any possible confusion with IP addresses, began to 545 break down in 1987 or 1988 when a company named 3Com wanted to use 546 its corporate name as a label within the COM TLD and the rule was 547 relaxed [RFC1123]. 549 In the last decade or two, the perspective that company names should 550 be supported if possible has expanded and done so largely without its 551 limits, if any, being explicitly understood or acknowledged. In the 552 current form, the DNS is really (and primarily) a system for 553 expressing thoughts and concepts. Those include free expression of 554 ideas in as close to natural language as possible as well as 555 representation of product names and brands. That view requires 556 letter-like characters that might not be reasonable in identifiers 557 along with a variety of symbols and punctuation. It may also require 558 indicators of preferred type styles to provide information in a form 559 that exactly matches personal or legal preferences. At least it 560 carried to an extreme, that perspective would argue for standardizing 561 word and sentence separators, for removing the 63 octet per label 562 limit and probably the limit of 255 octets on the total length of a 563 domain name, and perhaps even eliminating the hierarchy or allowing 564 separators for labels in presentation form (now fixed at "." for the 565 DNS) to be different according to context. It suggests that, at 566 least, the original design was defective in not prioritizing those 567 uses over the more restrictive approach associated with prioritizing 568 unique and unambiguous identifiers. 570 So we have two, or, depending on how one counts, three very different 571 use cases. The historical one is support for unique identifiers. 572 The other is expression of ideas and, if one considers them separate, 573 presentation of brand and product names. Because they inherently 574 involve different constraints, priorities, and success criteria, 575 these perspectives are, at best, only loosely compatible. 577 We cannot simultaneously optimize both the identifier perspective and 578 either or both of the others in the same system. At best, there are 579 some complex trade-offs involved. Even then, it is not clear that 580 the same DNS (or other system) can accommodate all of them. Until we 581 come to terms with that, the differences manifest themselves with 582 friction among communities, most often with tension between "we want 583 to do (or use or sell) these types of labels" and "not good for the 584 operational Internet or the DNS". 586 3.12. A Single Hierarchy with a Centrally-controlled Root 588 A good many Internet policy discussions in the last two decades have 589 revolved around such questions of how many top level domains there 590 should be, what they should be, who should control them and how, how 591 (or if) their individual operations and policy decisions should be 592 accountable to others, and what processes should be used (and by what 593 entities or organizational structures) to make those decisions. 594 Several people have pointed out that, if we were designing a next- 595 generation DNS using today's technology, it should be possible to 596 remove the technical requirement for a central authority over the 597 root (some people have suggested that blockchain approaches would be 598 helpful for this purpose; others believe they just would not scale 599 adequately, at least at acceptable cost, but that other options are 600 possible). Whether elimination of a single, centrally-controlled, 601 root would be desirable or not is fairly obviously a question of 602 perspective and priorities. 604 3.13. Newer Application Protocols, New Requirements, and DNS Evolution 606 New work done in other areas has led to demands for new DNS features, 607 many of them involving data values that require recursively 608 referencing the DNS. Early record types that did that were 609 accompanied by restrictions that reduced the risk of looping 610 references or other difficulties. For example, while the MX RRTYPE 611 has a fully-qualified domain name as its data, SMTP imposes "primary 612 name" restrictions that prevent the name used from being, e.g., a 613 CNAME. While loops with CNAMEs are possible, RFC 1034, Section 3.6, 614 includes a discussion about ways to avoid problems and how they 615 should be handled. Some newer protocols and conventions can cause 616 more stress. There are separate issues with additions and with how 617 the DNS has been extended to try to deal with them. 619 3.13.1. The Extensions 621 Some examples of DNS extensions for new protocol demands that 622 illustrate, or have led to, increased stress include: 624 NAPTR Requires far more complex data in the DNS for ENUM (e.g., 625 VoIP, specifically SIP) support, including URI information and 626 hence recursive or repeated lookups, than any of the RRTYPEs 627 originally supported. The RRSET associated with these records can 628 become quite large because the separator between the various 629 records is part of the RDATA, and not the {owner, class, type} 630 triple (a problem slightly related to the problem with overloading 631 of TXT RTYPE discussed in Section 3.13.2). 632 [[CREF1: I'm told this issue was brought up by IAB in RFCXXXX ???, 633 but have not yet tracked down the reference -JcK]] 634 This problem, and similar ones for some of the cases below. may 635 suggest that any future design is in need of a different TYPE 636 model such as systematic arrangements for subtypes or some 637 explicit hierarchy in the TYPEs. 639 URI Has a URI as its data, typically also requiring recursive or 640 repeated lookups. 642 Service location (SRV) and credential information (including SPF and 643 DKIM) 644 Require structured data and, especially for the latter two, 645 significantly more data, than most original RRTYPEs. 647 URI/URL The early design decision for the World Wide Web that its 648 mechanism for identifying digital web content (now known as 649 Uniform Resource Identifiers [RFC3986]) did so by using domain 650 names and hence the network location of the information or other 651 material. That, in turn, has required systems intended to improve 652 web performance by locating and retrieving a "nearest copy" 653 (rather than the single copy designated by the URL) to intercept 654 DNS queries and respond with values that are not precisely those 655 stored for the designated domain name in the DNS or to otherwise 656 access information in a way not supported by the DNS itself. 658 3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE 660 Unfortunately (but unsurprisingly), and despite IETF efforts to make 661 things easier [RFC6895], DNS support libraries have often been slow 662 to add full support for new RRTYPEs. This has impeded deployment of 663 applications that depend on those types and that must ask (query) 664 explicitly for them. Both to get faster deployment and, at least 665 until recently, to avoid burdensome IETF approval procedures, many 666 application designers have chosen to push protocol-critical 667 information into records with TXT RRTYPE, a record type that was 668 originally intended to include only information equivalent to 669 comments. 671 This causes two problems. First, TXT records used this way tend to 672 get long and complex, which is a problem in itself if one is trying 673 to minimize TCP connections. Second, applications that are 674 attempting to obtain data cannot merely ask for the relevant QTYPE, 675 they must obtain all of the records with QTYPE TXT and parse them to 676 determine which ones are of interest. That would be easier if there 677 was some standard for how to do that parsing but, at least in part 678 because the clear preference in the DNS design is for distinct 679 RRTYPEs for different kinds of information, there is no such standard 680 (there was a proposal in 1993 to structure the TXT DATA in a way that 681 would have addressed the issue [RFC1464] but it apparently never went 682 anywhere). 684 On the other hand, this issue is somewhat different from most of the 685 others described in this document because (as the IETF has 686 recommended several times) the problem is easily solved within the 687 current DNS design by allocating and supporting new RRTYPEs when 688 needed rather than using TXT as a workaround (that does not mean that 689 other solutions are impossible, either with the current DNS or some 690 other design). The problem then lies in the implementations and/or 691 mechanisms that deter or impede rapid deployment of support for new 692 RRTYPEs. 694 3.13.3. Periods and Zone Cut Issues 696 One of the DNS characteristics that is poorly understood by non- 697 experts is that the period (".", U+002E) character can be used in 698 three different ways: 700 o As a label separator in the presentation form that also designates 701 a "zone break" (delegation boundary). For example, 702 foo.bar.example.com indicates the owner, "foo", of records in the 703 "bar.example.com" zone. 705 o As a label separator in the presentation form that does not 706 designate a zone break. For example, foo.bar.example.com 707 indicates the owner, "foo.bar", of records in the "example.com" 708 zone. 710 o As a character within a label, including as a substitute for an 711 at-sign ("@") when an email address appears in an SOA record or in 712 a label that denotes such an address (see Section 2 above). The 713 ability to embed periods in labels in this way has also led to 714 attacks in which, e.g., a domain name consisting of the labels 715 "example" followed by "com" is deliberately confused with the 716 single label "example.com" with an embedded period. 718 In general, these cases cannot be distinguished by looking at them. 719 The third is problematic for non-DNS reasons, e.g., 720 "john.doe.example.net" is ambiguous as to whether it should be 721 interpreted as a simple FQDN, as a notation for john.doe@example.net, 722 for john@doe.example.net, and so on. 724 The distinction between the first two cases was probably not 725 important as the DNS was originally intended to be used. However, as 726 soon as RRTYPEs (other than NS records that define the zone cut) are 727 used that are sensitive to the boundaries between zones, the 728 distinctions become important to people other than the relevant zone 729 administrators. DNSSEC [RFC4033] involves one such set of 730 relationships. It increases the importance of questions about what 731 should go in a parent zone and what should go in child zones and how 732 much difference it makes if NS records in a parent zone for a child 733 zone are consistent with the records and data in the child zone. 734 This also causes application issues and may raise questions about 735 relationships between registrars and one or more registries or, if 736 they are separate, DNS operators. 738 3.14. Scaling of Reputation and Other Ancillary Information 740 The original design for DNS administration, reflected in RFC 1591 741 [RFC1591] and elsewhere, assumed that all domains would exhibit a 742 very high level of responsibility toward and for the community and 743 that level of responsibility would be enforced if necessary. 745 More recent decisions, many of them associated with commercialization 746 of the DNS, have eroded those very strong assumptions of registry 747 responsibility and accountability to the point that many consider 748 decisions about delegation of names, identification of registrants, 749 and relationships among names to be matters of of "registrant beware" 750 and even "user and applications beware". While some recent protocols 751 and proposals at least partially reflect that original model of a 752 high level of responsibility (see, e.g., IDNA [RFC5890] and the 753 discussion in a recent Internet-Draft [Klensin-5891bis]), other 754 decisions and actions tend to shift responsibility to the registrant 755 or try to avoid accountability entirely. One possible approach to 756 the problems, especially security problems, that are enabled by those 757 new trends and the associated environment is to establish reputation 758 systems associated with clearly-defined administrative boundaries and 759 with warnings to users, even if those reputation systems are managed 760 by parties not directly associated with the DNS. 762 The IETF DBOUND WG [IETF-DBOUND] addressed ways to establish and 763 document boundaries more precise than simple dependencies on TLDs but 764 it was not successful in producing a standard. 766 A TLD reputation-based approach was adopted by some web browsers 767 after IDNs and a growing number of gTLDs were introduced; that 768 approach was based on a simple list and does not scale to the current 769 size of the DNS or even the DNS root. 771 3.15. Tensions among transport, scaling and content 773 The original design for the DNS envisaged a simple query and response 774 protocol where both the command and the response could be readily 775 mapped into a single IP packet. The Hosts Requirement specification 776 [RFC1123] required all DNS applications to accept a UDP query or 777 response over UDP with up to 512 octets of DNS payload. TCP was seen 778 as a fallback when the response was greater than this 512 octet 779 limit, and this fallback to use TCP as the transport protocol was 780 considered to be the exception rather than the rule. 782 Over the intervening years we have seen the rise of a common 783 assumption of an Internet-wide Maximum Transmission Unit size of 784 1,500 octets, accompanied with an assumption that UDP fragmentation 785 is generally viable. This underpins the adoption of the Extended DNS 786 Options [RFC6891] to specify a UDP buffer size larger than 512 octets 787 and a suggestion within that specification to use 4,096 as a suitable 788 compromise as a UDP payload size. This has proved to be fortuitous 789 for the DNSSEC security extensions where the addition of DNSSEC 790 security credentials in DNS responses [RFC4034] can lead to the use 791 of large DNS responses. However, this exposes some tensions over the 792 handling of fragmentation in IP, where UDP fragments have been 793 observed to be filtered by various firewalls. Additionally for IPv6, 794 there are the factors of filtering of the ICMPv6 Packet Too Big 795 diagnostic messages, and discarding of IPv6 packets that contain 796 extension headers [RFC7872]. More generally, fragmented UDP packets 797 appear to have a lower level of reliability than unfragmented TCP 798 packets. 800 Behind this observation about relative reliability of delivery is the 801 tension between the lightweight load of UDP and the downside of 802 elevated probability of discarding of packet fragments as compared to 803 TCP, which offers increased levels of assurance of content delivery, 804 but with the associated imposition of TCP session state and the 805 downside of reduced DNS scalability and increased operational cost. 807 4. The Inverse Lookup Requirement 809 The requirement for an inverse lookup capability, i.e., the ability 810 to find a domain name given an address and, in principle, to find the 811 owner of a record by any of its data elements, was recognized in RFC 812 882. The feature was identified as optional but carried forward into 813 RFC 1034 and 1035 but was explicitly deprecated by RFC 1034 for 814 address to host name lookup (although RFC 1035 uses exactly that type 815 of lookup in an example). Despite the discussion of inverted forms 816 of the database in RFC 1035, inverse lookup has rarely, if ever, been 817 implemented, at least in its general form. The fundamental 818 difficulties with inverse lookup in either the RFC 882 form or the 819 "in-addr.arpa" approach mentioned below are consistent with the 820 problems described in fundamental papers on database management 821 [Codd1970] but were not described in RFC 1035 or related contemporary 822 IETF documents. 824 It is interesting to speculate on how many of the current 825 requirements to treat aliases as an integrated set of synonyms (e.g., 826 for variant handling) would have been addressed if inverse lookups 827 could reliably produce the owners of CNAME records. 829 At the same time, it was obviously important to have some mechanism 830 for address to name resolution. It was provided by PTR RRTYPE 831 entries in the IN-ADDR.ARPA zone, with delegations on octet 832 boundaries. However, that approach required that information be 833 maintained in parallel, in separate zones, for the name-> address and 834 address-> name mappings. That synchronization requirement for two 835 copies of essentially the same data was another popular topic in the 836 database management literature a decade or more before the DNS and, 837 predictably, led to many inconsistencies and other failures. 839 The introduction of CIDR [RFC1518] and Provider Dependent addresses 840 made the situation even more difficult, because it was no longer 841 possible to delegate the administration of reverse mapping records 842 for small networks to the actual operators of those networks. ISPs 843 and other aggregators often had no incentive to maintain reverse 844 mapping records consistent with network operator assignment of domain 845 names. A proposal to use binary labels to work around that issue 846 [RFC2673] was abandoned somewhat over three years later [RFC6891]. 848 Independent of how much or little harm the absence of a general 849 inverse lookup facility has caused and how effective the IN-ADDR.ARPA 850 approach has been, inverse lookup remains a facility that was 851 anticipated and known to be useful in the original DNS design but 852 that has never been fully realized. 854 5. Internet Scale, Function Support, and Incremental Deployment 856 In addition to the stresses caused by the new functions, including 857 those described in Section 3.13, incremental deployment of systems 858 that utilize them means that some functions will work in some 859 environments and not others. This has been especially problematic 860 with complex, multi-record, capabilities like DNSSEC that provide or 861 require special validation mechanisms and with some EDNS0 mechanisms 862 [RFC6891] that require that both client and server accept particular 863 extensions. When DNS functionality is required in embedded devices, 864 deployment of new features across the entire Internet in a reasonable 865 period of time is nearly impossible. 867 If one were redesigning the DNS, one could imagine ways to address 868 these issues that would make them slightly more tractable and, of 869 course, the features that are known to be necessary today could 870 become part of the baseline, "mandatory to implement", specification. 872 6. Searching and the DNS - An Historical Note 874 Some of the issues identified above might reasonably be addressed, 875 not by changing the DNS itself but by changing our model of what it 876 is about and how it is used. Specifically, one key assumption when 877 the DNS (and the host table system before it) was designed was that 878 it was a naming system for network resources, not, e.g., digital 879 content. As such, exact matching was important, it was reasonable to 880 have labels treated as mnemonics that did not necessarily have 881 linguistic or semantic meaning except to those using them, and so on. 882 A return to that model, presumably by having user-facing applications 883 call on an intermediate layer to disambiguate user-friendly names and 884 map them to DNS names (or network object locators more generally) 885 would significantly reduce stress on the DNS and would also allow 886 dealing with types of matching and similar or synonymous strings that 887 cannot be handled algorithmically no matter how much DNS matching 888 rules were altered. 890 In some respects, search engines based on free-text analysis and 891 linkages among information have come to serve many of the functions 892 of such an intermediate layer. Many studies and sources have pointed 893 out that few users actually understand, much less care about, the 894 distinction between a DNS name and a search term. Recent versions of 895 some web browsers have both recognized the failure of that 896 distinction and reinforced it by eliminating the separation between 897 "URL" and "search bar". 899 It is worth noting that, while that "search" approach, or some other 900 approach that abstracted and separated several of the issues 901 identified in Section 3 from the DNS protocol and database 902 themselves, it does not address all of them. At least some elements 903 of several of those issues, such as the synchronization ones 904 described in Section 3.7 and the transport ones described in 905 Section 3.15, are inherent in the DNS design and, if we are not going 906 to replace the DNS, we had best get used to them. 908 In the early part of the last decade, the IETF engaged in some 909 preliminary exploration of the intermediate layer approach in the 910 context of IDNs and what were then called "Internet keywords" 911 [DNS-search]. It may be time to examine that approach again and to 912 do so more deeply in the context of developments since the time of 913 that earlier work and the degree to which use of an intermediate 914 layer by appropriate user-facing applications might be used to 915 address some of the issues identified above. 917 7. Acknowledgements 919 Many of the concerns and ideas described in this document reflect 920 conversations over a period of many years, some rooted in DNS 921 "keyword" and "search" discussions that paralleled the development of 922 Internationalized Domain Names (IDNs). Conversations with, or 923 writings of, Rob Austein, Christine Borgman, Carolina Carvalho, Vint 924 Cerf, Lyman Chapin, Nazli Choucri, Patrik Faltstrom, Geoff Huston, 925 Xiaodong Lee, Karen Liu, Gervase Markham, Yaqub Mueller, Andrew 926 Sullivan, Paul Twomey, Nico Williams, Suzanne Woolf, Jiankang Yao, 927 other participants in the circa 2003 "DNS Search" effort and in the 928 ICANN SSAC Working Party on IDNs, and some others whose names were 929 sadly forgotten, were particularly important to either the content of 930 this document or the motivation for writing it even though they may 931 not agree with the conclusions I have reached and bear no 932 responsibility for them. 934 Many of the subsections of Section 3 were extracted from comments 935 first made in conjunctions with recent email discussions. Comments 936 from Suzanne Woolf about an early draft were particularly important 937 as was material developed with suggestions from Patrik Faltstrom, 938 especially Section 3.13. Feedback and suggestions from several of 939 the above and from Stephane Bortzmeyer, Tony Finch, Warren Kumari, 940 Craig Partridge, and George Sadowsky were extremely helpful for 941 improving the clarity and accuracy of parts of the document, 942 especially so for a broader audience. Craig Partridge also 943 contributed much of the material about queries for multiple types. 944 Geoff Huston made several useful comments and contributed most of 945 Section 3.15 and Bill Manning pointed out some broader requirements 946 about integrity of information and DNS management and operations. 948 8. IANA Considerations 950 [[CREF2: RFC Editor: Please remove this section before publication.]] 952 This memo includes no requests to or actions for IANA. 954 9. Security Considerations 956 A wide range of security issues related to both securing the DNS and 957 also to abilities to use namespaces for nefarious purposes have 958 arisen. Issues of securing the DNS would obviously be essential to a 959 replacement of the DNS. Issues of preventing nefarious use of the 960 namespace (e.g. use of the name that appears or disappears as a 961 signal to bots) would appear to be harder to solve within the naming 962 system. 964 [[CREF3: References needed ]] 966 10. References 968 10.1. Normative References 970 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 971 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 972 . 974 [RFC1035] Mockapetris, P., "Domain names - implementation and 975 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 976 November 1987, . 978 10.2. Informative References 980 [CACM-Homograph] 981 Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", 982 Communications of the ACM 45(2):128, February 2002, 983 . 986 [Cerf2017] 987 Cerf, V., "Desirable Properties of Internet Identifiers", 988 IEEE Internet Computing November/December 2017, pp. 2-3, 989 DOI 1089-7801/17, 2017. 991 [Codd1970] 992 Codd, E., "A Relational Model of Data for Large Shared 993 Data Banks", Commun. ACM 13, 6, DOI 10.1145/362384.362685, 994 June 1970, . 996 [DNS-Aliases] 997 Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS 998 Resolution of Aliased Names", March 2011, 999 . 1002 [DNS-BNAME] 1003 Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name 1004 Redirection", May 2016, . 1007 [DNS-search] 1008 IETF, "Internet Resource Name Search Service", 2003, 1009 . 1011 While it met several times informally and as one or more 1012 BOFs, this effort never really got off the ground. That 1013 was due in part to the IETF decision to go forward with 1014 the IDNA approach and in part by signs that the "keyword" 1015 efforts were beginning to fall apart. 1017 [Faltstrom-2004] 1018 Faltstrom, P. and R. Austein, "Design Choices When 1019 Expanding DNS", May 2004, . 1021 [Hoffman-DNS-JSON] 1022 Hoffman, P., "Representing DNS Messages in JSON", May 1023 2017, . 1026 [Hoffman-SimpleDNS-JSON] 1027 Hoffman, P., "Simple DNS Queries and Responses in JSON", 1028 June 2017, . 1031 [Huston2017a] 1032 Huston, G. and J. Silva Dama, "DNS Privacy", Internet 1033 Protocol Journal Vol 20, No 1, March 2017, 1034 . 1037 [Huston2017b] 1038 Huston, G., "The Root of the Domain Name System", Internet 1039 Protocol Journal 20, 2, June 2017, 1040 . 1043 [ICANN-VIP] 1044 ICANN, "IDN Variant Issues Project: Final Integrated 1045 Issues Report Published and Proposed Project Plan for Next 1046 Steps is Now Open for Public Comment", February 2012, 1047 . 1049 [IETF-DBOUND] 1050 IETF, "Domain Boundaries (dbound)", 2017, 1051 . 1053 [Klensin-5891bis] 1054 Klensin, J., "Internationalized Domain Names in 1055 Applications (IDNA): Registry Restrictions and 1056 Recommendations", March 2017, 1057 . 1060 [Mockapetris-1988] 1061 Mockapetris, P. and K. Dunlap, "Development of the Domain 1062 Name System", SIGCOMM '88 Symposium pp. 123-133, 1063 DOI 10.1145/52324.52338, ISO Reprint Series ISI/RS-88-219 1064 (ftp://ftp.isi.edu/isi-pubs/rs-88-219.pdf), August 1988, 1065 . 1068 [NRC-Signposts] 1069 National Research Council, "Signposts in Cyberspace: The 1070 Domain Name System and Internet Navigation"", 2005, 1071 . 1075 [RFC0236] Postel, J., "Standard host names", RFC 236, 1076 DOI 10.17487/RFC0236, September 1971, 1077 . 1079 [RFC0247] Karp, P., "Proffered set of standard host names", RFC 247, 1080 DOI 10.17487/RFC0247, October 1971, 1081 . 1083 [RFC0799] Mills, D., "Internet name domains", RFC 799, 1084 DOI 10.17487/RFC0799, September 1981, 1085 . 1087 [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD 1088 Internet host table specification", RFC 810, 1089 DOI 10.17487/RFC0810, March 1982, 1090 . 1092 [RFC0881] Postel, J., "Domain names plan and schedule", RFC 881, 1093 DOI 10.17487/RFC0881, November 1983, 1094 . 1096 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 1097 RFC 882, DOI 10.17487/RFC0882, November 1983, 1098 . 1100 [RFC0883] Mockapetris, P., "Domain names: Implementation 1101 specification", RFC 883, DOI 10.17487/RFC0883, November 1102 1983, . 1104 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 1105 host table specification", RFC 952, DOI 10.17487/RFC0952, 1106 October 1985, . 1108 [RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, "Hostname 1109 Server", RFC 953, DOI 10.17487/RFC0953, October 1985, 1110 . 1112 [RFC0974] Partridge, C., "Mail routing and the domain system", 1113 STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, 1114 . 1116 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1117 Application and Support", STD 3, RFC 1123, 1118 DOI 10.17487/RFC1123, October 1989, 1119 . 1121 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 1122 Arbitrary String Attributes", RFC 1464, 1123 DOI 10.17487/RFC1464, May 1993, 1124 . 1126 [RFC1518] Rekhter, Y. and T. Li, "An Architecture for IP Address 1127 Allocation with CIDR", RFC 1518, DOI 10.17487/RFC1518, 1128 September 1993, . 1130 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1131 RFC 1591, DOI 10.17487/RFC1591, March 1994, 1132 . 1134 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1135 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1136 August 1996, . 1138 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1139 RFC 2671, DOI 10.17487/RFC2671, August 1999, 1140 . 1142 [RFC2673] Crawford, M., "Binary Labels in the Domain Name System", 1143 RFC 2673, DOI 10.17487/RFC2673, August 1999, 1144 . 1146 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1147 "Internationalizing Domain Names in Applications (IDNA)", 1148 RFC 3490, DOI 10.17487/RFC3490, March 2003, 1149 . 1151 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1152 Profile for Internationalized Domain Names (IDN)", 1153 RFC 3491, DOI 10.17487/RFC3491, March 2003, 1154 . 1156 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1157 "DNS Extensions to Support IP Version 6", STD 88, 1158 RFC 3596, DOI 10.17487/RFC3596, October 2003, 1159 . 1161 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 1162 Engineering Team (JET) Guidelines for Internationalized 1163 Domain Names (IDN) Registration and Administration for 1164 Chinese, Japanese, and Korean", RFC 3743, 1165 DOI 10.17487/RFC3743, April 2004, 1166 . 1168 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1169 Resource Identifier (URI): Generic Syntax", STD 66, 1170 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1171 . 1173 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1174 Rose, "DNS Security Introduction and Requirements", 1175 RFC 4033, DOI 10.17487/RFC4033, March 2005, 1176 . 1178 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1179 Rose, "Resource Records for the DNS Security Extensions", 1180 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1181 . 1183 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 1184 Insensitivity Clarification", RFC 4343, 1185 DOI 10.17487/RFC4343, January 2006, 1186 . 1188 [RFC5890] Klensin, J., "Internationalized Domain Names for 1189 Applications (IDNA): Definitions and Document Framework", 1190 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1191 . 1193 [RFC5891] Klensin, J., "Internationalized Domain Names in 1194 Applications (IDNA): Protocol", RFC 5891, 1195 DOI 10.17487/RFC5891, August 2010, 1196 . 1198 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 1199 RFC 6761, DOI 10.17487/RFC6761, February 2013, 1200 . 1202 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1203 for DNS (EDNS(0))", STD 75, RFC 6891, 1204 DOI 10.17487/RFC6891, April 2013, 1205 . 1207 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1208 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1209 April 2013, . 1211 [RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, 1212 "Principles for Unicode Code Point Inclusion in Labels in 1213 the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, 1214 . 1216 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1217 "Architectural Considerations of IP Anycast", RFC 7094, 1218 DOI 10.17487/RFC7094, January 2014, 1219 . 1221 [RFC7706] Kumari, W. and P. Hoffman, "Decreasing Access Time to Root 1222 Servers by Running One on Loopback", RFC 7706, 1223 DOI 10.17487/RFC7706, November 2015, 1224 . 1226 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1227 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1228 2015, . 1230 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1231 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1232 . 1234 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1235 and P. Hoffman, "Specification for DNS over Transport 1236 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1237 2016, . 1239 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1240 "Observations on the Dropping of Packets with IPv6 1241 Extension Headers in the Real World", RFC 7872, 1242 DOI 10.17487/RFC7872, June 2016, 1243 . 1245 [RFC8244] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 1246 Names Problem Statement", RFC 8244, DOI 10.17487/RFC8244, 1247 October 2017, . 1249 [Sullivan-Class] 1250 Sullivan, A., "The DNS Is Not Classy: DNS Classes 1251 Considered Useless", July 2016, 1252 . 1255 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1256 9.0.0,", ISBN 978-1-936213-13-9, 2016, 1257 . 1259 [Unicode-UAX15] 1260 Davis, M. and K. Whistler, "Unicode Normalization Forms", 1261 February 2016, . 1263 [Unicode-USA31] 1264 Davis, M., "Unicode Identifier and Pattern Syntax", May 1265 2016, . 1267 [Vixie-20170704] 1268 Vixie, P., "Re: new DNS classes (email communication>", 1269 IETF Mailing Lists IETF-discuss and dnsop, Jule 2017, 1270 . 1273 Appendix A. Change Log 1275 RFC Editor: Please remove this appendix before publication. 1277 A.1. Changes from version -00 (2017-06-02) to -01 1279 o Many editorial corrections 1281 o Addition of new (some replacing prior placeholder) sections, 1282 especially to the list of issues with the current DNS design and 1283 notably including Section 3.13. 1285 A.2. Changes from version -01 (2017-06-06) to -02 1287 o Improved the discussion ins several sections, including a somewhat 1288 muddled description in Section 3.7 1290 o Revised the Introduction to make the context for this document 1291 somewhat more clear. 1293 o Added several more references even though still not nearly enough 1294 to make this document a comprehensive bibliography (which is not 1295 intended). 1297 o Many editorial corrections and a few added references. 1299 A.3. Changes from version -02 (2017-06-19) to -03 1301 o Added Section 3.15, discussing pressures less related to content, 1302 and smaller amounts of new material elsewhere. 1304 o Added some additional references and acknowledgments. 1306 o Extensive editorial corrections and revisions for clarity. 1308 A.4. Changes from version -03 (2017-06-26) to -04 1310 o Removed most of the initial "Author's Note". 1312 o Added Section 4 after a discussion with Nico Williams. 1314 o Rewrote several sections, and rearranged section numbering based 1315 on comments from Craig Partridge. 1317 o Old "Multiple address types" section replaced by a new "Multi-type 1318 queries" section largely supplied by Craig Partridge. 1320 o More small editorial corrections. 1322 A.5. Changes from version -04 (2017-10-05) to -05 1324 o Removed the former "Note in Draft" Section 2 and the "where to 1325 discuss" note from the front matter.. 1327 o Added some material resulting from reviews by Warren Kumari and 1328 others, including updating some references and adding another one. 1330 o Usual few small editorial fixes. 1332 Author's Address 1334 John C Klensin 1335 1770 Massachusetts Ave, Ste 322 1336 Cambridge, MA 02140 1337 USA 1339 Phone: +1 617 245 1457 1340 Email: john-ietf@jck.com