idnits 2.17.1 draft-klensin-dns-function-considerations-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 : ---------------------------------------------------------------------------- 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 (June 26, 2017) is 2490 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- 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 974 (Obsoleted by RFC 2821) -- Obsolete informational reference (is this intentional?): RFC 2671 (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) -- Duplicate reference: RFC5891, mentioned in 'RFC5891', was also mentioned in 'Klensin-5891bis'. -- 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 (~~), 1 warning (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Klensin 3 Internet-Draft June 26, 2017 4 Intended status: Informational 5 Expires: December 28, 2017 7 DNS Privacy, Authorization, Special Uses, Encoding, Characters, 8 Matching, and Root Structure: Time for Another Look? 9 draft-klensin-dns-function-considerations-03 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 Author's Note 27 This draft is intended to draw a number of issues and references 28 together in one place and to start a discussion. It is obviously 29 incomplete, particularly with regard to the list of perceived issues 30 and deficiencies with that DNS. To avoid misunderstanding, I don't 31 completely believe some of the deficiencies listed below but am 32 merely providing information about claims of deficiencies. Input is 33 welcome, especially about what is missing (or plain wrong) and would 34 be greatly appreciated. 36 This document should be discussed on the IETF list or by private 37 conversation with the author. 39 Status of This Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on December 28, 2017. 56 Copyright Notice 58 Copyright (c) 2017 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 74 2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 4 75 3. Warts and Tensions With The Current DNS . . . . . . . . . . . 5 76 3.1. Multiple address types . . . . . . . . . . . . . . . . . 5 77 3.2. Matching Part I: Case Sensitivity in Labels and Other 78 Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.3. Matching Part II: Non-ASCII ("internationalized") Domain 80 Name Labels . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.4. Matching Part III: Label Synonyms, Equivalent Names, and 82 Variants . . . . . . . . . . . . . . . . . . . . . . . . 7 83 3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 9 84 3.6. Alternate Name Spaces for Public Use in the DNS 85 Framework: The CLASS Problem . . . . . . . . . . . . . . 9 86 3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 9 87 3.8. Private Name Spaces and Special Names . . . . . . . . . . 10 88 3.9. Alternate Query or Response Encodings . . . . . . . . . . 11 89 3.10. Distribution and Managment of Root Servers . . . . . . . 11 90 3.11. Identifiers Versus Brands and Other Convenience Names . . 12 91 3.12. A Single Hierarchy with a Centrally-controlled Root . . . 13 92 3.13. Newer Application Protocols and New Requirements . . . . 13 93 3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 13 94 3.13.2. Extensions and Deployment Pressures -- The TXT 95 RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 14 96 3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 15 98 3.14. Scaling of Reputation and Other Ancillary Information . . 16 99 3.15. Tensions among transport, scaling and content . . . . . . 17 100 4. Searching and the DNS - An Historical Note . . . . . . . . . 17 101 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 102 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 104 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 105 8.1. Normative References . . . . . . . . . . . . . . . . . . 19 106 8.2. Informative References . . . . . . . . . . . . . . . . . 19 107 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 108 A.1. Changes from version -00 (2017-06-02) to -01 . . . . . . 25 109 A.2. Changes from version -01 (2017-06-06) to -02 . . . . . . 25 110 A.3. Changes from version -02 (2017-06-19) to -03 . . . . . . 25 111 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 25 113 1. Introduction 115 This document explores contemporary expectations of the Internet's 116 domain system (DNS) and compares them to the assumptions and 117 properties of the DNS design. It is primarily intended to ask the 118 question of whether the differences are causing enough stresses on 119 the system, stresses that cannot be resolved satisfactorily by 120 further patching, that the Internet community should be considering 121 designing a new system, one that is better adapted to current needs 122 and expectations, and developing a deployment and transition strategy 123 for it. For those (perhaps the majority of us) for whom actually 124 replacing the DNS is too radical to be realistic, the document may be 125 useful in two other ways. It may provide a foundation for discussing 126 what functions the DNS should not be expected to support and how 127 those functions can be supported in other ways, perhaps via an 128 intermediate system that then calls on the DNS or by using some other 129 type of database technology for some set of functions while leaving 130 the basic DNS functions intact. Or it may provide a basis for 131 "better just get used to that and the way it works" discussions to 132 replace fantasies about what the DNS might do in some alternate 133 reality. 135 There is a key design or philosophical question associated with the 136 analysis in this document that the document does not address. It is 137 whether changes to perceived requirements to DNS functionality as 138 described here are, in most respects, evolutionary or whether many of 139 them are instances of trying to utilize the DNS for new requirements 140 because it exists and is already deployed independent of whether the 141 DNS is really appropriate or not. The latter might be an instance of 142 a problem often described in the IETF as "when all you have is a 143 hammer, everything looks like a nail". 145 While this document does not assume deep technical or operational 146 knowledge of the DNS, it does assume some knowledge and at least 147 general familiarity with the concepts of RFC 1034 [RFC1034] and RFC 148 1035 [RFC1035] and the terminology discussed in RFC 7719 [RFC7719] 149 and elsewhere. Although some of the comments it contains might be 150 taken as hints or examples of different ways to think about the 151 design issues, it makes no attempt to explore, much less offer a 152 tutorial on, alternate naming systems or database technologies. 154 It is perhaps worth noting that, while the perspective is different 155 and more than a dozen years have passed, many of the issues discussed 156 in this document were analyzed and described (most of them with more 157 extensive explanations) in a 2005 US National Research Council report 158 [NRC-Signposts]. 160 Readers should note that several references are to obsolete 161 documents. That was done because they are intended to show the 162 documents and dates that introduced particular features or concepts. 163 When current versions are intended, they are referenced. 165 2. Background and Hypothesis 167 The domain name system (DNS) [RFC1034] was designed starting in the 168 early 1980s [RFC0799] [RFC0881] [RFC0882] with the main goal of 169 replacing the flat, centrally-administered, host table system 170 [RFC0810] [RFC0952] [RFC0953] with a hierarchical, administratively- 171 distributed, system. The DNS design included some features that, 172 after initial implementation and deployment, were judged to be 173 unworkable and either replaced (e.g., the mail destination (MD) and 174 mail forwarder (MF) approach [RFC0882] that were replaced by the MX 175 approach [RFC0974]), abandoned (e.g., the mechanism for using email 176 local parts as labels described in RFC 1034 Section 3.3), or 177 deprecated (e.g., the WKS RR TYPE [RFC1123]. Newer ideas and 178 requirements have identified a number of other features, some of 179 which were less developed than others. Of course the original 180 designers could not anticipate everything that has come to be 181 expected of the DNS in the last 30 years. 183 In recent years, demand for new and extended services and uses of the 184 DNS have, in turn, led to proposals for DNS extensions or changes of 185 various sorts. Some have been adopted, including a model for 186 negotiating extended functionality [RFC2671], others were found to be 187 impracticable, and still others continue to be under consideration. 188 A few features of the original DNS specification, such as the CLASS 189 property and label types, have also been suggested to be so badly 190 specified that they should be deprecated [Sullivan-Class]. 192 Unlike earlier changes such as the IDNA mechanisms for better 193 incorporating non-ASCII labels without modifying the DNS structure 194 itself [RFC3490] [RFC5890], some recent proposals require or strongly 195 suggest changes to APIs, formats, or interfaces by programs that need 196 to retrieve information from the DNS or interpret that information. 197 Differences between the DNS architecture and the requirements that 198 imply them suggest that it may be time to stop patching the DNS or 199 trying to extend it in small increments, but to consider moving some 200 functionality elsewhere or development of a new system that better 201 meets today's needs and a transition strategy to it. 203 The next section of this document discusses a number of issues with 204 the current DNS design that could appropriately be addressed by a 205 different and newer design model. In at least some cases, changing 206 the model and protocols could bring significant benefits to the 207 Internet and/or its administration. 209 This document is not a proposal for a new protocol. It is intended 210 to stimulate thought about how far we want to try to push the 211 existing DNS, to examine whether expectations of it are already 212 exceeding its plausible capabilities, and to start discussion of a 213 redesign or alternatives to one if the time for that decision has 214 come. 216 3. Warts and Tensions With The Current DNS 218 As suggested above, there are many signs that the DNS is incapable of 219 meeting contemporary expectations of how it should work and 220 functionality it should support. Some of those expectations are 221 unrealistic under any imaginable circumstances; others are impossible 222 (or merely problematic) in the current DNS structure but could be 223 accommodated in a redesign. These are examples, rather than a 224 comprehensive list, and do not appear in any particular order. 226 3.1. Multiple address types 228 While returning both TYPE A (IPv4 address) and AAAA (IPv6 address) 229 records as additional information in response to any of several query 230 types (see RFC 3596 [RFC3596]) was a useful patch, it is easy to 231 imagine better choices. For example, except that it would have 232 required DNS modifications, we could have established a single 233 "address" query type (QTYPE) that could return whatever IPv4 and/or 234 IPv6 addresses were available, perhaps with preference information if 235 that were stored in the database, and without requiring the "ANY" be 236 used. Other solutions would have been plausible; that one is offered 237 only to combine an existence proof of at least one possibility and an 238 example of how the existing DNS design and implementations are 239 preventing us from thinking more broadly about possible solutions. 241 3.2. Matching Part I: Case Sensitivity in Labels and Other Anomalies 243 The DNS specifications assume that labels are octet strings and 244 octets with the high bit zero have seven-bit ASCII codes in the 245 remaining bits. They require that, when a domain name used in a 246 query is matched to one stored in the database, those ASCII 247 characters be interpreted in a case-independent way, i.e., upper and 248 lower case letters are treated as equivalent (digits and symbols are 249 not affected) [RFC4343]. For non-ASCII octets, i.e., octets in 250 labels with the first bit turned on, there are no assumptions about 251 the character coding used, much less any rules about character case 252 equivalence -- strings must be compared by matching bits in sequence. 253 Even though the current model for handling non-ASCII (i.e., 254 "internationalized") domain name labels (IDNs) [RFC5890] (and see 255 Section 3.3 below) encodes information so the DNS is not directly 256 affected, the notion that some characters in labels are handled in a 257 case-insensitive way and that others are case-sensitive (or that 258 upper case must be prohibited entirely as IDNA does) has caused a 259 good deal of confusion and resentment. Those concerns and complaints 260 about inconsistent behavior and mishandling (or suboptimal handling) 261 of case relationships for some languages have not been mitigated by 262 repeated explanations that the relationships between "decorated" 263 lower-case characters and their upper-case equivalents are often 264 sensitive to language and locality and therefore not deterministic 265 with information available to DNS servers. 267 3.3. Matching Part II: Non-ASCII ("internationalized") Domain Name 268 Labels 270 Quite independent of the case-sensitivity problem, one of the 271 fundamental properties of Unicode [Unicode] is that some abstract 272 characters can be represented in multiple ways, such as by a single, 273 precomposed, code point or by a base code point followed by one or 274 more code points that specify combining characters. While Unicode 275 Normalization can be used to eliminate many (but not all) of those 276 distinctions for comparison (matching) purposes, it is best applied 277 during matching rather than by changing one string into another. The 278 first version of IDNA ("IDNA2003") made the choice to change strings 279 during processing for either storage or retrieval [RFC3490] 280 [RFC3491]; the second ("IDNA2008") required that all strings be 281 normalized and that upper case characters are not allowed at all 282 [RFC5891]. Neither is optimal, if only because, independent of where 283 they are changed if they are changed at all, transforming the strings 284 themselves implies that the input string in an application may not be 285 the same as the string used in processing and perhaps later display. 287 It would almost certainly be preferable, and more consistent with 288 Unicode recommendations, to use normalization (and perhaps other 289 techniques if they are appropriate) at matching time rather than 290 altering the strings at all, even if there were still only a single 291 matching algorithm, i.e., normalization were added to the existing 292 ASCII-only case folding. However, even Unicode's discussion of 293 normalization [Unicode-UAX15] indicates that there are special, 294 language-dependent, cases (the most commonly-cited example is the 295 dotless "i" (U+0131)). Not only does the DNS lack any information 296 about languages that could be used in a mapping algorithm, but, as 297 long as there is a requirement that there be only one mapping 298 algorithm for the entire system, that information could not be used 299 even if it were available. One could imagine a successor system that 300 would use information stored at nodes in the hierarchy to specify 301 different matching rules for subsidiary nodes (or equivalent 302 arrangements for non-hierarchical systems). It is not clear whether 303 that would be a good idea, but it certainly is not possible with the 304 DNS as we know it. 306 3.4. Matching Part III: Label Synonyms, Equivalent Names, and Variants 308 As the initial phases of work on IDNs started to conclude, it became 309 obvious that the nature and evolution of human language and writing 310 systems required treating some names as "the same as" others. The 311 first important example of this involved the relatively recent effort 312 to simplify the Chinese writing system, thereby creating a 313 distinction between "Simplified" and "Traditional" Chinese even 314 though the meaning of the characters remained the same in almost all 315 cases (in so-called ideographic character sets, characters have 316 meaning rather than representing sounds). A joint effort among the 317 relevant country code top level domain (TLD) registries and some 318 other interested parties produced a set of recommendations for 319 dealing with the issues with that script [RFC3743] and introduced the 320 concept of "variant" characters and domain names. 322 However, when names are seen as having meanings, rather than merely 323 being mnemonics, especially when they represent brands or the 324 equivalent, or when spelling for a particular written language is not 325 completely standardized, demands to treat different strings as exact 326 equivalents are obvious and inevitable. As a trivial English- 327 language example, it is widely understood that "colour" and "color" 328 represent the same word, so does that imply that, if they are used as 329 DNS labels in domain names all of whose other labels are identical, 330 the two domain names should be treated as identical? Examples for 331 other languages or writing systems, especially ones in which some or 332 all markings that distinguish characters or words by sound or tone or 333 that change the pronunciation of words are optional, are often more 334 numerous and more problematic than national spelling differences in 335 English, but they are harder to explain to those unfamiliar with 336 those other languages or writing systems (and hard to illustrate in 337 ASCII-only Internet-Drafts and RFCs). Although approximations are 338 possible, the DNS cannot handle that requirement: not only do its 339 aliasing mechanisms (CNAME, DNAME, and various proposals for newer 340 and different types of aliasing [DNS-Aliases] [DNS-BNAME], not 341 provide a strong enough binding, but the ability to use those aliases 342 from a subtree controlled by one administrative entity to that of 343 another one implies that there is little or no possibility of the 344 owner (in either the DNS sense or the registrar-registrant one) of a 345 particular name to control the synonyms for it. Some of that issue 346 can be dealt with at the application level, e.g., by redirects in web 347 protocols, but taking that approach, which is the essential 348 characteristic of "if both names belong to the same owner, everything 349 is ok" approaches, results in names being handled in inconsistent 350 ways in different protocols. 352 A different way of looking at part of this issue (and, to some 353 degree, of the one discussed above in Section 3.3) is that these 354 perceived equivalences and desired transformations are context- 355 dependent, but the DNS resolution process is not [RFC6912]. 357 Similar problems arise as people notice that some characters are 358 easily mistaken for others and that might be an opportunity for user 359 confusion and attacks. Commonly-cited examples include the Latin and 360 Cyrillic script "a" characters, which are identical [CACM-Homograph], 361 the characters in many scripts that look like open circles or 362 vertical or horizontal lines, and even the Latin script letter "l" 363 and the European digit "1", but examples abound in other scripts and 364 combinations of scripts as well. The most common proposed solution 365 within the DNS context has been to treat these cases, as well as 366 those involving orthographic variations, as "variants" (but variants 367 different from the system for Chinese characters mentioned above) and 368 either ban all but one (or a few) of the possible labels from the DNS 369 (possibly on a first come first served basis) or by ensuring that any 370 collection of such strings that are delegated as assigned to the same 371 ownership (see above). Neither solution is completely satisfactory: 372 if all but one string is excluded, users who guess at a different 373 form, perhaps in trying to transcribe characters from written or 374 printed form, don't find what they are looking for and, as pointed 375 out above, "same ownership" is sufficient only with carefully- 376 designed and administered applications protocol support and sometimes 377 not then. 379 Some of these issues are discussed at more length in an ICANN report 380 [ICANN-VIP]. 382 3.5. Query Privacy 384 There has been growing concern in recent years that DNS queries occur 385 in clear text on the public Internet and that, if those queries can 386 be intercepted, they can expose a good deal of information about 387 interests and contacts that could compromise individual privacy. 388 While a number of proposals, including query name minimization 389 [RFC7816] and running DNS over an encrypted tunnel [RFC7858], have 390 been made to mitigate that problem, they all appear to share the 391 common properties of security patches rather than designed-in 392 security or privacy mechanisms. While experience may prove otherwise 393 once (and if) they are widely deployed, it does not appear that any 394 of them are as satisfactory as a system with query privacy designed 395 in might be. More general tutorials on this issue have appeared 396 recently [Huston-DNSPrivacy]. 398 3.6. Alternate Name Spaces for Public Use in the DNS Framework: The 399 CLASS Problem 401 The DNS standards include specification of a CLASS value to "identify 402 a protocol family or instance of a protocol" [RFC 1034, Section 3.6 403 and elsewhere]. While CLASS was used effectively in the early days 404 of the DNS to manage different protocol families within the same 405 administrative environment, recent attempts to use it to either 406 partition the DNS namespace in other ways such as for non-ASCII names 407 (partially to address the issues in Section 3.2 Section 3.3) or to 408 use DNS mechanisms for entirely different namespaces have exposed 409 fundamental problems with the mechanism [Sullivan-Class], leading to 410 recommendations that it be dropped entirely. 412 Whether either the function CLASS was originally intended to provide 413 or the ones for which there have been attempts to use it more 414 recently are actually needed is a separate question; it is clear that 415 the current DNS technical and administrative model is unsuitable for 416 either function. 418 3.7. Loose Synchronization 420 The DNS model of master and slave servers, with the latter initiating 421 updates based on expiration interval values, and local caches with 422 updates based on TTL values, depends heavily on an approach that has 423 come to be called "loose synchronization", i.e., that there can be no 424 expectation that all of the servers that might reasonably answer a 425 query will have exactly the same data unless those data have been 426 unchanged for a rather long period. Put differently, if some or all 427 of the records associated with a particular node in the DNS 428 (informally, a fully-qualified domain name (FQDN)) change, one cannot 429 expect those changes to be propagated immediately. 431 That model has worked rather well since the DNS was first deployed, 432 protecting the system from requirements for mechanisms that are 433 typical where simultaneous update of multiple systems is needed. 434 Such mechanisms include elaborate locking, complex update procedures 435 and handshaking, or journaling. As has often been pointed out with 436 the Internet, implementation and operational complexity are often the 437 enemy of stability, security, and robustness. Loose synchronization 438 has helped keep the DNS as simple and robust as possible. 440 A number of recent ideas about using the DNS to store data for which 441 important changes occur very rapidly are, however, largely 442 incompatible with loose synchronization. Efforts to use very short 443 (or zero) refresh times (in SOA records for slave updates from 444 masters) and TTLs (for caches) to simulate nearly-simultaneous 445 updating may work up to a point but appear to impose very heavy loads 446 on servers and distribution mechanisms that were not designed to 447 accommodate that style of working. Similar observations can be made 448 about attempts to use the NOTIFY extension [RFC1996] or dynamic, 449 "server-push", updating rather than the traditional DNS mechanisms. 450 While the NOTIFY and push mechanisms normally provide refresh times 451 and update mechanisms faster than those specified in RFC 1034 and 452 1035, they imply that a "master" server must know the identities of 453 (and have good connectivity to all of) its slaves. That defeats at 454 least some of the advantages associated with stealth slaves, 455 particularly those associated with reduction of query traffic across 456 the Internet. Those mechanisms do nothing for cache updates: unless 457 servers keep track of the source of every query for names associated 458 with a specific zone and then somehow notify the query source 459 systems, the only alternative to having information that might be 460 obsolete stored in caches is to use very short or zero TTLs so the 461 cached data time out almost immediately after being stored (or are 462 not stored at all), requiring a new query to an authoritative server 463 each time a resolver attempts to look up a name. 465 3.8. Private Name Spaces and Special Names 467 Almost since the DNS was first deployed, there have been situations 468 in which it is desirable to use DNS-like names, and often DNS 469 resolution mechanisms or modifications of them, with name spaces for 470 which globally-available and consistent resolution using the public 471 DNS is either unfeasible or undesirable (and for which the use of 472 CLASS is not an appropriate mechanism). The need to isolate names 473 and addresses on LANs from the public Internet, typically via "split 474 horizon" approaches, is one example of this requirement although 475 often not recognized as such. Another example that has generated a 476 good deal of controversy involves "special names" -- labels or 477 pseudo-labels, often in TLD positions, that signal that the full name 478 should not be subject to normal DNS resolution or other processing 479 [RFC6761] [DNSOP-Sutld]. 481 Independent of troublesome policy questions about who should allocate 482 such names and the procedures to be used, they almost inherently 483 require either a syntax convention to identify them (there actually 484 was such a convention, but it was abandoned many years ago and there 485 is no plausible way to re-institute it) or tables of such names that 486 are known to, and kept updated on, every resolver on the Internet, at 487 least if spurious queries to the root servers are to be avoided. 489 If the DNS were to be redesigned and replaced, we could recognize 490 this requirement as part of the design and handle it much better than 491 it is possible to handle it today. 493 3.9. Alternate Query or Response Encodings 495 The DNS specifies formats for queries and data responses, based on 496 the state of the art and best practices at the time it was designed. 497 Recent work has suggested that there would be significant advantages 498 to supporting at least a description of the DNS messages in one or 499 more alternate formats, such as JSON [Hoffman-DNS-JSON] 500 [Hoffman-SimpleDNS-JSON]. While that work has been carefully done to 501 avoid requiring changes to the DNS, much of the argument for having 502 such a JSON-based description format could easily be turned into an 503 argument that, if the DNS were being revised, that format might be 504 preferable as a more direct alternative to having DNS queries and 505 responses in the original form. 507 3.10. Distribution and Managment of Root Servers 509 The DNS model requires a collection of root servers that hold, at 510 minimum, information about top-level domains. Over the years, that 511 requirement has evolved from a technically fairly minor function, 512 normally carried out as a service to the broader Internet community 513 and its users and systems, to a subject that is intensely 514 controversial with regard to control of those servers, including how 515 they should be distributed and where they should be located. While a 516 number of mechanisms have been proposed and one (anycast [RFC7094]) 517 is in very active use to mitigate some of the real and perceived 518 problems, it seems obvious that a DNS successor, designed for today's 519 global Internet and perceived requirements, could handle these 520 problems in a technically more appropriate and less controversial 521 way. 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 In the last decade or two, another perspective has emerged, largely 544 without being explicitly understood or acknowledged. In it, the DNS 545 is really (and primarily) a system for expressing thoughts and 546 concepts. Those include free expression of ideas in as close to 547 natural language as possible as well as representation of product 548 names and brands. That view requires letter-like characters that 549 might not be reasonable in identifiers along with a variety of 550 symbols and punctuation. It may also require indicators of preferred 551 type styles to provide information in a form that exactly matches 552 personal or legal preferences. At least it carried to an extreme, 553 that perspective would argue for standardizing word and sentence 554 separators, for removing the 63 octet per label limit and probably 555 the limit of 255 octets on the total length of a domain name, and 556 perhaps even eliminating the hierarchy or allowing separators for 557 labels in presentation form (now fixed at "." for the DNS) to be 558 different according to context. It suggests that, at least, the 559 original design was defective in not prioritizing those uses over the 560 more restrictive approach associated with prioritizing unique and 561 unambiguous identifiers. 563 So we have two, or, depending on how one counts, three very different 564 use cases. The historical one is support for unique identifiers. 565 The other is expression of ideas and, if one considers them separate, 566 presentation of brand and product names. Because they inherently 567 involve different constraints, priorities, and success criteria, 568 these perspectives are, at best, only loosely compatible. 570 We cannot simultaneously optimize both the identifier perspective and 571 either or both of the others in the same system. At best, there are 572 some complex trade-offs involved. Even then, it is not clear that 573 the same DNS (or other system) can accommodate all of them. Until we 574 come to terms with that, the differences manifest themselves with 575 friction among communities, most often with tension between "we want 576 to do (or use or sell) these types of labels" and "not good for the 577 operational Internet or the DNS". 579 3.12. A Single Hierarchy with a Centrally-controlled Root 581 A good many Internet policy discussions in the last two decades have 582 revolved around such questions of how many top level domains there 583 should be, what they should be, who should control them and how, how 584 (or if) their individual operations and policy decisions should be 585 accountable to others, and what processes should be used (and by what 586 entities or organizational structures) to make those decisions. 587 Several people have pointed out that, if we were designing a next- 588 generation DNS using today's technology, it should be possible to 589 remove the technical requirement for a central authority over the 590 root (some people have suggested that blockchain approaches would be 591 helpful for this purpose; others believe they just would not scale 592 adequately, at least at acceptable cost, but that other options are 593 possible). Whether elimination of a single, centrally-controlled, 594 root would be desirable or not is fairly obviously a question of 595 perspective and priorities. 597 3.13. Newer Application Protocols and New Requirements 599 New work done in other areas has led to demands for new DNS features, 600 many of them involving data values that require recursively 601 referencing the DNS. Early record types that did that were 602 accompanied by restrictions that reduced the risk of looping 603 references or other difficulties. For example, while the MX RRTYPE 604 has a fully-qualified domain name as its data, SMTP imposes "primary 605 name" restrictions that prevent the name used from being, e.g., a 606 CNAME. While loops with CNAMEs are possible, RFC 1034, Section 3.6, 607 includes a discussion about ways to avoid problems and how they 608 should be handled. Some newer protocols and conventions can cause 609 more stress. There are separate issues with additions and with how 610 the DNS has been extended to try to deal with them. 612 3.13.1. The Extensions 614 Some examples of DNS extensions for new protocol demands that 615 illustrate, or have led to, increased stress include: 617 NAPTR Requires far more complex data in the DNS for ENUM (e.g., 618 VoIP, specifically SIP) support, including URI information and 619 hence recursive or repeated lookups, than any of the RRTYPEs 620 originally supported. The RRSET associate with these records can 621 become quite large because the separator between the various 622 records is part of the RDATA, and not the {owner, class, type} 623 triple (a problem slightly related to the problem with overloading 624 of TXT RTYPE discussed in Section 3.13.2). This problem, and 625 similar ones for some of the cases below. may suggest that any 626 future design is in need of a different TYPE model such as 627 systematic arrangements for subtypes or some explicit hierarchy in 628 the TYPEs. 630 URI Has a URI as its data, typically also requiring recursive or 631 repeated lookups. 633 Service location (SRV) and credential information (including SPF and 634 DKIM) 635 Require structured data and, especially for the latter two, 636 significantly more data, than most original RRTYPEs. 638 URI/URL The early design decision for the World Wide Web that its 639 mechanism for identifying digital web content (now known as 640 Uniform Resource Identifiers [RFC3986]) did so by using domain 641 names and hence the network location of the information or other 642 material. That, in turn, has required systems intended to improve 643 web performance by locating and retrieving a "nearest copy" 644 (rather than the single copy designated by the URL) to intercept 645 DNS queries and respond with values that are not precisely those 646 stored for the designated domain name in the DNS or to otherwise 647 access information in a way not supported by the DNS itself. 649 In addition to the stresses these new functions cause, incremental 650 deployment of systems that utilize them means that some functions 651 will work in some environments and not others. This has been 652 especially problematic with complex, multi-record, functions like 653 DNSSEC that provide or require special validation mechanisms. 655 3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE 657 Unfortunately (but unsurprisingly) and despite IETF efforts to make 658 things easier [RFC6895], DNS support libraries have often been slow 659 to add full support for new RRTYPEs, impeding deployment of 660 applications that depend on them. Both to get faster deployment and, 661 at least until recently, to avoid burdensome IETF approval 662 procedures, many application designers have chosen to push protocol- 663 critical information into records with TXT RRTYPE, a record type that 664 was originally intended to include only information equivalent to 665 comments. 667 This causes two problems. First, TXT records used this way tend to 668 get long and complex, which is a problem in itself if one is trying 669 to minimize TCP connections. Second, applications that are 670 attempting to obtain data cannot merely ask for the relevant QTYPE, 671 they must obtain all of the records with QTYPE TXT and parse them to 672 determine which ones are of interest. That would be easier if there 673 was some standard for how to do that parsing but, at least in part 674 because the clear preference in the DNS design is for distinct 675 RRTYPEs for different kinds of information, there is no such standard 676 (there was a proposal in 1993 to structure the TXT DATA in a way that 677 would have addressed the issue [RFC1464] but it apparently never went 678 anywhere). 680 On the other hand, this issue is somewhat different from most of the 681 others described in this document because (as the IETF has 682 recommended several times) the problem is easily solved within the 683 current DNS design by allocating and supporting new RRTYPEs when 684 needed rather than using TXT as a workaround (that does not mean that 685 other solutions are impossible, either with the current DNS or some 686 other design). The problem then lies in the implementations and/or 687 mechanisms that deter or impede rapid deployment of support for new 688 RRTYPEs. 690 3.13.3. Periods and Zone Cut Issues 692 One of the DNS characteristics that is poorly understood by non- 693 experts is that the period (".", U+002E) character can be used in 694 three different ways: 696 o As a label separator in the presentation form that also designates 697 a "zone break" (delegation boundary). For example, 698 foo.bar.example.com indicates the owner, "foo", of records in the 699 "bar.example.com" zone. 701 o As a label separator in the presentation form that does not 702 designate a zone break. For example, foo.bar.example.com 703 indicates the owner, "foo.bar", of records in the "example.com" 704 zone. 706 o As a character within a label, including as a substitute for an 707 at-sign ("@") when an email address appears in an SOA record or in 708 a label that denotes such an address (see Section 2 above). 710 In general, these cases cannot be distinguished by looking at them. 711 The third is problematic for non-DNS reasons, e.g., 712 "john.doe.example.net" is ambiguous as to whether it should be 713 interpreted as a simple FQDN, as a notation for john.doe@example.net, 714 for john@doe.example.net, and so on. 716 The distinction between the first two cases was probably not 717 important as the DNS was originally intended to be used. However, as 718 soon as RRTYPEs (other than NS records that define the zone cut) are 719 used that are sensitive to the boundaries between zones, the 720 distinctions become important to people other than the relevant zone 721 administrators. DNSSEC involves one such set of relationships. It 722 increases the importance of questions about what should go in a 723 parent zone and what should go in child zones and how much difference 724 it makes if NS records in a parent zone for a child zone are 725 consistent with the records and data in the child zone. This also 726 causes application issues and may raise questions about relationships 727 between registrars and one or more registries or, if they are 728 separate, DNS operators. 730 3.14. Scaling of Reputation and Other Ancillary Information 732 The original design for DNS administration, reflected in RFC 1591 733 [RFC1591] and elsewhere, assumed that all domains would exhibit a 734 very high level of responsibility toward and for the community and 735 that level of responsibility would be enforced if necessary. More 736 recent decisions have taken things in the direction of "registrant 737 beware" and even "user and applications beware". While some recent 738 protocols and proposals at least partially reflect that original 739 model of a high level of responsibility (see, e.g., IDNA [RFC5890] 740 and the discussion in a recent Internet-Draft [Klensin-5891bis]), 741 other decisions and actions tend to shift responsibility to the 742 registrant or try to avoid accountability entirely. One possible 743 approach to the problems, especially security problems, that are 744 enabled by those new trends and the associated environment is to 745 establish reputation systems associated with clearly-defined 746 administrative boundaries and with warnings to users, even if those 747 reputation systems are managed by parties not directly associated 748 with the DNS. 750 The IETF DBOUND WG [IETF-DBOUND] addressed ways to establish and 751 document boundaries more precise than simple dependencies on TLDs but 752 it was not successful in producing a standard. 754 A TLD reputation-based approach was adopted by some web browsers 755 after IDNs and a growing number of gTLDs were introduced; that 756 approach was based on a simple list and does not scale to the current 757 size of the DNS or even the DNS root. 759 3.15. Tensions among transport, scaling and content 761 The original design for the DNS envisaged a simple query and response 762 protocol where both the command and the response could be readily 763 mapped into a single IP packet. The Hosts Requirement specification 764 [RFC1123] required all DNS applications to accept a UDP query or 765 response over UDP with up to 512 octets of DNS payload. TCP was seen 766 as a fallback when the response was greater than this 512 octet 767 limit, and this fallback to use TCP as the transport protocol was 768 considered to be the exception rather than the rule. 770 Over the intervening years we have seen the rise of a common 771 assumption of an Internet-wide Maximum Transmission Unit size of 772 1,500 octets, accompanied with an assumption that UDP fragmentation 773 is generally viable. This underpins the adoption of the Extended DNS 774 Options [RFC6891] to specify a UDP buffer size larger than 512 octets 775 and a suggestion within that specification to use 4,096 as a suitable 776 compromise as a UDP payload size. This has proved to be fortuitous 777 for the DNSSEC security extensions where the addition of DNSSEC 778 security credentials in DNS responses [RFC4034] can lead to the use 779 of large DNS responses. However, this exposes some tensions over the 780 handling of fragmentation in IP, where UDP fragments have been 781 observed to be filtered by various firewalls. Additionally for IPv6, 782 there are the factors of filtering of the ICMPv6 Packet Too Big 783 diagnostic messages, and discarding of IPv6 packets that contain 784 extension headers [RFC7872]. More generally, fragmented UDP packets 785 appear to have a lower level of reliability than unfragmented TCP 786 packets. 788 Behind this observation about relative reliability of delivery is the 789 tension between the lightweight load of UDP and the downside of 790 elevated probability of discarding of packet fragments as compared to 791 TCP, which offers increased levels of assurance of content delivery, 792 but with the associated imposition of TCP session state and the 793 downside of reduced DNS scalability and increased operational cost. 795 4. Searching and the DNS - An Historical Note 797 Some of the issues identified above might reasonably be addressed, 798 not by changing the DNS itself but by changing our model of what it 799 is about and how it is used. Specifically, one key assumption when 800 the DNS (and the host table system before it) was designed was that 801 it was a naming system for network resources, not, e.g., digital 802 content. As such, exact matching was important, it was reasonable to 803 have labels treated as mnemonics that did not necessarily have 804 linguistic or semantic meaning except to those using them, and so on. 805 A return to that model, presumably by having user-facing applications 806 call on an intermediate layer to disambiguate user-friendly names and 807 map them to DNS names (or network object locators more generally) 808 would significantly reduce stress on the DNS and would also allow 809 dealing with types of matching and similar or synonymous strings that 810 cannot be handled algorithmically no matter how much DNS matching 811 rules were altered. 813 In some respects, search engines based on free-text analysis and 814 linkages among information have come to serve many of the functions 815 of such an intermediate layer. Many studies and sources have pointed 816 out that few users actually understand, much less care about, the 817 distinction between a DNS name and a search term. Recent versions of 818 some web browsers have both recognized the failure of that 819 distinction and reinforced it by eliminating the separation between 820 "URL" and "search bar". 822 It is worth noting that, while that "search" approach, or some other 823 approach that abstracted and separated several of the issues 824 identified in Section 3 from the DNS protocol and database 825 themselves, it does not address all of them. At least some elements 826 of several of those issues, such as the synchronization ones 827 described in Section 3.7 and the transport ones described in 828 Section 3.15, are inherent in the DNS design and, if we are not going 829 to replace the DNS, we had best get used to them. 831 In the early part of the last decade, the IETF engaged in some 832 preliminary exploration of the intermediate layer approach in the 833 context of IDNs and what were then called "Internet keywords" 834 [DNS-search]. It may be time to examine that approach again and to 835 do so more deeply in the context of developments since the time of 836 that earlier work and the degree to which use of an intermediate 837 layer by appropriate user-facing applications might be used to 838 address some of the issues identified above. 840 5. Acknowledgements 842 Many of the concerns and ideas described in this document reflect 843 conversations over a period of many years, some rooted in DNS 844 "keyword" and "search" discussions that paralleled the development of 845 Internationalized Domain Names (IDNs). Conversations with, or 846 writings of, Rob Austein, Christine Borgman, Carolina Carvalho, Vint 847 Cerf, Lyman Chapin, Patrik Faltstrom, Geoff Huston, Gervase Markham, 848 Xiaodong Lee, Karen Liu, Yaqub Mueller, Andrew Sullivan, Paul Twomey, 849 Suzanne Woolf, Jiankang Yao, other participants in the circa 2003 850 "DNS Search" effort and in the ICANN SSAC Working Party on IDNs, and 851 some others whose names were sadly forgotten were particularly 852 important to either the content of this document or the motivation 853 for writing it even though they may not agree with the conclusions I 854 have reached and bear no responsibility for them. 856 Many of the subsections of Section 3 were extracted from comments 857 first made in conjunctions with recent email discussions. Comments 858 from Suzanne Woolf about an early draft were particularly important 859 as was material developed with suggestions from Patrik Faltstrom, 860 especially Section 3.13. Feedback and suggestions from several of 861 the above and from Stephane Bortzmeyer, Tony Finch, and George 862 Sadowsky were extremely helpful for improving the clarity and 863 accuracy of parts of the document, especially so for a broader 864 audience. Geoff Huston made several useful comments and contributed 865 most of Section 3.15. 867 6. IANA Considerations 869 [[CREF1: RFC Editor: Please remove this section before publication.]] 871 This memo includes no requests to or actions for IANA. 873 7. Security Considerations 875 From both security and privacy perspectives, a replacement for the 876 DNS would not have to go very far to be a significant improvement. 877 Even moving some functions out of the DNS that are now a poor fit 878 would provide significant opportunities for security and privacy 879 improvements. 881 8. References 883 8.1. Normative References 885 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 886 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 887 . 889 [RFC1035] Mockapetris, P., "Domain names - implementation and 890 specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, 891 November 1987, . 893 8.2. Informative References 895 [CACM-Homograph] 896 Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", 897 Communications of the ACM 45(2):128, February 2002, 898 . 901 [DNS-Aliases] 902 Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS 903 Resolution of Aliased Names", March 2011, 904 . 907 [DNS-BNAME] 908 Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name 909 Redirection", May 2016, . 912 [DNS-search] 913 IETF, "Internet Resource Name Search Service", 2003, 914 . 916 While it met several times informally and as one or more 917 BOFs, this effort never really got off the ground. That 918 was due in part to the IETF decision to go forward with 919 the IDNA approach and in part by signs that the "keyword" 920 efforts were beginning to fall apart. 922 [DNSOP-Sutld] 923 Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain 924 Names Problem Statement", June 2017, 925 . 928 [Hoffman-DNS-JSON] 929 Hoffman, P., "Representing DNS Messages in JSON", May 930 2017, . 933 [Hoffman-SimpleDNS-JSON] 934 Hoffman, P., "Simple DNS Queries and Responses in JSON", 935 June 2017, . 938 [Huston-DNSPrivacy] 939 Huston, G. and J. Silva Dama, "DNS Privacy", Internet 940 Protocol Journal Vol 20, No 1, March 2017, 941 . 944 [ICANN-VIP] 945 ICANN, "IDN Variant Issues Project: Final Integrated 946 Issues Report Published and Proposed Project Plan for Next 947 Steps is Now Open for Public Comment", February 2012, 948 . 950 [IETF-DBOUND] 951 IETF, "Domain Boundaries (dbound)", 2017, 952 . 954 [Klensin-5891bis] 955 Klensin, J., "Internationalized Domain Names in 956 Applications (IDNA): Registry Restrictions and 957 Recommendations", March 2017, 958 . 961 [NRC-Signposts] 962 National Research Council, "Signposts in Cyberspace: The 963 Domain Name System and Internet Navigation"", 2005, 964 . 968 [RFC0236] Postel, J., "Standard host names", RFC 236, 969 DOI 10.17487/RFC0236, September 1971, 970 . 972 [RFC0247] Karp, P., "Proffered set of standard host names", RFC 247, 973 DOI 10.17487/RFC0247, October 1971, 974 . 976 [RFC0799] Mills, D., "Internet name domains", RFC 799, 977 DOI 10.17487/RFC0799, September 1981, 978 . 980 [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD 981 Internet host table specification", RFC 810, 982 DOI 10.17487/RFC0810, March 1982, 983 . 985 [RFC0881] Postel, J., "Domain names plan and schedule", RFC 881, 986 DOI 10.17487/RFC0881, November 1983, 987 . 989 [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", 990 RFC 882, DOI 10.17487/RFC0882, November 1983, 991 . 993 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet 994 host table specification", RFC 952, DOI 10.17487/RFC0952, 995 October 1985, . 997 [RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, "Hostname 998 Server", RFC 953, DOI 10.17487/RFC0953, October 1985, 999 . 1001 [RFC0974] Partridge, C., "Mail routing and the domain system", 1002 STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, 1003 . 1005 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1006 Application and Support", STD 3, RFC 1123, 1007 DOI 10.17487/RFC1123, October 1989, 1008 . 1010 [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store 1011 Arbitrary String Attributes", RFC 1464, 1012 DOI 10.17487/RFC1464, May 1993, 1013 . 1015 [RFC1591] Postel, J., "Domain Name System Structure and Delegation", 1016 RFC 1591, DOI 10.17487/RFC1591, March 1994, 1017 . 1019 [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone 1020 Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, 1021 August 1996, . 1023 [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", 1024 RFC 2671, DOI 10.17487/RFC2671, August 1999, 1025 . 1027 [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, 1028 "Internationalizing Domain Names in Applications (IDNA)", 1029 RFC 3490, DOI 10.17487/RFC3490, March 2003, 1030 . 1032 [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep 1033 Profile for Internationalized Domain Names (IDN)", 1034 RFC 3491, DOI 10.17487/RFC3491, March 2003, 1035 . 1037 [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, 1038 "DNS Extensions to Support IP Version 6", RFC 3596, 1039 DOI 10.17487/RFC3596, October 2003, 1040 . 1042 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint 1043 Engineering Team (JET) Guidelines for Internationalized 1044 Domain Names (IDN) Registration and Administration for 1045 Chinese, Japanese, and Korean", RFC 3743, 1046 DOI 10.17487/RFC3743, April 2004, 1047 . 1049 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1050 Resource Identifier (URI): Generic Syntax", STD 66, 1051 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1052 . 1054 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1055 Rose, "Resource Records for the DNS Security Extensions", 1056 RFC 4034, DOI 10.17487/RFC4034, March 2005, 1057 . 1059 [RFC4343] Eastlake 3rd, D., "Domain Name System (DNS) Case 1060 Insensitivity Clarification", RFC 4343, 1061 DOI 10.17487/RFC4343, January 2006, 1062 . 1064 [RFC5890] Klensin, J., "Internationalized Domain Names for 1065 Applications (IDNA): Definitions and Document Framework", 1066 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1067 . 1069 [RFC5891] Klensin, J., "Internationalized Domain Names in 1070 Applications (IDNA): Protocol", RFC 5891, 1071 DOI 10.17487/RFC5891, August 2010, 1072 . 1074 [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", 1075 RFC 6761, DOI 10.17487/RFC6761, February 2013, 1076 . 1078 [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms 1079 for DNS (EDNS(0))", STD 75, RFC 6891, 1080 DOI 10.17487/RFC6891, April 2013, 1081 . 1083 [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA 1084 Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, 1085 April 2013, . 1087 [RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, 1088 "Principles for Unicode Code Point Inclusion in Labels in 1089 the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, 1090 . 1092 [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, 1093 "Architectural Considerations of IP Anycast", RFC 7094, 1094 DOI 10.17487/RFC7094, January 2014, 1095 . 1097 [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1098 Terminology", RFC 7719, DOI 10.17487/RFC7719, December 1099 2015, . 1101 [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve 1102 Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, 1103 . 1105 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., 1106 and P. Hoffman, "Specification for DNS over Transport 1107 Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 1108 2016, . 1110 [RFC7872] Gont, F., Linkova, J., Chown, T., and W. Liu, 1111 "Observations on the Dropping of Packets with IPv6 1112 Extension Headers in the Real World", RFC 7872, 1113 DOI 10.17487/RFC7872, June 2016, 1114 . 1116 [Sullivan-Class] 1117 Sullivan, A., "The DNS Is Not Classy: DNS Classes 1118 Considered Useless", July 2016, 1119 . 1122 [Unicode] The Unicode Consortium, "The Unicode Standard, Version 1123 9.0.0,", ISBN 978-1-936213-13-9, 2016, 1124 . 1126 [Unicode-UAX15] 1127 Davis, M. and K. Whistler, "Unicode Normalization Forms", 1128 February 2016, . 1130 [Unicode-USA31] 1131 Davis, M., "Unicode Identifier and Pattern Syntax", May 1132 2016, . 1134 Appendix A. Change Log 1136 RFC Editor: Please remove this appendix before publication. 1138 A.1. Changes from version -00 (2017-06-02) to -01 1140 o Many editorial corrections 1142 o Addition of new (some replacing prior placeholder) sections, 1143 especially to the list of issues with the current DNS design and 1144 notably including Section 3.13. 1146 A.2. Changes from version -01 (2017-06-06) to -02 1148 o Improved the discussion ins several sections, including a somewhat 1149 muddled description in Section 3.7 1151 o Revised the Introduction to make the context for this document 1152 somewhat more clear. 1154 o Added several more references even though still not nearly enough 1155 to make this document a comprehensive bibliography (which is not 1156 intended). 1158 o Many editorial corrections and a few added references. 1160 A.3. Changes from version -02 (2017-06-19) to -03 1162 o Added Section 3.15, discussing pressures less related to content, 1163 and smaller amounts of new material elsewhere. 1165 o Added some additional references and acknowledgments. 1167 o Extensive editorial corrections and revisions for clarity. 1169 Author's Address 1171 John C Klensin 1172 1770 Massachusetts Ave, Ste 322 1173 Cambridge, MA 02140 1174 USA 1176 Phone: +1 617 245 1457 1177 Email: john-ietf@jck.com