Network Working Group O. Kolkman Internet-Draft NLNet Intended status: Informational J. Peterson Expires: May 3, 2012 NeuStar, Inc. H. Tschofenig Nokia Siemens Networks B. Aboba Microsoft Corporation October 31, 2011 Architectural Considerations on Application Features in the DNS draft-iab-dns-applications-03 Abstract A number of Internet applications rely on the Domain Name System (DNS) to support their operations. Many applications use the DNS to locate services for a domain, for example; more recently, some applications have begun transforming identifiers other than domain names into formats 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 as to the sorts of ways that application can make use of the DNS. 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 May 3, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Kolkman, et al. Expires May 3, 2012 [Page 1] Internet-Draft Applications in DNS October 2011 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. 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 May 3, 2012 [Page 2] Internet-Draft Applications in DNS October 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 . . . . . . . . . . . . . . . . . . . . 11 3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 11 3.1.1. Responses Tailored to the Originator . . . . . . . . . 13 3.2. Using DNS as a Generic Database . . . . . . . . . . . . . 14 3.2.1. Large Data in the DNS . . . . . . . . . . . . . . . . 14 3.3. Administrative Structures Misaligned with the DNS . . . . 16 3.3.1. Metadata about Tree Structure . . . . . . . . . . . . 17 3.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 19 4. Private DNS and Split Horizon . . . . . . . . . . . . . . . . 21 5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 23 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 27 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28 10. Informative References . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 Kolkman, et al. Expires May 3, 2012 [Page 3] Internet-Draft Applications in DNS October 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 a mail service for the domain sanctioned by the zone administrator. The seminal MX record served as a prototype for other 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 as it evolved into the more general 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 Domain Keys 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 expectation of 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. Applications in many environments require these sorts of features from databases, and as the contexts in which applications rely on the DNS have increased, some application protocols have looked to extend the DNS to include these sorts of capabilities. Kolkman, et al. Expires May 3, 2012 [Page 4] Internet-Draft Applications in DNS October 2011 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 might 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 invocation of the resolver by applications, the behavior of name servers, resolvers or caches, extensions to the underlying DNS protocol, the operational responsibilities of zone administrators, security, or the overall architecture of names. When existing DNS protocol fields are used in ways that their designers did not intend to handle new applications, those applications may require further changes and extensions that are fundamentally at odds with the strengths of the DNS. Kolkman, et al. Expires May 3, 2012 [Page 5] Internet-Draft Applications in DNS October 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" transition from a global table (the original "hosts.txt" file) to a "distributed database that performs the same function." [RFC0882] 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. 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 an 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 that receives mail on behalf of the administrative domain in question; 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 under the same name, 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 Kolkman, et al. Expires May 3, 2012 [Page 6] Internet-Draft Applications in DNS October 2011 learn a host name and port where that service resides in a given 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, and that way that applications pass DNS names to resolvers. Email identifiers of the form "user@domain" rely on MX records to provide the convenience of simply specifying a "domain" component rather requiring to guess which particular host handles mail on behalf of the domain. While for applications like web browsing, naming conventions continue to abound ("www.example.com"), SRV records allow applications to query for an application-specific protocol and transport. For HTTP, the SRV service name corresponds to the URL scheme of the identifier invoked by the application (e.g., when "http://example.com" is the identifier, the SRV query is for "_http._tcp.example.com"); for other applications, the SRV service that the application passes to the resolver may be implicit in the identifier. The identifier used at the application layer thus designates the desired protocol and domain, but the application offloads to the DNS finding the location of the host of that service for 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. Locating specific services for a domain is thus the first major function that applications offloaded to the DNS in addition to simple name resolution. SRV broadened and generalized the precedent of MX to make service location available to any application, rather than just to mail. As the domain name of the located service might require a second DNS query to resolve, [RFC1034] shows that the Additional Data section of DNS responses may contain the corresponding address records for the names of services designated by the MX record; this optimization, which requires support in the authoritative server and the resolver, is an initial example of how support for application features requires changes to DNS operation. 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 [RFC3986] 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 Kolkman, et al. Expires May 3, 2012 [Page 7] Internet-Draft Applications in DNS October 2011 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 under that name 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 designates another domain name where one would look for records associated with this service in the domain. The "regexp," on the other hand, allows regular expression transformations on the original URI intended to transform it into an identifier that the DNS could resolve. As the Abstract of [RFC2915] says, "This allows the DNS to be used to lookup services for a wide variety of resource names (including URIs) which are not in domain name syntax." Any sort of hierarchical identifier can potentially be encoded as a DNS name, and thus historically the DNS has often been used to resolve identifiers that were 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(s) 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 label in a DNS name - 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. Though [RFC3402] stipulates of the identifier that "the lexical structure of this string must imply a unique delegation path," there Kolkman, et al. Expires May 3, 2012 [Page 8] Internet-Draft Applications in DNS October 2011 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. While this ability to look up names "which are not in the domain name syntax" does not change the underlying DNS protocols - the names generated by the DDDS algorithm are still just domain names - it does change the context in which applications pass name to resolvers, and can potentially require very different operational practices of zone administrators(see Section 3.3). In terms of the results of a DNS query, the presence of the "regexp" field of NAPTR records enabled unprecedented flexibility in the types of identifiers that applications could resolve with the DNS. Since the output of the regular expression frequently took the form of a URI (in ENUM resolution, for example, a telephone number 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 - which, as the next section explores, essentially means arbitrary data. 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. Originally, in [RFC2168], the intended applicability of the regular expression field in NAPTR was much more narrow: the regexp field contained a "substitution expression that is applied to the original URI in order to construct the next domain name to lookup," in order "change the host that is contacted to resolve a URI" or as a way of "changing the path or host once the URL has been assigned." The regular express tools available to NAPTR record authors, however, grant much broader powers to alter the input string, and thus applications began to rely on NAPTR to perform more radical transformations. By [RFC3402], the output of DDDS is wholly application-specific: "the Application must determine what the expected output of the Terminal Rule should be," and the example given in the document is one of identifying automobile parts by inputting a part number is receiving at the end of the process receiving information about the manufacturer (though this example reflects that the DNS is only one database to which the DDDS framework might apply). NAPTR did not however pioneer the storage of arbitrary data in the DNS. At the start, [RFC0882] observed 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 Kolkman, et al. Expires May 3, 2012 [Page 9] Internet-Draft Applications in DNS October 2011 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." [RFC1035] defined the TXT record, a means to store arbitrary strings in the DNS; [RFC1034] 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. In this fashion, an application that wants to store additional data in the DNS can do so without registering a new resource record type - though [RFC5507] points out that it is "difficult to reliably distinguish one application's record from otters, and for its parser to avoid problems when it encounters other TXT records." While open policies surrounding the use of the TXT record have resulted in a checkered past for standardizing application usage of TXT, TXT has been used as a technical solution for DKIM [RFC4871] to store necessary information about the security of email in DNS, though within a narrow naming convention (records stored under "_domainkey" subdomains). Storing keys in the DNS became the preferred solution for DKIM 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 (where attackers misrepresent that DKIM is unsupported in the domain) that are not possible if the DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees authenticity of the data). However, there are potential issues with story large data in the DNS, as discussed in Section 3.2.1. Kolkman, et al. Expires May 3, 2012 [Page 10] Internet-Draft Applications in DNS October 2011 3. Challenges for the DNS The methods discussed in the previous section for transforming arbitrary identifiers 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. As the following subsections will show, the potential that applications might rely on the DNS as a generic database 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. Ultimately, this document concludes that efforts to retrofit these capabilities into the DNS would be better invested in selecting, or if necessary inventing, other Internet services with broader powers than the DNS. 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 Kolkman, et al. Expires May 3, 2012 [Page 11] Internet-Draft Applications in DNS October 2011 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 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. However, [RFC3402] explicitly states that "it is an assumption of the DDDS that the lexical element used to make a delegation decision is simple enough to be contained within the Application Unique String itself. The DDDS does not solve the case where a delegation decision is made using knowledge contained outside the AUS and the Rule (time of day, financial transactions, rights management, etc.)." 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 (see Section 3.1.1). From a sheer syntactical perspective, however, domain names do not admit of this sort of rich structure. Several workarounds 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. The intended applicability of the EDNS0 mechanism, as the [RFC2761] states, is to "a particular transport level message and not to any actual DNS data," and consequently the OPT Resource Records it specifies are never to be forwarded; the use of EDNS0 for compound queries, however, clearly is intended to discriminate actual DNS data rather than to facilitate transport- layer handling. [RFC2761] also specifies that only one OPT pseudo- Resource Record can appear in a single request, so the use of this mechanism can only compound a query by a single field. For these reasons, this draft recommends against the use of eDNS0 as a mechanism for crafting compound DNS queries. 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 Kolkman, et al. Expires May 3, 2012 [Page 12] Internet-Draft Applications in DNS October 2011 understood 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. Even comparatively unambiguous expressions of server preference like the time-to-live parameter are not always honored by caches. 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 to preserve the originating IP address (see [I-D.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 obscure the source IP address and instead supply the IP address of an intermediary that may be very distant from the originating endpoint. Implementing vandergaast does require significant changes in the operation of recursive resolvers and the authoritative servers that would rely on the original source IP address to select Resource Records, and moreover a fundamental change to caching behavior as well. 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 [RFC6269]), though the practice remains widespread in "split horizon" private DNS deployment (see Section 4) 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 Kolkman, et al. Expires May 3, 2012 [Page 13] Internet-Draft Applications in DNS October 2011 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, [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] 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-Resource Record 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 lists 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. 3.2. Using DNS as a Generic Database As previously noted, the use of the First Well Known Rule of DDDS combined with data URLs (or potentially TXT records) 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. The DNS therefore cannot be a completely generic database. Similar concerns apply to the size of DNS responses. 3.2.1. Large Data in the DNS While the data URL specification [RFC2397] notes that it is "only useful for short values," unfortunately it gives no particular guidance about what "short" might mean. Many applications today use quite large data URLs (containing a megabyte or more of data) as Kolkman, et al. Expires May 3, 2012 [Page 14] Internet-Draft Applications in DNS October 2011 workarounds in environments where only URIs can syntactically appear. The meaning of "short" in an application context is probably very different from how we should understand it in a DNS message. Referring to a typical public DNS deployment, [RFC5507] observes that "there's a strong incentive to keep DNS messages short enough to fit in a UDP datagram, preferably a UDP datagram short enough not to require IP fragmentation," which entails a maximum size of 512 octets. While the use of TCP and eDNS0 allows DNS responses to be quite long, this requires stateful operation of servers which can be costly in deployments where servers have only fleeting connections to many clients. Ultimately, 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. Where the responder supports EDNS0, an attacker may set the requester maximum payload size to a larger value while querying for a large Resource Record, such as a certificate [RFC4398]. Thus the combination of large data stored in DNS RRs and responders supporting large 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 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. 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 Kolkman, et al. Expires May 3, 2012 [Page 15] Internet-Draft Applications in DNS October 2011 utilize EDNS0. As the large disparity between the size of a query and size of the response creates this amplification, implementations should limit EDNS0 responses to a specific ratio compared to the request size. The precise ratio can be configured on a per- deployment basis, but without this limitation, EDNS0 can cause significant harm. 3.3. 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. While [RFC3402] requires only that "Application Unique String has some kind of regular, lexical structure that the rules can be applied to," DDDS is first and foremost a delegation system: its abstract stipulates that "Well- formed transformation rules will reflect the delegation of management of information associated with the string." Telephone numbers in the United States, for example, are assigned and delegated in a relatively complex manner. Historically, the first six digits of a nationally specific number (called the "NPA/NXX") reflected a point of administrative delegation from the number assignment agency to a carrier; from these blocks of ten thousand numbers, the carrier would in turn delegate individual assignments of the last four digits (the "XXXX" portion) to particular customers. However, after the rise of North American telephone number portability in the 1990s, the first point of delegation went away: the delegation is effectively from the number authority to the carrier for each the complete ten-digit number (NPA/NXX-XXXX). While technical implementation details differ from nation to nation, number portability systems with similar administrative delegations now exist worldwide. To render these identifiers as domain names in accordance with the DDDS Rule for ENUM yields a large flat zone with no points of administrative delegation (or zone cuts) from the country-code administrator, e.g. 1.e164.arpa, down to the ultimately assignee of a number. The scalability difficulties of maintaining a single DNS zone with potentially over five billion names in it manifest in a number of areas (in practice, there are closer to 300M allocated telephone numbers in the United States today, but that is still more than three times the number of .com domain names). The scalability that results from caching depends on points of delegation so that cached results for intermediate servers take the load off higher tier servers. If there are no such delegations, then as in the telephone number example the zone apex server must bear the entire load for queries. Worse still, number portability also introduces far more dynamism in number assignment, where in some regions updated Kolkman, et al. Expires May 3, 2012 [Page 16] Internet-Draft Applications in DNS October 2011 assignees for ported numbers must propagate within fifteen minutes of a change in administration. Jointly, these two problems cacheing the zone extremely problematic. Moreover, traditional tools for DNS replication, such as the zone transfer protocol AXFR [RFC1034] and IXFR [RFC1995], are not designed to accommodate zones with these dimensions and properties. When traditional DNS management tools no longer apply to the structures that an application tries to provision in the DNS, this is another clue that the DNS might not be the right place for an application to store its data. DDDS provides a capability that transforms arbitrary strings into domain names, but those names play well with the DNS only when the input string have an administrative structure that maps on DNS delegations. In the first place, delegation implies some sort of hierarchical structure. 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. Although telephone numbers, even in North America, have some hierarchical qualities (like the geographical areas corresponding to their first three digits), after the implementation of number portability these points no longer mapped onto an administrative delegation. If the input string to the DDDS does not have a hierarchical structure representing administrative delegations that can map onto the DNS distribution system, that string probably is not a good candidate for translating into a domain name. 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. In the web context, for example, it can be difficult for applications to determine whether two domain names represent the same "site" when 3.3.1. Metadata about Tree Structure There are also other ways in which the delegative structure of an identifier may not map well onto the DNS. Traditionally, DNS resolvers assume that when they receive a domain name from an application, that the name is complete - that it is not a fragment of a DNS name that a user is still in the middle of typing. For some communications systems, however, this assumption does not apply. ENUM use cases have surfaced a couple of optimization requirements to reduce unnecessary calls and queries by including metadata in the DNS that describes the contents and structure of ENUM DNS trees to help applications to handle incomplete queries or queries for domains not in use. In particular, the "send-n" proposal [I-D.bellis-enum-send-n] hopes to reduce the number of DNS queries sent in regions with variable-length numbering plans. When a dialed number potentially has a variable length, a telephone switch Kolkman, et al. Expires May 3, 2012 [Page 17] Internet-Draft Applications in DNS October 2011 ordinarily cannot anticipate when a dialed number is complete, as only the numbering plan administrator (who may be a national regulator, or even in open number plans a private branch exchange) knows how long a telephone number needs to be. Consequently, a switch trying to resolve such a number through a system like ENUM might send a query for a telephone number that has only partially been dialed in order to test its completeness. The "send-n" proposal installs in the DNS a hint informing the telephone switch of 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. Unsurprisingly, those boundaries reflect points of administrative delegation, where the parent in a number plan yields authority to a child. 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 the call cannot complete until all digits are collected, so at best this mechanism only reduces the time the system will wait before sending an ENUM query after collecting the final dialed digit. A tangentially related proposal, [I-D.ietf-enum-unused], similarly places resource records in the DNS that tell the application that it need not attempt to reach a number on the telephone network, as the number is unassigned - a comparable general DNS mechanism would identify, for a domain name with no heather or not the domain had been allocated to an owner. Both proposals optimize application behavior by placing metadata in the DNS that predicts the success of future queries or application invocation by identifying points of administrative delegation or assignment in the tree. In some respects, marking a point in the tree where a zone begins or end has some features in common with the traditional parent zone use of the NS record type, except instead of pointing to a child zone, these metadata proposals point to distant grandchildren. While this does not change resolver behavior as such (instead, it changes the way that applications invoke the resolver), it does have implications for the practices for zone administrators. Metadata in the authoritative server 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. Who gets to supply records for unassigned names? While in the original but little-used "golden" root model of ENUM, this would almost certainly be a numbering plan administrator, it is far less clear who that would be in the more common and successful Kolkman, et al. Expires May 3, 2012 [Page 18] Internet-Draft Applications in DNS October 2011 "infrastructure" ENUM models (see Section 4). Ultimately, these metadata proposals share some qualities with DNS redirection services offered by ISPs (for example, [I-D.livingood-dns-redirect]) which "help" web users who try to browser to sites that do not exist - though in those cases, at least the existence or non-existence of a domain name is a fact about the Internet, rather than about an external network like the telephone system which must be synchronized with the DNS tree in the metadata proposals. In send-n, different leaf zones, who administer telephone numbers of different lengths, can only provision their hints at their own apex, which provides an imperfect optimization: they cannot install it in a parent, both because they lack the authority and because different zones would want to provision contradictory data. An application protocol designer who wants to manage identifiers whose administrative model does not map well onto the DNS would be better served to implement such features outside the DNS. 3.4. 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 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 that their request has not been hijacked at the DNS layer and redirected to a potentially malicious domain, unless some subsequent application mechanism can provide the necessary assurance. By way of contrast, 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. Kolkman, et al. Expires May 3, 2012 [Page 19] Internet-Draft Applications in DNS October 2011 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 DNS itself 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 delegations 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 May 3, 2012 [Page 20] Internet-Draft Applications in DNS October 2011 4. Private DNS and Split Horizon The classic view of the uniqueness of DNS names is given in [RFC2826]: DNS names are designed to be globally unique, that is, for any one DNS name at any one time there must be a single set of DNS records uniquely describing protocol addresses, network resources and services associated with that DNS name. All of the applications deployed on the Internet which use the DNS assume this, and Internet users expect such behavior from DNS names. However, [RFC2826] "does not preclude private networks from operating their own private name spaces," but notes that if private networks "wish to make use of names uniquely defined for the global Internet, they have to fetch that information from the global DNS naming hierarchy." There are various DNS deployments outside of the global public DNS, including "split horizon" deployments and DNS usages on private (or virtual private) networks. In a split horizon, an authoritative server gives different responses to queries from the public Internet than they do to internal resolvers; as they typically differentiate internal from public queries by the source IP address, the concerns in Section 3.1.1 apply to such deployments. When the internal address space range is private [RFC1918], this both makes it easier for the server to discriminate public from private and harder for public entities to impersonate nodes in the internal network. Networks that are made private physically, or logically by cryptographic tunnels, make these private deployments more secure. The most complex deployments along these lines use multiple virtual private networks to serve different answers for the same name to many networks. The use cases that motivate split horizon DNS typically involve restricting access to some network services - intranet resources like internal web site, development servers or directories, for example - while preserving the ease of use offered by domain names for internal users. While for many of these resources, the split horizon would not return answers to public resolvers for those internal resources (those records are kept confidential from the public), in some cases, the same name (e.g., "mail.example.com") might resolve to one host internally but another externally. The requirements for multiple-VPN private deployments, however, are different: in this case the authoritative server gives different, and confidential, answers to a set of resolvers querying for the same name. While these sorts of use cases rarely arise for traditional domain names, where, as [RFC2826] says, users and applications expect a unique resolution for a name, they can easily arise when other sorts of identifiers have been translated by a mechanism like DDDS into "domain name syntax." Kolkman, et al. Expires May 3, 2012 [Page 21] Internet-Draft Applications in DNS October 2011 Telephone calls, for example, are traditionally routed through highly mediated networks, and an attempt to find a route for a call often requires finding an appropriate intermediary based on the source network and location rather than finding an endpoint (see the distinction between the Look-Up Function and Location Routing Function in [RFC5486]). Moreover, the need for selective responses and confidentially is easily motivated when the data returned by the DNS is no longer "describing protocol addresses, network resources and services," but instead arbitrary data. Although ENUM was originally intended for deployment in the global public root of the DNS (under e164.arpa), for example, the requirements of maintaining telephone identifiers in the DNS quickly steered operators into private deployments. In private environments, it is also easier to deploy any necessary extensions than it is in the public DNS: 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, 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 deployment in private and constrained environments as the basis of a standard solution. When proprietary parameters or extensions are deployed in these private environments, experience teaches us that these implementations will begin to interact with the public DNS, and that the private practices will leak. The history of SIP, for example, was full of supposedly private extensions (notably the "P-" headers) which saw widespread success and use outside of the constrained environments for which they were specifically designed. Therefore, keeping these features within higher-layer applications rather than offloading them to the DNS is preferred. Kolkman, et al. Expires May 3, 2012 [Page 22] Internet-Draft Applications in DNS October 2011 5. 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 critical that application designers who intend to use the DNS to support their applications consider the implications that their uses have for the behavior of resolvers, intermediaries including caches and recursive resolvers, and authoritative servers. It is likely that the DNS provides a good match whenever applications needs are aligned with the following properties: Data stored in the DNS can be propagated and cached using conventional DNS mechanisms, without intermediaries needing to understand exceptional logic (considerations beyond the name, type and class of the query) used by the authoritative server to formulate responses Data stored in the DNS is indexed by keys that do not violate the syntax or semantics of domain names Applications invoke the DNS to resolve complete names, not fragments Answers do not depend on an application-layer identity of the entity doing the query Ultimately, applications invoke the DNS to assist in communicating with the domain of the name they are resolving Whenever one of the four properties above does not apply to one's 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: Populating metadata about domain boundaries within the tree - the points of administrative delegation in the DNS are something that applications should in general not be aware off Domain names derived from identifiers that do not share a semantics or administrative model compatible with the DNS Kolkman, et al. Expires May 3, 2012 [Page 23] Internet-Draft Applications in DNS October 2011 Selective confidentiality of data stored in and provided by the DNS DNS responses not fitting into UDP packets, unless EDNS0 is available, and only then with the caveats discussed above 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 similar to 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. Many applications already use HTTP because of widespread support for it in middleboxes. Similarly, HTTP has numerous ways to provide the necessary authentication, authorization and confidentiality properties that some features require, as well as the redirection properties discussed in Section 3.4. The overhead of using HTTP may not be appropriate for all environments, but even in environments where a more lightweight protocol is appropriate, DNS is not the only alternative. 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 [I-D.faltstrom-uri] 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. Kolkman, et al. Expires May 3, 2012 [Page 24] Internet-Draft Applications in DNS October 2011 6. Security Considerations Many of the concerns about how applications use the DNS discussed in this document involve security. 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. As Section 3.2.1 observes, large data in the DNS can provide a means of generating reflection attacks, and without the remedies discussed in that section (especially the use of EDNS0 and TCP) the presence of large records is not recommended. Section 3.4 discusses a security problem concerning redirection that has surfaced in a number of protocols (see [I-D.barnes-hard-problem]). 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. The existing feature set of DNSSEC is however sufficient for providing security for most of the ways that applications traditionally have used the DNS. Nothing in this document is intended to discourage either the implementation, deployment, or use of Secure DNS Dynamic Updates ([RFC2136], [RFC3007]) to the DNS system, DNS Security ([RFC4033] and related specifications), or the use of Secure DNS Dynamic Updates in combination with DNS Security. Kolkman, et al. Expires May 3, 2012 [Page 25] Internet-Draft Applications in DNS October 2011 7. IANA Considerations This document contains no considerations for the IANA. Kolkman, et al. Expires May 3, 2012 [Page 26] Internet-Draft Applications in DNS October 2011 8. IAB Members Internet Architecture Board Members at the time this document was published were: [TO BE INSERTED] Kolkman, et al. Expires May 3, 2012 [Page 27] Internet-Draft Applications in DNS October 2011 9. 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 May 3, 2012 [Page 28] Internet-Draft Applications in DNS October 2011 10. 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.bellis-enum-send-n] Bellis, R., "IANA Registrations for the 'Send-N' Enumservice", draft-bellis-enum-send-n-02 (work in progress), June 2008. [I-D.faltstrom-uri] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", draft-faltstrom-uri-06 (work in progress), October 2010. [I-D.ietf-enum-unused] Stastny, R., Conroy, L., and J. Reid, "IANA Registration for Enumservice UNUSED", draft-ietf-enum-unused-04 (work in progress), March 2008. [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, "EDNS Option Code for SIP and PSTN Source Reference Info", draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work in progress), October 2011. [I-D.livingood-dns-redirect] Creighton, T., Griffiths, C., Livingood, J., and R. Weber, "DNS Redirect Use by Service Providers", draft-livingood-dns-redirect-03 (work in progress), October 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. [I-D.vandergaast-edns-client-ip] Contavalli, C., Gaast, W., Leach, S., and D. Rodden, "Client IP information in DNS requests", draft-vandergaast-edns-client-ip-01 (work in progress), May 2010. Kolkman, et al. Expires May 3, 2012 [Page 29] Internet-Draft Applications in DNS October 2011 [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. [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. [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. [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996. [RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2052, October 1996. [RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997. [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 May 3, 2012 [Page 30] Internet-Draft Applications in DNS October 2011 [RFC2826] Internet Architecture Board, "IAB Technical Comment on the Unique DNS Root", RFC 2826, May 2000. [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000. [RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 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. Kolkman, et al. Expires May 3, 2012 [Page 31] Internet-Draft Applications in DNS October 2011 [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 Subject Alternative Name for Expression of Service Name", RFC 4985, August 2007. [RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia Interconnect (SPEERMINT) Terminology", RFC 5486, March 2009. [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. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. Kolkman, et al. Expires May 3, 2012 [Page 32] Internet-Draft Applications in DNS October 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 May 3, 2012 [Page 33]