Network Working Group J. Klensin Internet-Draft June 19, 2017 Intended status: Informational Expires: December 21, 2017 DNS Privacy, Authorization, Special Uses, Encoding, Characters, Matching, and Root Structure: Time for Another Look? draft-klensin-dns-function-considerations-02 Abstract The basic design of the Domain Name System was completed almost 30 years ago. The last half of that period has been characterized by significant changes in requirements and expectations, some of which either require changes to how the DNS is used or that can be accommodated only poorly or not at all. This document asks the question of whether it is time to either redesign and replace the DNS to match contemporary requirements and expectations (rather than continuing to try to design and implement incremental patches that are not fully satisfactory) or to draw some clear lines about functionality that is not really needed or that should be performed somewhere else. Author's Note This draft is intended to draw a number of issues and references together in one place and to start a discussion. It is obviously incomplete, particularly with regard to the list of perceived issues and deficiencies with that DNS. To avoid misunderstanding, I don't completely believe some of the deficiencies listed below but am merely providing information about claims of deficiencies. Input is welcome, especially about what is missing (or plain wrong) and would be greatly appreciated. This document should be discussed on the IETF list or by private conversation with the author. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Klensin Expires December 21, 2017 [Page 1] Internet-Draft DNS Revisions June 2017 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 21, 2017. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background and Hypothesis . . . . . . . . . . . . . . . . . . 4 3. Warts and Tensions With The Current DNS . . . . . . . . . . . 5 3.1. Multiple address types . . . . . . . . . . . . . . . . . 5 3.2. Matching Part I: Case Sensitivity in Labels and Other Anomalies . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Matching Part II: Non-ASCII ("internationalized") Domain Name Labels . . . . . . . . . . . . . . . . . . . . . . . 6 3.4. Matching Part III: Label Synonyms, Equivalent Names, and Variants . . . . . . . . . . . . . . . . . . . . . . . . 7 3.5. Query Privacy . . . . . . . . . . . . . . . . . . . . . . 8 3.6. Alternate Name Spaces for Public Use in the DNS Framework: The CLASS Problem . . . . . . . . . . . . . . 9 3.7. Loose Synchronization . . . . . . . . . . . . . . . . . . 9 3.8. Private Name Spaces and Special Names . . . . . . . . . . 10 3.9. Alternate Query or Response Encodings . . . . . . . . . . 11 3.10. Distribution and Managment of Root Servers . . . . . . . 11 3.11. Identifiers Versus Brands and Other Convenience Names . . 11 3.12. A Single Hierarchy with a Centrally-controlled Root . . . 12 3.13. Newer Application Protocols and New Requirements . . . . 13 3.13.1. The Extensions . . . . . . . . . . . . . . . . . . . 13 3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE . . . . . . . . . . . . . . . . . . . . . . . 14 3.13.3. Periods and Zone Cut Issues . . . . . . . . . . . . 15 Klensin Expires December 21, 2017 [Page 2] Internet-Draft DNS Revisions June 2017 3.14. Scaling of Reputation and Other Ancillary Information . . 15 4. Searching and the DNS - An Historical Note . . . . . . . . . 16 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 18 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22 A.1. Changes from version -00 (2017-06-02) to -01 . . . . . . 22 A.2. Changes from version -01 (2017-06-06) to -02 . . . . . . 22 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document explores contemporary expectations of the Internet's domain system (DNS) and compares them to the assumptions and properties of the DNS design. It is primarily intended to ask the question of whether the differences are causing enough stresses on the system, stresses that cannot be resolved satisfactorily by further patching, that the Internet community should be considering designing a new system, one that is better adapted to current needs and expectations, and developing a deployment and transition strategy for it. For those (perhaps the majority of us) for whom actually replacing the DNS is too radical to be realistic, the document may be useful in two other ways. It may provide a foundation for discussing what functions the DNS should not be expected to support and how those functions can be supported in other ways, perhaps via an intermediate system that then calls on the DNS or by using some other type of database technology for some set of functions while leaving the basic DNS functions intact. Or it may provide a basis for "better just get used to that and the way it works" discussions to replace fantasies about what the DNS might do in some alternate reality. There is a key design or philosophical question associated with the analysis in this document that the document does not address. It is whether changes to perceived requirements to DNS functionality as described here are, in most respects, evolutionary or whether many of them are instances of trying to utilize the DNS for new requirements because it exists and is already deployed independent of whether the DNS is really appropriate or not. The latter might be an instance of a problem often described in the IETF as "when all you have is a hammer, everything looks like a nail". While this document does not assume deep technical or operational knowledge of the DNS, it does assume some knowledge and at least general familiarity with the concepts of RFC 1034 [RFC1034] and RFC Klensin Expires December 21, 2017 [Page 3] Internet-Draft DNS Revisions June 2017 1035 [RFC1035] and the terminology discussed in RFC 7719 [RFC7719] and elsewhere. Although some of the comments it contains might be taken as hints or examples of different ways to think about the design issues, it makes no attempt to explore, much less offer a tutorial on, alternate naming systems or database technologies. It is perhaps worth noting that, while the perspective is different and more than a dozen years have passed, many of the issues discussed in this document were analyzed and described (most of them with more extensive explanations) in a 2005 US National Research Council report [NRC-Signposts]. Readers should note that several references are to obsolete documents. That was done because they are intended to show the documents and dates that introduced particular features or concepts. When current versions are intended, they are referenced. 2. Background and Hypothesis The domain name system (DNS) [RFC1034] was designed starting in the early 1980s [RFC0799] [RFC0881] [RFC0882] with the main goal of replacing the flat, centrally-administered, host table system [RFC0810] [RFC0952] [RFC0953] with a hierarchical, administratively- distributed, system. The DNS design included some features that were judged to be unworkable and either replaced (e.g., the mail destination (MD) and mail forwarder (MF) approach [RFC0882] that were replaced by the MX approach [RFC0974]), abandoned (e.g., the mechanism for using email local parts as labels described in RFC 1034 Section 3.3), or deprecated (e.g., the WKS RR TYPE [RFC1123]. Newer ideas and requirements have identified a number of other features, some of which were less developed than others. Of course the original designers could not anticipate everything that has come to be expected of the DNS in the last 30 years. In recent years, demand for new and extended services and uses of the DNS have, in turn, led to proposals for DNS extensions or changes of various sorts. Some have been adopted, including a model for negotiating extended functionality [RFC2671], others were found to be impracticable, and still others continue to be under consideration. A few features of the original DNS specification, such as the CLASS property and label types, have also been suggested to be so badly specified that they should be deprecated [Sullivan-Class]. Unlike earlier changes such as the IDNA mechanisms for better incorporating non-ASCII labels without modifying the DNS structure itself [RFC3490] [RFC5890], some recent proposals require or strongly suggest changes to APIs, formats, or interfaces by programs that need to retrieve information from the DNS or interpret that information. Klensin Expires December 21, 2017 [Page 4] Internet-Draft DNS Revisions June 2017 Requirements for such changes suggest that it may be time to stop patching the DNS or trying to extend it in small increments, but to consider development of a system that better meets today's needs and a transition strategy to it. The next section of this document discusses a number of issues with the current DNS design that could appropriately be addressed by a different and newer design model. In at least some cases, changing the model and protocols could bring significant benefits to the Internet and/or its administration. This document is not a proposal for a new protocol. It is intended to stimulate thought about how far we want to try to push the existing DNS, to examine whether expectations of it are already exceeding its plausible capabilities, and to start discussion of a redesign or alternatives to one if the time for that discussion has come. 3. Warts and Tensions With The Current DNS As suggested above, there are many signs that the DNS is incapable of meeting contemporary expectations of how it should work and functionality it should support. Some of those expectations are unrealistic under any imaginable circumstances; others are impossible (or merely problematic) in the current DNS structure but could be accommodated in a redesign. These are examples, rather than a comprehensive list, and do not appear in any particular order. 3.1. Multiple address types While returning both TYPE A (IPv4 address) and AAAA (IPv6 address) records as additional information in response to any of several query types (see RFC 3596 [RFC3596]) was a useful patch, it is easy to imagine better choices. For example, except that it would have required DNS modifications, we could have established a single "address" query type (QTYPE) that could return whatever IPv4 and/or IPv6 addresses were available, perhaps with preference information if that were stored in the database, and without requiring the "ANY" be used. Other solutions would have been plausible; that one is offered only to combine an existence proof of at least one possibility and an example of how the existing DNS design and implementations are preventing us from thinking more broadly about possible solutions. 3.2. Matching Part I: Case Sensitivity in Labels and Other Anomalies The DNS specifications assume that labels are octet strings and octets with the high bit zero have seven-bit ASCII codes in the remaining bits. They require that, when a domain name used in a Klensin Expires December 21, 2017 [Page 5] Internet-Draft DNS Revisions June 2017 query is matched to one stored in the database, those ASCII characters be interpreted in a case-independent way, i.e., upper and lower case letters are treated as equivalent (digits and symbols are not affected). For non-ASCII octets, i.e., octets in labels with the first bit turned on, there are no assumptions about the character coding used, much less any rules about character case equivalence -- strings must be compared by matching bits in sequence. Even though the current model for handling non-ASCII (i.e., "internationalized") domain name labels (IDNs) [RFC5890] (and see Section 3.3 below) encodes information so the DNS is not directly affected, the notion that some characters in labels are handled in a case-insensitive way and that others are case-sensitive (or that upper case must be prohibited entirely as IDNA does) has caused a good deal of confusion and resentment. Those concerns about inconsistent behavior and mishandling (or suboptimal handling) of case relationships for some languages have not been mitigated by repeated explanations that the relationships between "decorated" lower-case characters and their upper-case equivalent are often sensitive to language and locality and therefore not deterministic with information available to DNS servers. 3.3. Matching Part II: Non-ASCII ("internationalized") Domain Name Labels Quite independent of the case-sensitivity problem, one of the fundamental properties of Unicode [Unicode] is that some abstract characters can be represented in multiple ways, such as by a single, precomposed, code point or by a base code point followed by one or more code points that specify combining characters. While Unicode Normalization can be used to eliminate many (but not all) of those distinctions for comparison (matching) purposes, it is best applied during matching rather than by changing one string into another. The first version of IDNA ("IDNA2003") made the choice to change strings during processing for either storage or retrieval [RFC3490] [RFC3491]; the second ("IDNA2008") required that all strings be normalized [RFC5891]. Neither is optimal, if only because transforming the strings themselves implies that the input string in an application may not be the same as the string used in processing and perhaps later display. It would almost certainly be preferable, and more consistent with Unicode recommendations, to use normalization (and perhaps other techniques) at matching time rather than altering the strings at all, even if there were still only a single matching algorithm, i.e., normalization were added to the existing ASCII-only case folding. However, even Unicode's discussion of normalization [Unicode-UAX15] indicates that there are special, language-dependent, cases (the most commonly-cited example is the dotless "i" (U+0131)). Not only does Klensin Expires December 21, 2017 [Page 6] Internet-Draft DNS Revisions June 2017 the DNS lack any information about languages that could be used in a mapping algorithm, but, as long as there is a requirement that there be only one mapping algorithm for the entire system, that information could not be used even if it were available. One could imagine a successor system that would use information stored at nodes in the hierarchy to specify different matching rules for subsidiary nodes (or equivalent arrangements for non-hierarchical systems). It is not clear whether that would be a good idea, but it certainly is not possible with the DNS as we know it. 3.4. Matching Part III: Label Synonyms, Equivalent Names, and Variants As the initial phases of work on IDNs started to conclude, it became obvious that the nature and evolution of human language and writing systems required treating some names as "the same as" others. The first important example of this involved the relatively recent effort to simplify the Chinese writing system, thereby creating a distinction between "Simplified" and "Traditional" Chinese even though the meaning of the characters remained the same in almost all cases (in so-called ideographic character sets, characters have meaning rather than representing sounds). A joint effort among the relevant country code top level domain (TLD) registries and some other interested parties produced a set of recommendations for dealing with the issues with that script [RFC3743] and introduced the concept of "variant" characters and domain names. However, when names are seen as having meanings, rather than merely being mnemonics, and especially when they represent brands or the equivalent, or when spelling for a particular written language is not completely standardized, there is an immediate demand to treat different strings as exact equivalents. As a trivial English- language example, it is widely understood that "colour" and "color" represent the same word, so does that imply that, if they are used as DNS labels in domain names all of whose other labels are identical, should the two domain names be treated as identical? Examples for other languages or writing systems, especially ones in which some or all markings that distinguish characters by sound or that change the pronunciation of words are optional, are often more numerous and more problematic than national spelling differences in English, but they are harder to explain to those unfamiliar with those other languages or writing systems (and hard to illustrate in ASCII-only Internet- Drafts and RFCs). Although approximations are possible, the DNS cannot handle that requirement: not only do its aliasing mechanisms (CNAME, DNAME, and various proposals for newer and different types of aliasing [DNS-Aliases] [DNS-BNAME], not provide a strong enough binding, but the ability to use those aliases from a subtree controlled by one administrative entity to that of another one, implies that there is little or no possibility of the owner (in Klensin Expires December 21, 2017 [Page 7] Internet-Draft DNS Revisions June 2017 either the DNS sense or the registrar-registrant one) of a particular name to control the synonyms for it. Some of that issue can be dealt with at the application level, e.g., by redirects in web protocols, but taking that approach, which is the essential characteristic of "if both names belong to the same owner, everything is ok" approaches, results in names being handled in inconsistent ways in different protocols. A different way of looking at part of this issue (and, to some degree, of the one discussed above in Section 3.3) is that these perceived equivalences and desired transformations are context- dependent, but the DNS resolution process is not [RFC6912]. Similar problems arise as people notice that some characters are easily mistaken for others and that might be an opportunity for user confusion and attacks. Commonly-cited examples include the Latin and Cyrillic script "a" characters, which are identical [CACM-Homograph], the characters in many scripts that look like open circles or vertical or horizontal lines, and even the Latin script letter "l" and the European digit "1", but examples abound in other scripts and combinations of scripts as well. The most common proposed solution within the DNS context has been to treat these cases, as well as those involving orthographic variations, as "variants" and either ban all but one (or a few) of the possible labels from the DNS (possibly on a first come first served basis) or by ensuring that any collection of such strings that are delegated as assigned to the same ownership (see above). Neither solution is completely satisfactory: if all but one string is excluded, users who guess at a different form, perhaps in trying to transcribe characters from written or printed form, don't find what they are looking for and, as pointed out above, "same ownership" is sufficient only with carefully- designed and administered applications protocol support and sometimes not then. Some of these issues are discussed at more length in an ICANN report [ICANN-VIP]. 3.5. Query Privacy There has been growing concern in recent years that DNS queries occur in clear text on the public Internet and that, if those queries can be intercepted, they can expose a good deal of information about interests and contacts that could compromise individual privacy. While a number of proposals, including query name minimization [RFC7816] and running DNS over an encrypted tunnel [RFC7858] have been made to mitigate that problem, they all appear to share the common properties of security patches rather than designed-in security or privacy mechanisms. While experience may prove otherwise Klensin Expires December 21, 2017 [Page 8] Internet-Draft DNS Revisions June 2017 once (and if) they are widely deployed, it does not appear that any of them are as satisfactory as a system with query privacy designed in might be. More general tutorials on this issue have appeared recently [Huston-DNSPrivacy]. 3.6. Alternate Name Spaces for Public Use in the DNS Framework: The CLASS Problem The DNS standards include specification of a CLASS value to "identify a protocol family or instance of a protocol" RFC 1034, Section 3.6 and elsewhere [RFC1034]. While it was used effectively in the early days of the DNS to manage different protocol families within the same administrative environment, recent attempts to use it to either partition the DNS namespace in other ways such as for non-ASCII names (partially to address the issues in Section 3.2 Section 3.3) or to use DNS mechanisms for entirely different namespaces have exposed fundamental problems with the mechanism [Sullivan-Class], leading to recommendations that it be dropped entirely. Whether either the function CLASS was originally intended to provide or the ones for which there have been attempts to use it more recently are actually needed is a separate question; it is clear that the current DNS technical and administrative model is unsuitable for either function. 3.7. Loose Synchronization The DNS model of master and slave servers, with the latter initiating updates based on TTL values, together with more local caches, depends heavily on an approach that has come to be called "loose synchronization", i.e., that there can be no expectation that all of the servers that might reasonably answer a query will have exactly the same data unless those data have been unchanged for a rather long period. Put differently, if some or all of the records associated with a particular node in the DNS (informally, a fully-qualified domain name (FQDN)) change, one cannot expect those changes to be propagated immediately. That model has worked rather well since the DNS was first deployed, protecting the system from requirements, that are typical where simultaneous update of multiple systems is needed, such as elaborate locking, complex update mechanisms, or journaling. As has often been pointed out with the Internet, implementation and operational complexity are often the enemy of stability, security, and robustness. Loose synchronization has helped keep the DNS as simple and robust as possible. Klensin Expires December 21, 2017 [Page 9] Internet-Draft DNS Revisions June 2017 A number of recent ideas about using the DNS to store data that change very rapidly and where the changes are important are, however, largely incompatible with loose synchronization. Efforts to use very short (or zero) refresh times (in SOA records for slave updates from masters) and TTLs (for caches) to simulate nearly-simultaneous updating may work up to a point but appear to impose very heavy loads on servers and distribution mechanisms that were not designed to accommodate that style of working. Similar observations can be made about attempts to use the NOTIFY extension [RFC1996] or dynamic, "server-push", updating rather than the traditional DNS mechanisms. While the NOTIFY and push mechanisms normally provide refresh times and update mechanisms faster than those specified in RFC 1034 and 1035, they imply that a "master" server must know the identities of (and have good connectivity to all of) its slaves, defeating at least some of the advantages associated with stealth slaves, particularly those associated with reduction of query traffic across the Internet. Those mechanisms do nothing for cache updates: unless servers keep track of every query for names associated with a specific zone and somehow notify the query source systems, the only alternative to having information that might be obsolete stored in caches is to use very short or zero TTLs so the cached data time out almost immediately after being stored (or are not stored at all), requiring a new query to an authoritative server each time a resolver makes a query. 3.8. Private Name Spaces and Special Names Almost since the DNS was first deployed, there have been situations in which it is desirable to use DNS-like names, and often DNS resolution mechanisms or modifications of them, with name spaces for which globally-available and consistent resolution using the public DNS is either unfeasible or undesirable (and for which the use of CLASS is not an appropriate mechanism). The need to isolate names and addresses on LANs from the public Internet, typically via "split horizon" approaches, is one example of this requirement although often not recognized as such. Another example that has generated a good deal of controversy involves "special names" -- labels or pseudo-labels, often in TLD positions, that signal that the full name should not be subject to normal DNS resolution or other processing [RFC6761] [DNSOP-Sutld]. Independent of troublesome policy questions about who should allocate such names and the procedures to be used, they almost inherently require either a syntax convention to identify them (there actually was such a convention, but it was abandoned many years ago and there is no plausible way to re-institute it) or tables of such names that are known to, and kept updated on, every resolver on the Internet, at least if spurious queries to the root servers are to be avoided. Klensin Expires December 21, 2017 [Page 10] Internet-Draft DNS Revisions June 2017 If the DNS were to be redesigned and replaced, we could recognize this requirement as part of the design and handle it much better than it is possible to handle it today. 3.9. Alternate Query or Response Encodings The DNS specifies formats for queries and data responses, based on the state of the art and best practices at the time it was designed. Recent work has suggested that there would be significant advantages to supporting at least a description of the DNS messages in one or more alternate formats, such as JSON [Hoffman-DNS-JSON] [Hoffman-SimpleDNS-JSON]. While that work has been carefully done to avoid requiring changes to the DNS, much of the argument for having such a JSON-based description format could easily be turned into an argument that, if the DNS were being revised, that format might be preferable as a more direct alternative to having DNS queries and responses in the original form. 3.10. Distribution and Managment of Root Servers The DNS model requires a collection of root servers that hold, at minimum, information about top-level domains. Over the years, that requirement has evolved from a technically fairly minor function, normally carried out as a service to the broader Internet community and its users and systems, to a subject that is intensely controversial with regard to who should control those servers, how they should be distributed and where they should be located. While a number of mechanisms have been proposed and one (anycast [RFC7094]) is in very active use to mitigate some of the real and perceived problems, it seems obvious that a DNS successor, designed for today's perceived requirements, could handle these problems in a technically more appropriate and less controversial way. 3.11. Identifiers Versus Brands and Other Convenience Names A key design element of the original network object naming systems for the ARPANET, largely inherited by the DNS, was that the names, while expected to be mnemonic, were identifiers and their being highly distinguishable and not prone to ambiguity was important. That led to very restrictive rules about what could appear in a name. In the case of the host table, the restrictions that came to the DNS (largely via SMTP) as the "preferred syntax" [RFC 1034 Section 3.5] or what we now often call the letter-digit-hyphen (LDH) rule. Similar rules to make identifiers easier to use, less prone to ambiguity, or less likely to interfere with syntax in more formal languages occur frequently. For example, almost every programming language has restrictions on what can appear in an identifier and Unicode provides general recommendations about identifier composition Klensin Expires December 21, 2017 [Page 11] Internet-Draft DNS Revisions June 2017 [Unicode-USA31]. Both are quite restrictive as compared to the number of characters and total number of strings that can be written using that character coding system. In the last decade or two, another perspective has emerged, largely without being explicitly understood or acknowledged. In it, the DNS is really (and primarily) a system for expressing thoughts and concepts. Those include free expression of ideas in as close to natural language as possible as well as representation of product names and brands. That view requires letter-like characters that might not be reasonable in identifiers along with a variety of symbols and punctuation and might require indicators of preferred type styles to provide information in a form that exactly matches personal or legal preferences. That perspective would argue for standardizing word and sentence separators, removing the 63 octet per label limit and probably the limit of 255 octets on the total length of a domain name, and maybe even eliminating the hierarchy or allowing separators for labels in presentation form (now fixed at "." for the DNS) to be different according to context. At least it suggests that the original design was defective in not prioritizing those uses over support for unique and unambiguous identifiers. So we have two, or, depending on how one counts, three very different use cases. The historical one is support for unique identifiers. The other is expression of ideas and, if one considers it separate, presentation of brand and product names. Because they inherently involve different constraints, priorities, and success criteria, these perspectives are, at best, only loosely compatible. We cannot simultaneously optimize both the identifier perspective and either or both of the others in the same system. At best, there are some complex trade-offs involved. Even then, it is not clear that the same DNS (or other system) can accommodate all of them. Until we come to terms with that, the differences manifest themselves with friction among communities, most often with tension between "we want to do (or use or sell) these types of labels" and "not good for the operational Internet or the DNS". 3.12. A Single Hierarchy with a Centrally-controlled Root A good many Internet policy discussions in the last two decades have revolved around such questions of how many top level domains there should be and what they should be, who should control them and how, how (or if) their individual operations and policy decisions should be accountable to others, and what processes should be used (and by what entities or organizational structures) to make those decisions. Several people have pointed out that, if we were designing a next- generation DNS using today's technology, it should be possible to Klensin Expires December 21, 2017 [Page 12] Internet-Draft DNS Revisions June 2017 remove the technical requirement for a central authority over the root (some people have suggested that blockchain approaches would be helpful for this purpose; others believe they just would not scale adequately, at least at acceptable cost). Whether that would be desirable or not is fairly obviously a question of perspective and priorities. 3.13. Newer Application Protocols and New Requirements New work done in other areas has led to demands for new DNS features, many of them involving data values that require recursively referencing the DNS. Early record types that did that were accompanied by restrictions that reduced the risk of looping references or other difficulties. For example, while the MX RRTYPE has a fully-qualified domain name as its data, SMTP imposes "primary name" restrictions that prevent the name used from being, e.g., a CNAME. While loops with CNAMEs are possible, RFC 1034, Section 3.6, includes a discussion about ways to avoid problems and how they should be handled. Some newer protocols and conventions can cause more stress. There are separate issues with additions and with how the DNS has been extended to try to deal with them. 3.13.1. The Extensions Some examples of DNS extensions for new protocol demands that illustrate, or have led to, increased stress include: NAPTR Requires far more complex data in the DNS for ENUM (e.g., VoIP and SIP) support, including URI information and hence recursive or repeated lookups, than any of the RRTYPEs originally supported. The RRSET associate with these records can become quite large becaues the separator between the various records is part of the RDATA, and not the {owner, class, type} triple (a problem slightly related to the problem with overloading of TXT RTYPE discussed in Section 3.13.2. This problem, and similar ones for some of the cases below. may suggest that any future design is in need of a different TYPE model such as systematic arrangements for subtypes or some explicit hierarchy in the TYPEs. URI Has a URI as its data, typically also requiring recursive or repeated lookups. Service location (SRV) and credential information (including SPF) Require structured data and, especially for the later, significantly more data, than most original RRTYPEs. URI/URL The early design decision for the World Wide Web that its mechanism for identifying digital web content (now known as Klensin Expires December 21, 2017 [Page 13] Internet-Draft DNS Revisions June 2017 Uniform Resource Identifiers [RFC3986]) did so by using domain names and hence the network location of the information or other material. That, in turn, has required systems intended to improve web performance by locating and retrieving a "nearest copy" rather than the single copy designated by the URL to intercept DNS queries and respond with values that are not precisely those stored for the designated domain name in the DNS or to otherwise access information in a way not supported by the DNS itself. In addition to the stresses these new functions cause, incremental deployment of systems that utilize them means that some functions will work in some environments and not others. This has been especially problematic with complex, multi-record, functions like DNSSEC that provide or require special validation mechanisms such as DNNSEC. 3.13.2. Extensions and Deployment Pressures -- The TXT RRTYPE Unfortunately (but unsurprisingly) and despite IETF efforts to make things easier [RFC6895], DNS support libraries have often been slow to add full support for new RRTYPEs, impeding deployment of applications that depend on them. Both to get faster deployment and, at least until recently, to avoid burdensome IETF approval procedures, many application designers have chosen to push protocol- critical information into records with TXT RRTYPE, a record type that was originally intended to include only information equivalent to comments. This causes two problems. First, TXT records used this way tend to get long and complex, which is a problem in itself if one is trying to minimize TCP connections. Second, applications that are attempting to obtain data cannot merely ask for the relevant QTYPE, they must obtain all of the records with QTYPE TXT and parse them to determine which ones are of interest. That would be easier if there was some standard for how to do that parsing but, at least in part because the clear preference in the DNS design is for distinct RRTYPEs for different kinds of information, there is no such standard. On the other hand, this issue is somewhat different from most of the others described in this document because (as the IETF has recommended several times) the problem is easily solved within the current DNS design by allocating and supporting new RRTYPEs when needed rather than using TXT as a workaround (that does not mean that other solutions are impossible, either with the current DNS or some other design). The problem then lies in the implementations and/or mechanisms that deter or impede rapid deployment of support for new RRTYPEs. Klensin Expires December 21, 2017 [Page 14] Internet-Draft DNS Revisions June 2017 3.13.3. Periods and Zone Cut Issues One of the DNS characteristics that is poorly understood by non- experts is that the period (".", U+002E) character can be used in three different ways: o As a label separator in the presentation form that also designates a "zone break" (delegation boundary). For example, foo.bar.example.com indicates the owner, "foo", of records in the "bar.example.com" zone. o As a label separator in the presentation form that does not designate a zone break. For example, foo.bar.example.com indicates the owner, "foo.bar", of records in the "example.com" zone. o As a character within a label, including as a substitute for an at-sign ("@") when an email address appears in an SOA record or in a label that denotes such an address (see Section 2). In general, these cases cannot be distinguished by looking at them. The third is problematic for non-DNS reasons, e.g., "john.doe.example.net" is ambiguous as to whether it should be interpreted as a simple FQDN, as a notation for john.doe@example.net, for john@doe.example.net, and so on. The distinction between the first two cases was probably not important as the DNS was originally intended to be used. However, as soon as RRTYPEs (other than NS records that define the zone cut) are used that are sensitive to the boundaries between zones, the distinctions become important to people other than the relevant zone administrators. DNSSEC involves one such set of relationships. It increases the importance of questions about what should go in a parent zone and what should go in child zones and how much difference it makes if NS records in a parent zone for a child zone are consistent with the records and data in the child zone. This also causes application issues, may raise questions about relationships between registrars and one or more registries or, if they are separate, DNS operators. 3.14. Scaling of Reputation and Other Ancillary Information The original design for DNS administration, reflected in RFC 1591 [RFC1591] and elsewhere, assumed that all domains would exhibit a very high level of responsibility toward and for the community and that level of responsibility would be enforced if necessary. More recent decisions have taken things in the direction of "registrant beware" and even "user and applications beware" even some recent Klensin Expires December 21, 2017 [Page 15] Internet-Draft DNS Revisions June 2017 protocols at least partially reflect the original model (see, e.g., IDNA [RFC5890] and the discussion in a recent Internet-Draft [Klensin-5891bis]. One possible approach to the problems, especially security problems, that are enabled by the new environment is to establish reputation systems associated with clearly-defined administrative boundaries and with warnings to users. The IETF DBOUND WG [IETF-DBOUND] addressed ways to establish and document boundaries more precise than simple dependencies on TLDs but it was not successful in producing a standard. A TLD reputation-based approach was adopted by some web browsers after IDNs and a growing number of gTLDs were introduced; that approach was based on a simple list and does not scale to the current size of the DNS or even the DNS root. 4. Searching and the DNS - An Historical Note Some of the issues identified above might reasonably be addressed, not by changing the DNS itself but by changing our model of what it is about and how it is used. Specifically, one key assumption when the DNS (and the host table system before it) was designed was that it was a naming system for network resources, not, e.g., digital content. As such, exact matching was important, it was reasonable to have labels treated as mnemonics that did not necessarily have linguistic or semantic meaning except to those using them, and so on. A return to that model, presumably by having user-facing applications call on an intermediate layer to disambiguate user-friendly names and map them to DNS names (network object locators) would significantly reduce stress on the DNS and would also allow dealing with types of matching and similar or synonymous strings that cannot be handled algorithmically no matter how much DNS matching rules were altered. In the early part of the last decade, the IETF explored that approach a little bit in the context of IDNs and what were then called "Internet keywords" [DNS-search]. It may be time to look at that approach again and more deeply in the context of more recent developments. It is worth noting that, while that "search" approach, or some other approach that abstracted and separated several of the issues identified in Section 3 from the DNS protocol and database themselves, it does not address all of them. At least some elements of several of those issues, such as the synchronization ones described in Section 3.7, are inherent in the DNS design and, if we are not going to replace the DNS, we had best get used to them. Klensin Expires December 21, 2017 [Page 16] Internet-Draft DNS Revisions June 2017 5. Acknowledgements Many of the concerns and ideas described in this document reflect conversations over a period of many years, some rooted in DNS "keyword" and "search" discussions that paralleled the development of Internationalized Domain Names (IDNs). Conversations with, or writings of, Rob Austein, Christine Borgman, Carolina Carvalho, Vint Cerf, Lyman Chapin, Patrik Faltstrom, Geoff Huston, Xiaodong Lee, Karen Liu, Yaqub Mueller, Andrew Sullivan, Paul Twomey, Suzanne Woolf, Jiankang Yao, other participants in the circa 2003 "DNS Search" effort and in the ICANN SSAC Working Party on IDNs, and some others whose names were sadly forgotten were particularly important to either the content of this document or the motivation for writing it even though they may not agree with the conclusions I have reached and bear no responsibility for them. Many of the subsections of Section 3 were extracted from comments first made in conjunctions with recent email discussions. Comments from Suzanne Woolf about an early draft were particularly important as was material developed with suggestions from Patrik Faltstrom, especially Section 3.13. Feedback and suggestions from several of the above and from Stephane Bortzmeyer, Tony Finch, and George Sadowsky were extremely helpful for improving the clarity and accuracy of parts of the document, especially so for a broader audience. 6. IANA Considerations [[CREF1: RFC Editor: Please remove this section before publication.]] This memo includes no requests to or actions for IANA. 7. Security Considerations From both security and privacy perspectives, a replacement for the DNS would not have to go very far to be a significant improvement. 8. References 8.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, . Klensin Expires December 21, 2017 [Page 17] Internet-Draft DNS Revisions June 2017 8.2. Informative References [CACM-Homograph] Gabrilovich, E. and A. Gontmakher, "The Homograph Attack", Communications of the ACM 45(2):128, February 2002, . [DNS-Aliases] Woolf, S., Lee, X., and J. Yao, "Problem Statement: DNS Resolution of Aliased Names", March 2011, . [DNS-BNAME] Yao, J., Lee, X., and P. Vixie, "Bundled DNS Name Redirection", May 2016, . [DNS-search] IETF, "Internet Resource Name Search Service", 2003, . While it met several times informally and as one or more BOFs, this effort never really got off the ground. That was due in part to the IETF decision to go forward with the IDNA approach and in part by signs that the "keyword" efforts were beginning to fall apart. [DNSOP-Sutld] Lemon, T., Droms, R., and W. Kumari, "Special-Use Domain Names Problem Statement", June 2017, . [Hoffman-DNS-JSON] Hoffman, P., "Representing DNS Messages in JSON", May 2017, . [Hoffman-SimpleDNS-JSON] Hoffman, P., "Simple DNS Queries and Responses in JSON", June 2017, . Klensin Expires December 21, 2017 [Page 18] Internet-Draft DNS Revisions June 2017 [Huston-DNSPrivacy] Huston, G. and J. Silva Dama, "DNS Privacy", Internet Protocol Journal Vol 20, No 1, March 2017, . [ICANN-VIP] ICANN, "IDN Variant Issues Project: Final Integrated Issues Report Published and Proposed Project Plan for Next Steps is Now Open for Public Comment", February 2012, . [IETF-DBOUND] IETF, "Domain Boundaries (dbound)", 2017, . [Klensin-5891bis] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Registry Restrictions and Recommendations", March 2017, . [NRC-Signposts] National Research Council, "Signposts in Cyberspace: The Domain Name System and Internet Navigation"", 2005, . [RFC0799] Mills, D., "Internet name domains", RFC 799, DOI 10.17487/RFC0799, September 1981, . [RFC0810] Feinler, E., Harrenstien, K., Su, Z., and V. White, "DoD Internet host table specification", RFC 810, DOI 10.17487/RFC0810, March 1982, . [RFC0881] Postel, J., "Domain names plan and schedule", RFC 881, DOI 10.17487/RFC0881, November 1983, . [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, DOI 10.17487/RFC0882, November 1983, . Klensin Expires December 21, 2017 [Page 19] Internet-Draft DNS Revisions June 2017 [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, . [RFC0953] Harrenstien, K., Stahl, M., and E. Feinler, "Hostname Server", RFC 953, DOI 10.17487/RFC0953, October 1985, . [RFC0974] Partridge, C., "Mail routing and the domain system", STD 10, RFC 974, DOI 10.17487/RFC0974, January 1986, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC1591] Postel, J., "Domain Name System Structure and Delegation", RFC 1591, DOI 10.17487/RFC1591, March 1994, . [RFC1996] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996, August 1996, . [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, DOI 10.17487/RFC2671, August 1999, . [RFC3490] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, DOI 10.17487/RFC3490, March 2003, . [RFC3491] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, DOI 10.17487/RFC3491, March 2003, . [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, DOI 10.17487/RFC3596, October 2003, . Klensin Expires December 21, 2017 [Page 20] Internet-Draft DNS Revisions June 2017 [RFC3743] Konishi, K., Huang, K., Qian, H., and Y. Ko, "Joint Engineering Team (JET) Guidelines for Internationalized Domain Names (IDN) Registration and Administration for Chinese, Japanese, and Korean", RFC 3743, DOI 10.17487/RFC3743, April 2004, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC6761] Cheshire, S. and M. Krochmal, "Special-Use Domain Names", RFC 6761, DOI 10.17487/RFC6761, February 2013, . [RFC6895] Eastlake 3rd, D., "Domain Name System (DNS) IANA Considerations", BCP 42, RFC 6895, DOI 10.17487/RFC6895, April 2013, . [RFC6912] Sullivan, A., Thaler, D., Klensin, J., and O. Kolkman, "Principles for Unicode Code Point Inclusion in Labels in the DNS", RFC 6912, DOI 10.17487/RFC6912, April 2013, . [RFC7094] McPherson, D., Oran, D., Thaler, D., and E. Osterweil, "Architectural Considerations of IP Anycast", RFC 7094, DOI 10.17487/RFC7094, January 2014, . [RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", RFC 7719, DOI 10.17487/RFC7719, December 2015, . [RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016, . Klensin Expires December 21, 2017 [Page 21] Internet-Draft DNS Revisions June 2017 [RFC7858] Hu, Z., Zhu, L., Heidemann, J., Mankin, A., Wessels, D., and P. Hoffman, "Specification for DNS over Transport Layer Security (TLS)", RFC 7858, DOI 10.17487/RFC7858, May 2016, . [Sullivan-Class] Sullivan, A., "The DNS Is Not Classy: DNS Classes Considered Useless", July 2016, . [Unicode] The Unicode Consortium, "The Unicode Standard, Version 9.0.0,", ISBN 978-1-936213-13-9, 2016, . [Unicode-UAX15] Davis, M. and K. Whistler, "Unicode Normalization Forms", February 2016, . [Unicode-USA31] Davis, M., "Unicode Identifier and Pattern Syntax", May 2016, . Appendix A. Change Log RFC Editor: Please remove this appendix before publication. A.1. Changes from version -00 (2017-06-02) to -01 o Many editorial corrections o Addition of new (some replacing prior placeholder) sections, especially to the list of issues with the current DNS design and notably including Section 3.13. A.2. Changes from version -01 (2017-06-06) to -02 o Improved the discussion ins several sections, including a somewhat muddled description in Section 3.7 o Revised the Introduction to make the context for this document somewhat more clear. o Added several more references even though still not nearly enough to make this document a comprehensive bibliography (which is not intended). o Many editorial corrections and a few added references. Klensin Expires December 21, 2017 [Page 22] Internet-Draft DNS Revisions June 2017 Author's Address John C Klensin 1770 Massachusetts Ave, Ste 322 Cambridge, MA 02140 USA Phone: +1 617 245 1457 Email: john-ietf@jck.com Klensin Expires December 21, 2017 [Page 23]