Network Working Group O. Kolkman Internet-Draft NLNet Intended status: Informational J. Peterson Expires: January 12, 2012 NeuStar, Inc. H. Tschofenig Nokia Siemens Networks B. Aboba Microsoft Corporation July 11, 2011 Architectural Considerations on Application Features in the DNS draft-iab-dns-applications-02 Abstract A number of Internet applications have integrated supplemental features into the Domain Name System (DNS) to support their operations. Many of these features assist in locating the appropriate service in a domain, or in transforming intermediary identifiers into names that the DNS can process. Proposals to incorporate more sophisticated application behavior into the DNS, however, have raised questions about the applicability and extensibility of the DNS. This document explores the architectural consequences of installing certain application features in the DNS, and provides guidance to future application designers. 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/. 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 January 12, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Kolkman, et al. Expires January 12, 2012 [Page 1] Internet-Draft Applications in DNS July 2011 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Kolkman, et al. Expires January 12, 2012 [Page 2] Internet-Draft Applications in DNS July 2011 Table of Contents 1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview of DNS Application Usages . . . . . . . . . . . . . . 6 2.1. Locating Services in a Domain . . . . . . . . . . . . . . 6 2.2. NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . . 7 2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9 3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 10 3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 10 3.1.1. Responses Tailored to the Originator . . . . . . . . . 11 3.2. Metadata about Tree Structure . . . . . . . . . . . . . . 13 3.3. Using DNS as a Generic Database . . . . . . . . . . . . . 13 3.3.1. Large Data in the DNS . . . . . . . . . . . . . . . . 14 3.4. Administrative Structures Misaligned with the DNS . . . . 15 3.5. Domain Redirection . . . . . . . . . . . . . . . . . . . . 15 4. Principles and Guidance . . . . . . . . . . . . . . . . . . . 17 4.1. Private DNS Deployments . . . . . . . . . . . . . . . . . 18 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. Informative References . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 Kolkman, et al. Expires January 12, 2012 [Page 3] Internet-Draft Applications in DNS July 2011 1. Motivation The Domain Name System (DNS) has long provided a general means of translating easily-memorized domain names into numeric Internet Protocol addresses, which makes the Internet easier to use by providing a valuable layer of indirection between well-known names and lower-layer protocol elements. [RFC0974] documented a further use of the DNS: to manage application services operating in a domain with the Mail Exchange (MX) resource record, which helped email addressed to the domain to find an authoritative mail service for the domain. The seminal MX record served as a prototype for a long series of DNS resource records that supported applications associated with a domain name. The SRV resource record [RFC2052] provided a more general mechanism for locating services in a domain, complete with a weighting system and selection among transports. The Naming Authority Pointer (NAPTR, originally [RFC2168]) resource record, especially in its reincarnation as the Dynamic Delegation Discovery System (DDDS, [RFC3401] passim) framework, added a new wrinkle - an algorithm for transforming a string into a domain name, which might then be resolved by the DNS to find NAPTR records. This enabled the resolution of identifiers that do not have traditional host components through the DNS; the best-known example of this are telephone numbers, as resolved by the DDDS application ENUM. Recent work such as DomainKeys Identified Mail (DKIM, [RFC4871]) has enabled security features of applications to be advertised through the DNS, via the TXT resource record. As the amount of application intelligence available to the DNS has increased, however, some proposed usages and extensions have become misaligned with both the architecture and underlying protocols of the DNS. In the global public DNS, for example, the resolution of domain names to IP addresses is public information with no need for confidentiality, and thus the underlying query/response protocol has no authentication or encryption mechanism - typically, any security required by an application or service is invoked after the DNS query, when the resolved service has been contacted. Only in private DNS environments (including split horizon DNS) where the identity of the querier is assured through some external means does the DNS maintain confidential records in this sense - although for load balancing reasons, localization or related optimizations, the public DNS may return different addresses in response to queries from different sources, or even no response at all, which is discussed further in Section 3.1.1. To take another example, the query/response protocol of the DNS assumes queries for a single name, and requires significant extension to support queries that cover ranges of names or scan for names matching certain criteria. Applications in many Kolkman, et al. Expires January 12, 2012 [Page 4] Internet-Draft Applications in DNS July 2011 environments require these sorts of features from databases, and as the features of the DNS have increased, some application protocols have looked to leverage the DNS for databases that include these capabilities. This document therefore provides guidance to designers of applications and application protocols on the use or extension of the DNS to provide features to applications. It offers an overview of ways that applications have used the DNS in the past, as well as proposed ways that applications could use the DNS that raise concerns. It gives some reasons to decide the question, "Should I store this information in the DNS, or use some other means?" when that question arises during protocol development. These guidelines remind application protocol designers of the strengths and weaknesses of the DNS in order to make it easier for designers to decide what features the DNS should provide for their application. The guidance in this document complements the guidance on extending the DNS given in [RFC5507]. Whereas [RFC5507] considers the preferred ways to add new information to the underlying syntax of the DNS (such as defining new resource records or adding prefixes or suffixes to labels), the current document considers broader implications of offloading application features to the DNS, be it through extending the DNS or simply reusing existing protocol capabilities - implications that may concern the behavior of name servers, resolvers or caches, the DNS protocol, security or the overall architecture. Kolkman, et al. Expires January 12, 2012 [Page 5] Internet-Draft Applications in DNS July 2011 2. Overview of DNS Application Usages [RFC0882] identifies the original and fundamental connection between the DNS and applications. It begins by describing how the interdomain scope of applications creates "formidable problems when we wish to create consistent methods for referencing particular resources that are similar but scattered throughout the environment." This motivated "the need to have a mapping between host names... and ARPA Internet addresses" move away from a global table (the original "hosts.txt" file) and to a "distributed database that performs the same function." RFC0822 also envisioned some ways to find the resources associated with mailboxes in a domain: without these extensions, a user trying to send mail to a foreign domain lacked a discovery mechanism to locate the right host in the remote domain to which to connect to for mail. While a special-purpose discovery mechanism could be built by each such application protocol that needed this functionality, the universality of the DNS invites installing these features into its public tree. Over time, several other applications leveraged resource records for locating services in a domain or for storing application data associated with a domain in the DNS. This section gives on overview of such application usage to date. 2.1. Locating Services in a Domain The MX resource record provides the simplest motivating example for an application advertising its resources in the Domain Name System. The MX resource record contains the domain name of a server within the administrative domain in question that receives mail; that domain name must itself be resolved to one or more IP addresses through the DNS in order to reach the mail server. While naming conventions for applications might serve a similar purpose (a host might be named "mail.example.com" for example), approaching service location through the creation of a new resource record yields important benefits. For example, one can put multiple MX records in a zone, in order to designate backup resources or to load balance across several such servers (see [RFC1794]); these properties could not easily be captured by naming conventions (see [RFC4367]). While the MX record represents a substantial improvement over naming conventions as a means of service location, it remains specific to a single application. Thus, the general approach of the MX record was adapted to fit a broader class of application through the Service (SRV) resource record (originally [RFC2052]). The SRV record allows DNS resolvers to query for particular services and underlying transports (for example, HTTP running over TLS, see [RFC2818]) and to learn a host name and port where that service resides in a given Kolkman, et al. Expires January 12, 2012 [Page 6] Internet-Draft Applications in DNS July 2011 domain. It also provides a weighting mechanism to allow load balancing across several instances of a service. The reliance of applications on the existence of MX and SRV records has important implications for the way that applications manage identifiers. Email identifiers of the form "user@domain" require the presence of something like MX records to provide the convenience of simply specifying that "domain" component rather than a "host.domain" structure. While for applications like HTTP, naming conventions continue to abound ("www.example.com"), the SRV algorithm queries for an application-specific label combining the protocol and transport. For a protocol like HTTP, the SRV service name derives corresponds to the URL scheme of the identifier invoked by the application ("_http._tcp.example.com"). The application identifier thus retained sole responsibility for carrying the desired protocol and domain, but could offload to the DNS the location of the host of that service within the domain, the port where the service resided on that host, load balancing and fault tolerance, and related application features. Ultimately, resolvers that acquire MX or SRV records may use them as intermediate transformations in order to arrive at an eventual domain name that will resolve to the IP addresses to contact for the service (as optimization, the Additional Data section of these DNS responses may contain the corresponding address records). [TBD: Potentially incorporate some discussion of Hammer's hostmeta or the Webfingers approach as alternatives to using the DNS to identify additional resources required for services] 2.2. NAPTR and DDDS The NAPTR resource record evolved to fulfill a need in the transition from Uniform Resource Locators (URLs) to the more mature URI framework, which incorporated Uniform Resources Names (URNs). Unlike URLs, URNs typically do not convey enough semantics internally to resolve them through the DNS, and consequently a separate URI- transformation mechanism is required to convert these types of URIs into domain names. This allowed identifiers with no recognizable domain component to be treated as DNS names for the purpose of name resolution. Once these transformations resulted in a domain name, applications could retrieve NAPTR records from that zone in the DNS. NAPTR records contain a far more rich and complex structure than MX or SRV resource records. A NAPTR record contains two different weighting mechanisms ("order" and "preference"), a "service" field to designate the application that the NAPTR record described, and then two fields that could contain translations: a "replacement" or "regular expression" field, only one of which appeared in given NAPTR record. A "replacement," like NAPTR's ancestor the PTR record, simply designated another zone where one would look for records Kolkman, et al. Expires January 12, 2012 [Page 7] Internet-Draft Applications in DNS July 2011 associated with this service in the domain. The "regexp," on the other hand, allowed regular expression transformations on the original URI intended to transform it into an identifier that the DNS could resolve. Any sort of hierarchical identifier can potentially be encoded as a DNS name, and thus the DNS has often been used to resolve identifiers that where never devised as a name for an Internet host. A prominent early example is the in-addr domain [RFC0882], which transposes an IPv4 address into a domain name in order to query the DNS for name associated with the address. Similar mechanisms could obviously be applied to other sorts of identifiers that lacked a domain component. Eventually, this idea connected with activities to create a system for resolving telephone numbers on the Internet, which became known as ENUM (originally [RFC2916]). ENUM borrowed from an earlier proposal, the "tpc.int" domain [RFC1530], which provided a means for encoding telephone numbers as domain names by applying a string preparation algorithm that required reversing the digits and treating each individual digit as a zone of the DNS - thus, for example, the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int. In the ENUM system, in place of "tpc.int" the special domain "e164.arpa" was reserved for use. In its more mature form in the Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim) framework, this initial transformation of the telephone number to a domain name was called the "First Well Known Rule." Its flexibility has inspired a number of proposals beyond ENUM to encode and resolve unorthodox identifiers in the DNS. Provided that the identifiers transformed by the First Well Known Rule have some meaningful structure and are not overly lengthy, virtually anything can serve as an input for the DDDS structure: for example, civic addresses (see draft-rosen-dns-sos). Though DDDS[RFC3402] stipulates of the identifier that "the lexical structure of this string must imply a unique delegation path," there is no requirement that the identifier be hierarchical, nor that the points of delegation in the domain name created by the First Well Known Rule correspond to any points of administrative delegation implied by the structure of the identifier. In terms of the results of a DNS query, the presence of the "regexp" field of NAPTR records enabled unprecedented flexibility in the transformations that DNS resolution could perform. Since the output of the regular expression frequently took the form of a URI (in ENUM resolution, for example, a telephone might be converted into a SIP URI [RFC3261]), anything that could be encoded as a URI might be the result of resolving a NAPTR record. Kolkman, et al. Expires January 12, 2012 [Page 8] Internet-Draft Applications in DNS July 2011 2.3. Arbitrary Data in the DNS Since URI encoding has ways of carrying basically arbitrary data, resolving a NAPTR record might result in an output other than an identifier which would subsequently be resolved to IP addresses and contacted for a particular application - it could give a literal result consumed by the application. RFC0882 identified that "it is unlikely that all users of domain names will be able to agree on the set of resources or resource information that names will be used to retrieve," and consequently places little restriction on the information that DNS records might carry: it might be "host addresses, mailbox data, and other as yet undetermined information." NAPTR did not however pioneer the storage of arbitrary data in the DNS. [RFC1035] defined the TXT record, a means to store arbitrary strings in the DNS; RFC1035 specifically stipulates that a TXT contains "descriptive text" and that "the semantics of the text depends on the domain where it is found." The existence of TXT records has long provided new applications with a rapid way of storing data associated with a domain name in the DNS, as adding data in this fashion require no registration process. [RFC1464] added a means of incorporating name/value pairs to the TXT record structure, which allowed applications to differentiate different chunks of data stored in a TXT record. Thus, an application that wants to store additional data in the DNS can do so without registering a new resource record type. While open policies surrounding the use of the TXT record have resulted in a checkered past for standardizing application usage of TXT, it has provided a technical solution for DKIM ([RFC4871]) to necessary information about the security of email in DNS. Storing keys in the DNS for DKIM made sense for several reasons: notably, because the public keys associated with email required wide public distribution, and because email identifiers contain a domain component that applications can easily use to consult the DNS. If the application had to negotiate support for the DKIM mechanism with mail servers, it would give rise to bid-down attacks that are not possible if the DNS delivers the keys (provided that DNSSEC[RFC4033] guarantees authenticity of the data). Kolkman, et al. Expires January 12, 2012 [Page 9] Internet-Draft Applications in DNS July 2011 3. Challenges for the DNS These methods for transforming arbitrary identifiers with domain components into domain names, and for returning arbitrary data in response to DNS queries, both represent significant departures from the basic function of translating host names to IP addresses, yet neither fundamentally alters the underlying semantics of the DNS. When we consider, however, that the URIs returned by DDDS might be base 64 encoded binary data in the data URL [RFC2397], the DNS could effectively implement the entire application feature set of any simple query-response protocol. Effectively, the DDDS framework overlays the DNS with a generic database - indeed, the DDDS framework was designed to work with any sort of underlying database; as [RFC3403] shows, the DNS is only one potential database for DDDS to use. Whether the DNS as an underlying database can support the features that some applications of DDDS require, however, is a more complicated question. The promise that applications might rely on the DNS as a generic database often gives rise to additional requirements that one might expect to find in a database access protocol: authentication of the source of queries for comparison to access control lists, formulating complex relational queries, and asking questions about the structure of the database itself. DNS was not designed to provide these sorts of properties, and extending the DNS to encompass them would represent a fundamental alteration to its model. If an application protocol designer wants these properties from a database, in general this is a good indication that the DNS cannot meet the needs of the application in question. Since many of these new requirements have emerged from the ENUM space, the following sections use ENUM as an illustrative example; however, any application using the DNS as a feature-rich database could easily end up with similar requirements. 3.1. Compound Queries Traditionally, the DNS requires resolvers to supply no information other than the domain name, the type and the class of records sought in order to receive a reply from an authoritative server. Outside of the DNS space, however, there are plenty of query-response applications that require a compound or relational search, which takes into account more than one factor in formulating a response or uses no single factor as a key to the database. For example, in the telephony space, telephone call routing often takes into account numerous factors aside from the dialed number, including originating trunk groups, interexchange carrier selection, number portability data, time of day, and so on. All are considered simultaneously in Kolkman, et al. Expires January 12, 2012 [Page 10] Internet-Draft Applications in DNS July 2011 generating a route. While in its original conception, ENUM hoped to circumvent the traditional PSTN and route directly to Internet- enabled devices, the infrastructure ENUM effort to support the migration of traditional carrier routing functions to the Internet aspires to achieve feature parity with traditional number routing. Consequently, some consideration has been given to ways to add additional data to ENUM queries to give the DNS server sufficient information to return a suitable URI. From a sheer syntactical perspective, however, domain names do not admit of this sort of rich structure. Several workaround have attempted to instantiate these sorts of features in DNS queries. Most commonly, proposals piggyback additional query parameters as eDNS0 extensions (see [RFC2671]). Alternatively, the domain name itself could be compounded with the additional parameters: one could take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk group identifier to it, for example, of the form tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in the latter case, a DNS server can adhere to its traditional behavior in locating resource records, the syntactical viability of encoding additional parameters in this fashion is very dubious, especially if more than one additional parameter is required and the presence of parameters is optional. The former eDNS0 case requires significant changes to name server behavior. Moreover, the implications of these sorts of compound queries for recursion and caching are potentially serious. The logic used by the authoritative server to respond to a compound query may not be followed by any recursive servers or caches; intermediaries that naively assume that the response was selected based on the domain name, type and class alone might serve responses to queries in a different way than the authoritative server intends. 3.1.1. Responses Tailored to the Originator The most important subcase of the compound queries are DNS responses tailored to the identity of their originator, where some sort of administrative identity of the originator must be conveyed to the DNS. We must first distinguish this from cases where the originating IP address or a similar indication is used to serve a location- specific name. For those sorts of applications, which generally lack security implications, relying on factors like the source IP address introduces little harm for example, when providing a web portal customized to the region of the client, it would not be a security breech if the client saw the localized portal of the wrong country. Because recursive resolvers may obscure the origination network of the DNS client, a recent proposal suggested introducing a new DNS query parameter to be populated by DNS recursive resolvers in order Kolkman, et al. Expires January 12, 2012 [Page 11] Internet-Draft Applications in DNS July 2011 to preserve the originating IP address (see [draft-vandergaast-edns-client-ip]). However, aside from purely cosmetic uses, these approaches have known limitations due to the prevalence of private IP addresses, VPNs and so on which can prevent the source IP address from conveying useful information. In other deployments in use today, including those based on the BIND "views" feature, the source IP address is used to grant access to a private set of resource records. The security implications of trusting the source IP address of a DNS query have prevented most solutions along these lines from being standardized (see draft-ietf-intarea-shared-addressing-issues), though the practice remains widespread in "split horizon" private DNS deployment (see Section 4.1) which typically rely on an underlying security layer, such as a physical network or an IPSec VPN, to prevent spoofing of the source IP address. These deployments do have a confidentiality requirement to prevent information intended for a constrained audience (internal to an enterprise, for example) from leaking to the public Internet -- while these internal network resources may use private IP addresses which would not be useful on the public Internet anyway, in some cases this leakage would reveal topology or other information that the name server provisioner hopes to keep private. These first two cases, regardless of their acceptance by the standards community, have widespread acceptance in the field. Some applications, however, go even further and propose extending the DNS to add an application-layer identifier of the originator rather than an IP address; for example, draft-kaplan-enum-source-uri provides a SIP URI in an eDNS0 parameter (though without any specific provision for cryptographically verifying the claimed identity). Effectively, the conveyance of application-layer information about the administrative identity of the originator through the DNS is a weak authentication mechanism, on the basis of which the DNS server makes an authorization decision before sharing resource records. This can parlay into a per-RR confidentiality mechanism, where only a specific set of originators are permitted to see resource records, or a case where a query for the same name by different entities results in completely different resource record sets. The DNS, however, substantially lacks the protocol semantics to manage access control list for data, and again, caching and recursion introduce significant challenges for applications that attempt to offload this responsibility to the DNS. Achieving feature parity with even the simplest authentication mechanisms available at the application layer would like require significant rearchitecture of the DNS. Kolkman, et al. Expires January 12, 2012 [Page 12] Internet-Draft Applications in DNS July 2011 3.2. Metadata about Tree Structure ENUM use cases have also surfaced a couple of optimization requirements to reduce unnecessary calls and queries by including metadata that describes the contents and structure of ENUM DNS trees. In particular, the "send-n" proposal [draft-bellis-enum-send-n] hopes to reduce the number of DNS queries sent in cases where a telephone system is collecting dialed digits in a region that supports "overlap" dialing, a practice which compensates for variable-length numbering plans. When the dialed number potentially has a variable length, a telephone switch ordinarily cannot anticipate when a dialed number is complete, as only the terminating customer premise equipment (typically a private branch exchange) knows how long a telephone number needs to be. The "send-n" proposal offloads to the DNS the responsibility for informing the telephone switch the minimum number of digits that must be collected by placing in zones corresponding to incomplete telephone numbers some resource records which state how many more digits are required - effectively how many steps down the DNS tree one must take before querying the DNS again. With this information, the application is not required to query the DNS every time a new digit is dialed, but can wait to collect sufficient digits to receive a response. As an optimization, this practice thus saves the resources of the DNS server - though it does not result in faster call set-up, as the call cannot complete until all digits are collected. A tangentially related proposal, [draft-ietf-enum-void], similarly places resource records in the DNS that tell the application that it need not attempt to reach a number on the PSTN, as the number is unassigned. Both proposals optimize application behavior by placing metadata in the DNS that predicts the success of future queries or application invocations. These predictions require that the metadata remain synchronized with the state of the resources it predicts. Maintaining that synchronization, however, requires that the DNS have semi-real time updates that may conflict with scale and caching mechanisms. It may also raise questions about the authority and delegation model, and whether the entities that control the zones where changes occur have the authority to populate the zones where synchronization must be maintained; in send-n, different leaf zones might want to populate different information in a common parent. An application protocol designer who wants to manage identifiers in this fashion would be better served to implement this mechanism outside the DNS. 3.3. Using DNS as a Generic Database As previously noted, the use of the First Well Known Rule of DDDS combined with data URLs (or potential RFC1461 TXT records) Kolkman, et al. Expires January 12, 2012 [Page 13] Internet-Draft Applications in DNS July 2011 effectively allows the DNS to answer queries for arbitrary strings and to return arbitrary data as a value. Some query-response applications, however, require queries and responses that simply fall outside the syntactic capabilities of the DNS. Domain names themselves must conform to certain syntactic constraints: they must consist of labels that do not exceed 63 characters while the total length of the encoded name may not exceed 255 octets, they must obey fairly strict encoding rules, and so on. 3.3.1. Large Data in the DNS While the data URL specification [RFC2397] notes that it is "only useful for short values," many applications today use quite large data URLs as workarounds in environments where only URIs can syntactically appear. While the use of TCP and eDNS0 allows DNS responses to be quite long, nonetheless there are forms of data that an application might store in the DNS that exceed reasonable limits: in the ENUM context, for example, something like storing base 64 encoded mp3 files of custom ringtones. Designs relying on storage of large amounts of data within DNS RRs furthermore need to minimize the potential damage achievable in a reflection attack (see [RFC4732], Section 3), in which the attacker sends DNS queries with a forged source address, and the victim receives the response. By generating a large response to a small query, the attacker can magnify the bandwidth directed at the victim. Since the large disparity between the size of a query and size of the response creates this amplification, future work might identify a desired proportion between the size of a query and the size of a response. Since it is difficult to complete a TCP three-way handshake begun from a forged source address, DNS reflection attacks utilize UDP queries. Unless the attacker uses EDNS0 [RFC2671] to enlarge the requester's maximum payload size, a response can only reach 576 octets before the truncate bit is set in the response. This limits the maximum magnification achievable from a DNS query that does not utilize EDNS0. However, where the responder supports EDNS0, an attacker may set the requester maximum payload size to a larger value while querying for a large RR, such as a certificate [RFC4398]. Thus the combination of large data stored in DNS RRs and responders supporting large requester payload sizes has the potential to increase the potential damage achievable in a reflection attack. Since a reflection attack can be launched from any network that does not implement source address validation, these attacks are difficult to eliminate absent the ubiquitous deployment of source address validation. Since Kolkman, et al. Expires January 12, 2012 [Page 14] Internet-Draft Applications in DNS July 2011 reflection attacks are most damaging when launched from high bandwidth networks, the implementation of source address validation on these networks is particularly important. The bandwidth that can be mustered in a reflection attack directed by a botnet controlling broadband hosts is sobering. For example, if a responder could be directed to generate a 10KB response in reply to a 50 octet query, then magnification of 200:1 would be attainable. This would enable a botnet controlling 10000 hosts with 1 Mbps of bandwidth to focus 2000 Gbps of traffic on the victim, more than sufficient to congest any site on the Internet. 3.4. Administrative Structures Misaligned with the DNS While the DDDS framework enables any sort of alphanumeric data to serve as a DNS name through the application of the First Well Known Rule, the delegative structure of the resulting DNS name may not reflect the division of responsibilities for the resources that the alphanumeric data indicates. Telephone numbers in the United States, for example, are assigned and delegated in a relatively complex manner: the first three digits of a nationally specific number are an "area code" which is understood as an indivisible component of the number, yet for the purpose of the DNS, those three digits are ranked hierarchically. Any mechanism to map a hierarchical identifier into a DNS name should be constructed such that the resulting DNS name does match the natural hierarchy of the original identifier. The difficulty of mapping the DNS to administrative structures can even occur with traditional domain names, where applications expect clients to infer or locate zone cuts. 3.5. Domain Redirection Most Internet application services provide a redirection feature - when you attempt to contact a service, the service may refer you to a different service instance, potentially in another domain, that is for whatever reason better suited to address a request. In HTTP and SIP, for example, this feature is implemented by the 300 class responses containing one or more better URIs that may indicate that a resource has moved temporarily or permanently to another service. Several tools in the DNS, including the SRV record, can provide a similar feature at a DNS level, and consequently some applications as an optimization offload the responsibility for redirection to the DNS; NAPTR can also provide this capability on a per-application basis, and numerous DNS resource records can provide redirection on a per-domain basis. This can prevent the unnecessary expenditure of application resources on a function that could be performed as a component of a DNS lookup that is already a prerequisite for Kolkman, et al. Expires January 12, 2012 [Page 15] Internet-Draft Applications in DNS July 2011 contacting the service. Consequently, in some deployment architectures this DNS-layer redirection is used for virtual hosting services. Implementing domain redirection in the DNS, however, has important consequences for application security. In the absence of universal DNSSEC, applications must blindly trust the DNS in order to believe that their request has not been hijacked and redirected to a potentially malicious domain, unless some subsequent application mechanism can provide the necessary assurance. By way of contrast, for application-layer redirections protocols like HTTP and SIP have widely deployed security mechanisms such as TLS that can use certificates to vouch that a 300 response came from the domain that the originator initially hoped to contact. A number of applications have attempted to provide an after-the-fact security mechanism that verifies the authority of a DNS delegation in the absence of DNSSEC. The specification for dereferencing SIP URIs ([RFC3263], reaffirmed in [RFC5922]) requires that during TLS establishment, the site eventually reached by a SIP request present a certificate corresponding to the original URI expected by the user (in other words, if example.com redirects to example.net in the DNS, this mechanism expects that example.net will supply a certificate for example.com in TLS, per the HTTP precedent in [RFC2818]), which requires a virtual hosting service to possess a certificate corresponding to the hosted domain. This restriction rules out many styles of hosting deployments common in the web world today, however. [I-D.barnes-hard-problem] explores this problem space, and [I-D.saintandre-tls-server-id-check] proposes a solution for all applications that use TLS. Potentially, new types of certificates (similar to [RFC4985]) might bridge this gap, but support for those certificates would require changes to existing certificate authority practices as well as application behavior. All of these application-layer measures attempt to mirror the delegation of authority in the DNS, when the itself DNS serves as the ultimate authority on how domains are delegated. Synchronizing a static instrument like a certificate with a delegation in the DNS, however, is problematic because delegation are not static: revoking and reissuing a certificate every time a delegation changes is cumbersome operationally. In environments where DNSSEC is not available, the problems with securing DNS-layer redirections would be avoided by performing redirections in the application-layer. Kolkman, et al. Expires January 12, 2012 [Page 16] Internet-Draft Applications in DNS July 2011 4. Principles and Guidance The success of the DNS relies on the fact that it is a distributed database, one that has the property that it is loosely coherent and that it offers lookup instead of search functionality. Loose coherency means that answers to queries are coherent within the bounds of data replication between authoritative servers and caching behavior by recursive name servers. It is likely that the DNS provides a good match whenever applications needs are aligned with the following properties: Data can be stored in such a way that querying just for the domain name, class and type suffices to provide an answer Data is indexed by keys that do not violate the syntax or semantics of domain names Answers do not depend on an application-layer identity of the entity doing the query Data stored in the DNS can be propagated and cached without intermediaries needing to understand exceptional logic used by the authoritative server to formulate responses Whenever one of the four properties above does not apply to ones data one should seriously consider whether the DNS is the best place to store actual data. On the other hand, good indicators that the DNS is not the appropriate tool for solving problems is when you have to worry about: Trying to establish domain boundaries within the tree - the delegation point in the DNS is something that applications should in general not be aware off Working from application identifiers that cannot be resolved by the DNS without complex encoding The sensitivity of the data, especially preserving its confidentiality from unauthorized queries in a multilateral environment Highly volatile data that synchronizes with the state of applications external to the DNS Answers dependent on the application-layer identity of the originator of the query Kolkman, et al. Expires January 12, 2012 [Page 17] Internet-Draft Applications in DNS July 2011 There are many useful application features that can safely be offloaded to the DNS: aside from locating services in a domain, the DNS clearly can assist in the resolution of identifiers without a domain component (including URNs), and moreover it can host some static application data, like the cryptographic keys used by DKIM for email, which are well suited to storage in the DNS. However, the prospects for offloading application features like authentication of query originators, structuring compound questions and implementing metadata about the tree structure are more remote. While clearly DNS-layer redirection is a widely deployed alternative to application-layer redirection, many applications that choose to offload this have struggled to meet the resulting security challenges. In cases where applications require these sorts of features, they are simply better instantiated by independent application-layer protocols than the DNS. The query-response semantics of the DNS are easily replicated by HTTP, for example, and the objects which HTTP can carry both in queries and responses can easily contain the necessary structure to manage compound queries. Similarly, HTTP has numerous ways to provide the necessary authentication, authorization and confidentiality properties that some features require. Where the administrative delegations of the DNS form a necessary component in the instantiation of an application feature, there are various ways that the DNS can bootstrap access to an independent application-layer protocol better suited to field the queries in question. For example, since NAPTR or URI resource records can contain URIs, those URIs can in turn point to an external query- response service such as HTTP where more syntactically and semantically rich queries and answers might be exchanged. 4.1. Private DNS Deployments Much of the guidance offered by this document refers to the difficulties of instantiating certain application features in the global public root of the DNS. There are however various private DNS deployments, including split horizons that give a different view of a zone to the public Internet than they do to internal resolvers. Concerns about confidentiality, for example, are far easier to manage in a private environment than a public one. Consequently, many deployments that want to install rich application features in DNS do so in private environments rather than in the public DNS. There are several motivations for this: in the first place, proprietary non-standard extensions and parameters can easily be integrated into DNS queries or responses as the implementations of resolvers and servers can likely be controlled; secondly, Kolkman, et al. Expires January 12, 2012 [Page 18] Internet-Draft Applications in DNS July 2011 confidentiality and custom responses can be provided by deploying, respectively, underlying physical or virtual private networks to shield the private tree from public queries, and effectively different virtual DNS trees for each administrative entity that might launch a query; thirdly, in these constrained environments, caching and recursive resolvers can be managed or eliminated in order to prevent any unexpected intermediary behavior. While these private deployments serve an important role in the marketplace, there are risks in using techniques intended only for use in private and constrained environments as the basis of a standard solution. When proprietary parameters or extensions are deployed in these private environments, it seems almost certain that these implementations will begin to interact with the public DNS, and that the private practices will leak. Therefore, keeping these features within higher-layer applications rather than offloading them to the DNS is preferred. Kolkman, et al. Expires January 12, 2012 [Page 19] Internet-Draft Applications in DNS July 2011 5. Security Considerations Many of the concerns about offloading application features to the DNS revolve around security. Section 3.5 discusses a security problem concerning redirection that has surfaced in a number of protocols (see [I-D.barnes-hard-problem]). The perceived need to authenticate the source of DNS queries (see Section 3.1.1) and authorize access to particular resource records also illustrates the fundamental security principles that arise from offloading certain application features to the DNS. While DNSSEC, were it deployed universally, can play an important part in securing application redirection in the DNS, DNSSEC does not provide a means for a resolver to authenticate itself to a server, nor a framework for servers to return selective answers based on the authenticated identity of resolvers. Kolkman, et al. Expires January 12, 2012 [Page 20] Internet-Draft Applications in DNS July 2011 6. IANA Considerations This document contains no considerations for the IANA. Kolkman, et al. Expires January 12, 2012 [Page 21] Internet-Draft Applications in DNS July 2011 7. Acknowledgements The IAB appreciates the comments and often spirited disagreements of Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom and Eliot Lear. Kolkman, et al. Expires January 12, 2012 [Page 22] Internet-Draft Applications in DNS July 2011 8. Informative References [I-D.barnes-hard-problem] Barnes, R. and P. Saint-Andre, "High Assurance Re- Direction (HARD) Problem Statement", draft-barnes-hard-problem-00 (work in progress), July 2010. [I-D.saintandre-tls-server-id-check] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity in Certificates Used with Transport Layer Security", draft-saintandre-tls-server-id-check-09 (work in progress), August 2010. [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", RFC 882, November 1983. [RFC0974] Partridge, C., "Mail routing and the domain system", RFC 974, January 1986. [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC1464] Rosenbaum, R., "Using the Domain Name System To Store Arbitrary String Attributes", RFC 1464, May 1993. [RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the TPC.INT Subdomain: General Principles and Policy", RFC 1530, October 1993. [RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794, April 1995. [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform Resource Identifiers using the Domain Name System", RFC 2168, June 1997. [RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397, August 1998. [RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. Kolkman, et al. Expires January 12, 2012 [Page 23] Internet-Draft Applications in DNS July 2011 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. [RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002. [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002. [RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005. [RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J., and T. Wright, "Transport Layer Security (TLS) Extensions", RFC 4366, April 2006. [RFC4367] Rosenberg, J. and IAB, "What's in a Name: False Assumptions about DNS Names", RFC 4367, February 2006. [RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- Service Considerations", RFC 4732, December 2006. [RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton, J., and M. Thomas, "DomainKeys Identified Mail (DKIM) Signatures", RFC 4871, May 2007. [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure Kolkman, et al. Expires January 12, 2012 [Page 24] Internet-Draft Applications in DNS July 2011 Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007. [RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009. [RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain Certificates in the Session Initiation Protocol (SIP)", RFC 5922, June 2010. Kolkman, et al. Expires January 12, 2012 [Page 25] Internet-Draft Applications in DNS July 2011 Authors' Addresses Olaf Kolkman NLNet Email: olaf@nlnetlabs.nl Jon Peterson NeuStar, Inc. Email: jon.peterson@neustar.biz Hannes Tschofenig Nokia Siemens Networks Email: Hannes.Tschofenig@gmx.net Bernard Aboba Microsoft Corporation Email: bernarda@microsoft.com Kolkman, et al. Expires January 12, 2012 [Page 26]