diff options
Diffstat (limited to 'doc/rfc/rfc6950.txt')
| -rw-r--r-- | doc/rfc/rfc6950.txt | 1739 |
1 files changed, 1739 insertions, 0 deletions
diff --git a/doc/rfc/rfc6950.txt b/doc/rfc/rfc6950.txt new file mode 100644 index 0000000..19ba03a --- /dev/null +++ b/doc/rfc/rfc6950.txt @@ -0,0 +1,1739 @@ + + + + + + +Internet Architecture Board (IAB) J. Peterson +Request for Comments: 6950 NeuStar, Inc. +Category: Informational O. Kolkman +ISSN: 2070-1721 NLnet Labs + H. Tschofenig + Nokia Siemens Networks + B. Aboba + Skype + October 2013 + + + Architectural Considerations on Application Features in the DNS + +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; some, for example, transform + identifiers other than domain names into formats that the DNS can + process, and then fetch application data or service location data + from the DNS. Proposals incorporating sophisticated application + behavior using DNS as a substrate have raised questions about the + role of the DNS as an application platform. This document explores + the architectural consequences of using the DNS to implement certain + application features, and it provides guidance to future application + designers as to the limitations of the DNS as a substrate and the + situations in which alternative designs should be considered. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Architecture Board (IAB) + and represents information that the IAB has deemed valuable to + provide for permanent record. It represents the consensus of the + Internet Architecture Board (IAB). Documents approved for + publication by the IAB are not a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6950. + + + + + + + + +Peterson, et al. Informational [Page 1] + +RFC 6950 Application Features in DNS October 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + +Table of Contents + + 1. Motivation ......................................................2 + 2. Overview of DNS Application Usages ..............................4 + 2.1. Locating Services in a Domain ..............................5 + 2.2. NAPTR and DDDS .............................................6 + 2.3. Arbitrary Data in the DNS ..................................8 + 3. Challenges for the DNS .........................................10 + 3.1. Compound Queries ..........................................10 + 3.1.1. Responses Tailored to the Originator ...............12 + 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 ......................18 + 3.4. Domain Redirection ........................................20 + 4. Private DNS and Split Horizon ..................................21 + 5. Principles and Guidance ........................................23 + 6. Security Considerations ........................................25 + 7. IAB Members at the Time of Approval ............................26 + 8. Acknowledgements ...............................................26 + 9. Informative References .........................................27 + +1. Motivation + + The Domain Name System (DNS) has long provided a general means of + translating domain names into Internet Protocol addresses, which + makes the Internet easier to use by providing a valuable layer of + indirection between names and lower-layer protocol elements. + [RFC0974] documented a further use of the DNS: to locate an + application service operating in a domain, via the Mail Exchange (MX) + Resource Record; these records help email addressed to the domain to + find a mail service for the domain sanctioned by the zone + administrator. + + + + + + +Peterson, et al. Informational [Page 2] + +RFC 6950 Application Features in DNS October 2013 + + + 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) + Resource Record (originally described in [RFC2168]), especially as it + evolved into the more general Dynamic Delegation Discovery System + (DDDS) [RFC3401] framework, added a generic mechanism for storing + application data in the DNS. Primarily, this involved a client-side + 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 examples of this are + telephone numbers, as resolved by the DDDS application ENUM. Recent + work, such as DomainKeys Identified Mail (DKIM) [RFC6376], has + enabled security features of applications to be advertised through + the DNS, via the TXT Resource Record. + + The scope of application usage of the DNS has thus increased over + time. Applications in many environments require features such as + confidentiality, 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. However, some + proposed usages of, and extensions to, the DNS have become misaligned + with both the DNS architecture and the DNS protocol. If we take the + example of confidentiality, we see that in the global public DNS, the + resolution of domain names to IP addresses is an exchange of public + information with no expectation of confidentiality. Thus, the + underlying query/response protocol has no 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 policy can the DNS maintain confidential records, by + providing distinct answers to the private and public users of the + DNS. In support of load-balancing or other optimizations, a DNS + server may return different addresses in response to queries from + different sources, or even no response at all; see Section 3.1.1 for + details. + + This document provides guidance to application designers and + application protocol designers looking to use the DNS to support + features in their applications. It provides an overview of past + application usage of the DNS as well as a review of proposed new + usages. It identifies concerns and trade-offs and provides guidance + on 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 + + + +Peterson, et al. Informational [Page 3] + +RFC 6950 Application Features in DNS October 2013 + + + 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 applications that rely on the DNS for the + implementation of certain features, 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 + demand further changes and extensions that are fundamentally at odds + with the strengths of the DNS. + +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 transitioning the "mapping between host names... and + ARPA Internet addresses" from a global table (the original "hosts" + 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 service discovery mechanism could be built + for each such application protocol that needed this functionality, + the universal support for the DNS encourages installing these + features into its public tree rather than inventing something new. + Thus, over time, several other applications leveraged DNS resource + records for locating services in a domain or for storing application + data associated with a domain in the DNS. This section gives + examples of various types of DNS usage by applications to date. + + + + + + + +Peterson, et al. Informational [Page 4] + +RFC 6950 Application Features in DNS October 2013 + + +2.1. Locating Services in a Domain + + The MX Resource Record provides the simplest example of an + application advertising its domain-level 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], though more recently DNS-based Service + Discovery (DNS-SD) [RFC6763] codifies service instance naming + conventions for use across applications to locate services in a + domain). + + 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 applications through the Service + (SRV) Resource Record (originally described in [RFC2052]). The SRV + record allows DNS resolvers to query for particular services and + underlying transports (for example, HTTP running over Transport Layer + Security (TLS) [RFC2818]) and to 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 the way that applications pass domain 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 than requiring an application to guess which + particular host handles mail on behalf of the domain. While naming + conventions continue to abound ("www.example.com") for applications + like web browsing, SRV records allow applications to query for an + application-specific protocol and transport in the domain. For the + Lightweight Directory Access Protocol (LDAP), the SRV service name + corresponds to the URL scheme of the identifier invoked by the + application (e.g., when "ldap://example.com" is the identifier, the + SRV query passed to the resolver is for "_ldap._tcp.example.com"); + for other applications, the SRV service name that the application + passes to the resolver may be implicit in the identifier rather than + + + +Peterson, et al. Informational [Page 5] + +RFC 6950 Application Features in DNS October 2013 + + + explicit. In either case, the application delivers the service name + to the DNS to find the location of the host of that service for the + domain, the port where the service resides on that host, additional + locations or ports for load-balancing and fault tolerance, and + related application features. + + Locating specific services for a domain was the first major function + for which applications started using the DNS beyond 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 applications that acquire MX (or SRV) records might need + to perform further queries or transformations in order to arrive at + an eventual domain name that will resolve to the IP addresses for the + service, [RFC1034] allowed 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. At the same time, this is an example of an + extension of the DNS that cannot be universally relied on: many DNS + resolver implementations will ignore the addresses in the additional + section of the DNS answers because of the trustworthiness issues + described in [RFC2181]. + +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 Uniform + Resource Identifier (URI) [RFC3986] framework, which incorporated + Uniform Resource 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 allows + identifiers with no recognizable domain component to be treated as + domain names for the purpose of name resolution. Once these + transformations result in a domain name, applications can 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 describes, and then two fields that can contain + translations: a "replacement" field or a "regexp" (regular + expression) field, only one of which appears in a given NAPTR record + (see [RFC2168]). 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 + + + + + +Peterson, et al. Informational [Page 6] + +RFC 6950 Application Features in DNS October 2013 + + + "regexp", on the other hand, allows regular expression + transformations on the original URI intended to turn it into an + identifier that the DNS can 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 domain 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 found in the in-addr domain [RFC0883], in which IPv4 + addresses are encoded as domain names by applying a string + preparation algorithm that required reversing the octets and treating + each individual octet as a label in a domain name -- thus, for + example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. This + allowed resolvers to query the DNS to learn name(s) associated with + an IPv4 address. The same mechanism has been applied to IPv6 + addresses [RFC3596] and other sorts of identifiers that lack 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 described in [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 domain + 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 the more mature form of the NAPTR standard, in the Dynamic + Delegation Discovery System (DDDS) [RFC3401] framework, the initial + transformation of an identifier (such as a telephone number) to a + domain name was called the "First Well Known Rule". The address- + reversing mechanism, whereby a query name is formed by reversing an + IPv4 address and prepending it to the in-addr.arpa domain, is + generalized for the use of NAPTR: each application defines a "First + Well Known Rule" that translates a specific resource into a query + name. 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 regarding 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 + + + + + +Peterson, et al. Informational [Page 7] + +RFC 6950 Application Features in DNS October 2013 + + + created by the "First Well Known Rule" correspond to any points of + administrative delegation inherent in the structure of the + identifier. + + While this ability to look up names "which are not in domain name + syntax" does not change the underlying DNS protocol -- 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 + + URI encoding has ways of encapsulating basically arbitrary data: the + most extreme example is a data URL [RFC2397]. Thus, the returned + NAPTR record might be interpreted to produce output other than a + domain name that would subsequently be resolved to IP addresses and + contacted for a particular application -- it could give a literal + result that would be consumed by the application. Originally, as + discussed in [RFC2168], the intended applicability of the regular + expression field in NAPTR was narrower: 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 to + "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 expression 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 that did not serve any of those aforementioned needs. + According to [RFC3402], the output of DDDS is wholly application- + specific: "the Application must define 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 and + receiving at the end of the process information about the + manufacturer. + + Historically speaking, NAPTR did not 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 + + + +Peterson, et al. Informational [Page 8] + +RFC 6950 Application Features in DNS October 2013 + + + 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". + [RFC1035] defined the TXT record, a means to store arbitrary strings + in the DNS; [RFC1035] also 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 requires no registration process. [RFC1464] + experimented with a means of incorporating name/value pairs to the + TXT record structure, which allowed applications to distinguish + different chunks of data stored in a TXT record -- surely not just + "descriptive text" as the TXT originally specified. 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 others, 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 many applications. + Recently, DKIM [RFC6376] sidestepped the problem of TXT ambiguity by + storing keys under a specialized DNS naming structure that includes + the component "_domainkeys", which serves to restrict the scope of + that TXT solely to DKIM use. Storing keys in the DNS became the + preferred solution for DKIM for several reasons: notably, because + email applications already queried the DNS in their ordinary + operations, 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 on the originating + side) 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 storing large data in the DNS, as + discussed in Section 3.2.1, as well as with the DKIM namespace + conventions that complicate the use of DNS wildcards (as discussed in + Section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]). + If prefixes are used to identify TXT records used by an application, + potentially the use of wildcards may furthermore cause leakages that + other applications will need to detect. + + + + + + + +Peterson, et al. Informational [Page 9] + +RFC 6950 Application Features in DNS October 2013 + + +3. Challenges for the DNS + + The methods discussed in the previous section for transforming + arbitrary identifiers into domain names and 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 a data URL, the DNS could effectively + implement the entire application feature set of any simple query- + response protocol. Effectively, the DDDS framework considers the DNS + a generic database -- indeed, the DDDS framework was designed to work + with any sort of underlying database; as [RFC3403] says, 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 for + applications to 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. The global public DNS was not designed to provide these + sorts of properties, and extending the DNS protocols to encompass + them could result in 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, or can only partly, 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, DNS RRsets are uniquely identified by domain name, + resource record type, and class. DNS queries are based on this + 3-tuple, and the replies are resource record sets that are to be + treated as atomic data elements (see [RFC2181]); to applications, the + behavior of the DNS has traditionally been that of an exact-match + query-response lookup mechanism. Outside of the DNS space, however, + there are plenty of query-response applications that require a + + + +Peterson, et al. Informational [Page 10] + +RFC 6950 Application Features in DNS October 2013 + + + compound or relational search, one taking into account more than one + factor in formulating a response or one that 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 generating a + route. While in its original conception ENUM hoped to circumvent the + traditional Public Switched Telephone Network (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 append 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. For + example, 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 this particular 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 dubious, especially if more than one + additional parameter is required and the presence of parameters is + optional so that the application needs multiple queries to assess the + completeness of the information it needs to perform its function. + + As an alternative, it has been proposed that we piggyback additional + query parameters as Extension Mechanisms for DNS (EDNS(0)) extensions + (see [RFC6891]). This might be problematic for three reasons. + First, supporting EDNS(0) extensions requires significant changes to + name server behavior; these changes need to be supported by the + authoritative and recursive name servers on which the application + relies and might be very hard to realize on a global scale. In + addition, the original stated applicability of the EDSN(0) mechanism, + as [RFC2671] states, was to "a particular transport level message and + not to any actual DNS data", and consequently the OPT Resource + + + +Peterson, et al. Informational [Page 11] + +RFC 6950 Application Features in DNS October 2013 + + + Records it specifies are never to be forwarded. The use of EDNS(0) + for compound queries, however, clearly is intended to discriminate + actual DNS data rather than to facilitate transport-layer handling. + Finally, [RFC6891] also specifies that "OPT RRs MUST NOT be cached, + forwarded, or stored" (see the next paragraph). For these reasons, + this memo recommends against crafting compound DNS queries by using + EDNS(0). + + 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 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. Therefore, were EDNS(0) to be employed + this way, its attributes would not be transitive, and if this were + not considered where intermediaries are employed, as is normally the + case in the global DNS, brokenness might occur. + +3.1.1. Responses Tailored to the Originator + + DNS responses tailored to the identity of their originator, where + some sort of administrative identity of the originator must be + conveyed to the DNS, constitute the most important subcase of these + compound queries. 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 breach 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 [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 technology such as the one + described by [EDNS-CLIENT-IP] would 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. As a result, such technology cannot be rolled out in an + incremental, unilateral fashion but could only be successful when + implemented bilaterally (by authoritative server and recursive + resolver); this is a significant bar to deployment. + + + +Peterson, et al. Informational [Page 12] + +RFC 6950 Application Features in DNS October 2013 + + + 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 + selected, and potentially sensitive, 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 deployments (see Section 4), which + typically rely on an underlying security layer, such as a physical + network, a clear perimeter demarcation at a network perimeter point + (with network-layer anti-spoofing countermeasures), 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 that should not be useful on + the public Internet anyway, in some cases this leakage would reveal + topology or other information that the name server administrator + hopes to keep private. More recently, TSIG [RFC2845] has been + employed as a way of selecting among "views" in BIND; this provides a + stronger level of security than merely relying on the source IP + address, but typically many users share the same secret to access a + given view, and moreover TSIG does not provide confidentiality + properties to DNS messages -- without network-layer separation + between users of different views, eavesdroppers might capture the DNS + queries and responses. + + The use of source IP addresses as a discriminator to select DNS + resource records, regardless of its lack of acceptance by the + standards community, has 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; for + example, [EDNS-OPT-CODE] provides a SIP URI in an EDNS(0) parameter. + Effectively, this 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 approximate a confidentiality mechanism per resource record, + where only a specific set of originators is 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. + However, without any underlying cryptographic security, this + mechanism must rely on external layers for security (such as VPNs) + rather than any direct assurance. Again, caching, forwarding, 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 likely require significant rearchitecture + of the DNS. + + + +Peterson, et al. Informational [Page 13] + +RFC 6950 Application Features in DNS October 2013 + + +3.2. Using DNS as a Generic Database + + As previously noted, applications can use a method like the "First + Well Known Rule" of DDDS to transform an arbitrary string into a + domain name and then receive from the DNS arbitrary data stored in + TXT RRs, in the "regexp" of NAPTRs, or even in custom records. Some + query-response applications, however, require queries and responses + that simply fall outside the syntactic capabilities of the DNS. For + example, domain names themselves must consist of labels that do not + exceed 63 octets, while the total length of the encoded name may not + exceed 255 octets, and applications that use label characters outside + the traditional ASCII set may run into problems (however, see the + discussion in [RFC6055], Section 3 for definitive guidance on the use + of non-ASCII in the DNS). 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. Some applications today use + quite large data URLs (containing a megabyte or more of data) as + workarounds in environments where only URIs can syntactically appear + (for example, in Apple iOS, to pass objects between applications). + 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". And while EDNS(0) allows for mechanisms + to negotiate DNS message sizes larger than the traditional 512 + octets, there is a high risk that a long payload will cause UDP + fragmentation, in particular when the DNS message already carries + DNSSEC information. If EDNS(0) is not available, or the negotiated + EDNS(0) packet size is too small to fit the data, or UDP fragments + are dropped, the DNS may (eventually) resort to using TCP. While TCP + 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 UDP-only DNS queries with a forged source address, and the + + + +Peterson, et al. Informational [Page 14] + +RFC 6950 Application Features in DNS October 2013 + + + victim receives the response. The attacker relies on amplification, + where a small query generates a large response directed at the + victim. Where the responder supports EDNS(0), 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 or "heavier" transport protocols such as TCP. The + bandwidth that can be mustered in a reflective amplification attack + directed by a botnet reflecting off a recursive name server on a + high-bandwidth network is sobering. For example, if the responding + resolver 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 200 Gbps of traffic on the victim, more than + sufficient to congest any site on today's Internet. + + DNS reflection attacks typically utilize UDP queries; it is + prohibitively difficult to complete a TCP three-way handshake begun + from a forged source address for DNS reflection attacks. Unless the + attacker uses EDNS(0) [RFC6891] 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 + EDNS(0). As the large disparity between the size of a query and size + of the response creates this amplification, techniques for mitigating + this disparity should be further studied, though this is beyond the + scope of this memo (for an analysis of the effects of limiting + EDNS(0) responses while still accommodating DNSSEC, see [Lindsay]). + For example, some implementations could limit EDNS(0) responses to a + specific ratio compared to the request size, where the precise ratio + can be configured on a per-deployment basis (taking into account + DNSSEC response sizes). Without some means of mitigating the + potential for amplification, EDNS(0) could cause significant harm. + + In summary, there are two operational forces that tend to drive the + practically available EDNS(0) sizes down: possible UDP fragmentation + and minimizing amplification in case of reflection attacks. DNSSEC + data will use a significant fraction of the available space in a DNS + packet. Therefore -- appreciating that given the current DNSSEC and + + + + + + +Peterson, et al. Informational [Page 15] + +RFC 6950 Application Features in DNS October 2013 + + + EDNS(0) deployment experience, precise numbers are impossible to give + -- the generic payload available to other DNS data, given the premise + that TCP fallback is to be minimized, is likely to be closer to + several hundred octets than a few thousand octets. + +3.3. Administrative Structures Misaligned with the DNS + + While the DDDS framework enables any sort of alphanumeric data to + serve as a domain name through the application of the "First Well + Known Rule", the delegative structure of the resulting domain name + may not reflect any administrative division of responsibilities + inherent in the original data. While [RFC3402] requires only that + the "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 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 administrative domain with no + points of administrative delegation from the country-code + administrator, e.g., 1.e164.arpa, down to the ultimate assignee of a + number. Under the assumption that one administrative domain is + maintained within one DNS zone containing potentially over five + billion names, scalability difficulties manifest in a number of + areas: the scalability that results from caching depends on these + 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 assignees for ported numbers must + propagate within fifteen minutes of a change in administration. + Jointly, these two problems make caching the zone extremely + problematic. Moreover, traditional tools for DNS replication, such + + + +Peterson, et al. Informational [Page 16] + +RFC 6950 Application Features in DNS October 2013 + + + as the zone transfer protocols AXFR [RFC1034] and IXFR [RFC1995], + might not scale to accommodate zones with these dimensions and + properties. + + In practice, the maximum sizes of telephone number administrative + domains are closer to 300M (the current amount of allocated telephone + numbers in the United States today -- still more than three times the + number of .com domain names), and one can alleviate some of the + scalability issues mentioned above by artificially dividing the + administrative domain into a hierarchy of DNS zones. Still, the fact + that traditional DNS management tools no longer apply to the + structures that an application tries to provision in the DNS is a + clue that the DNS might not be the right place for an application to + store its data. + + While DDDS is the most obvious example of these concerns, the point + is more generic: for example, were address portability to be + implemented for IP addresses and their administration thus to become + non-hierarchical, the same concerns would apply to in-addr.arpa + names. 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 domains represent the same "site" when + comparing security credentials with URLs (see Section 3.4 below for + more on this). This has also caused known problems in determining + the scope of web cookies, in contexts where applications must infer + where administrative domains end in order to grant cookies that are + as narrowly scoped as possible. + + In summary, the "First Well Known Rule" of DDDS provides a capability + that transforms arbitrary strings into domain names, but those names + play well with the DNS only when the input strings have an + administrative structure that maps to DNS delegations. In the first + place, delegation implies some sort of hierarchical structure. Any + mechanism to map a hierarchical identifier into a domain name should + be constructed such that the resulting domain 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, then that string probably is not a good + candidate for translating into a domain name. + + + + + +Peterson, et al. Informational [Page 17] + +RFC 6950 Application Features in DNS October 2013 + + +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 the name is complete -- that it is not a fragment of a + domain 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; proposed solutions include + metadata in the DNS that describes the contents and structure of ENUM + DNS trees to help applications handle incomplete queries or queries + for domains not in use. + + In particular, the "send-n" proposal [ENUM-Send-N] hoped 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 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 that 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 this mechanism simply reduces the time the system + will wait before sending an ENUM query after collecting the final + dialed digit. A tangentially related proposal, [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 + records available in the DNS, whether or not the domain had been + allocated by a registry to a registrant (which is a different + condition than a name merely being unresolvable, per the semantics of + NXDOMAIN). + + + + +Peterson, et al. Informational [Page 18] + +RFC 6950 Application Features in DNS October 2013 + + + 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 ends has some features in common with the + traditional parent zone use of the NS record type, except that + 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 one administrative domain would need to + remain synchronized with the state of the resources it predicts in + another administrative domain in the DNS namespace, in a case like + overlap dialing where the carrier delegates to a zone controlled by + an enterprise. When dealing with external resources associated with + other namespaces, like number assignments in the PSTN or the + databases of a registry operator, other synchronization requirements + arise; maintaining that synchronization requires that the DNS have + "semi-real time" updates that may conflict with scale and caching + mechanisms of the DNS. + + Placing metadata in the DNS 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 e164.arpa + root 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 "infrastructure" ENUM models (see Section 4). + Ultimately, these metadata proposals share some qualities with DNS + redirection services offered by ISPs (for example, [DNS-REDIRECT]) + that "help" web users who try to browse to sites that do not exist. + Similarly, metadata proposals like [ENUM-UNUSED] create DNS records + for unallocated zones that redirect to a service provider's web page. + However, in the [DNS-REDIRECT] cases, at least the existence or + non-existence of a domain name is a fact about the Internet + namespace, rather than about an external namespace like the telephony + E.164 namespace (which must be synchronized with the DNS tree in the + metadata proposals). In send-n, different leaf zones that administer + telephone numbers of different lengths can only provision their hints + at their own apex, which provides an imperfect optimization: they + cannot install it themselves in a parent, both because they lack the + authority and because different zones would want to provision + contradictory data. The later the hint appears in the tree, however, + the less optimization will result. An application protocol designer + managing identifiers whose administrative model does not map well + onto the DNS namespace and delegations structure would be better + served to implement such features outside the DNS. + + + + + +Peterson, et al. Informational [Page 19] + +RFC 6950 Application Features in DNS October 2013 + + +3.4. Domain Redirection + + Most Internet application services provide a redirection feature -- + when one attempts to contact a service, the service may refer the + person to a different service instance, potentially in another + domain, that is for whatever reason better suited to service a + request. In HTTP and SIP, for example, this feature is implemented + by the 300 class responses containing one or more URIs, which 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 protocols supporting redirection, such as HTTP and SIP, have + available security mechanisms, including TLS, that can use + certificates to attest 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; + this requires a virtual hosting service to possess a certificate + corresponding to the hosted domain. (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]). This restriction rules out many styles + of hosting deployments common in the web world today, however. + [HARD-PROBLEM] explores this problem space. [RFC6125] proposes a + solution for all applications that use TLS, which relies on new + application-specific identifiers in certificates, as does [RFC4985]); + note, however, that support for such certificates would require + + + +Peterson, et al. Informational [Page 20] + +RFC 6950 Application Features in DNS October 2013 + + + changes to existing certificate authority practices as well as + application behavior. With DNSSEC in place, DNS-based Authentication + of Named Entities (DANE) [RFC6394] offers another way to bind + certificates to particular applications and services. + + All of these application-layer measures attempt to mirror the + delegation of administrative authority in the DNS, when the DNS + itself serves as the ultimate authority on how domains are delegated. + (Note: changing the technical delegation structure by changing NS + records in the DNS is not the same as administrative delegation, + e.g., when a domain changes ownership.) 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 an administrative 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. + This inevitably gives rise to various design trade-offs involving + performance, load, and related factors, but in these application + environments, the security properties typically take priority. + +4. Private DNS and Split Horizon + + The classic view of the uniqueness of domain names in the DNS 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. + + [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; while some deployments + differentiate internal queries from public queries by the source IP + address, the concerns in Section 3.1.1 relating to trusting source IP + addresses apply to such deployments. When the internal address space + range is private [RFC1918], this makes it both easier for the server + to discriminate public from private and harder for public entities to + impersonate nodes in the private network. Networks that are made + + + +Peterson, et al. Informational [Page 21] + +RFC 6950 Application Features in DNS October 2013 + + + 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 distinct networks. + + The use cases that motivate split-horizon DNS typically involve + restricting access to some network services -- intranet resources + such as internal web sites, 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 such as the + "First Well Known Rule" of DDDS into "domain name syntax". Telephone + calls, for example, are traditionally routed through highly mediated + networks, in which 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 responses tailored to + the originator, and for confidentiality, is easily motivated when the + data returned by the DNS is no longer "describing protocol addresses, + network resources and services" [RFC2826] but instead is arbitrary + data. Although, for example, ENUM was originally intended for + deployment in the global public root of the DNS (under e164.arpa), + 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 more 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 + + + +Peterson, et al. Informational [Page 22] + +RFC 6950 Application Features in DNS October 2013 + + + 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 private + environments, experience teaches us that these implementations will + begin to interact with the public DNS and that the private practices + will leak. + + While such leakage is not a problem when using the mechanisms + described in Sections 3.1, 3.2, and 3.5 (with private RR types) of + [RFC5507], other extension mechanisms might cause confusion or harm + if leaked. The use of a dedicated suffix (Section 3.3 of [RFC5507]) + in a private environment might cause confusion if leaked to the + public Internet, for example. + + That this kind of leakage of protocol elements from private + deployments to public deployments does happen has been demonstrated, + for example, with SIP: SIP implemented a category of supposedly + private extensions ( the "P-" headers) that saw widespread success + and use outside of the constrained environments for which they were + specifically designed. There is no reason to think that + implementations with similar "private" extensions to the DNS + protocols would not similarly end up in use in public environments. + +5. Principles and Guidance + + The success of the global public DNS relies on the fact that it is a + distributed database, one that has the property that it is loosely + coherent and offers lookup instead of search functionality. Loose + coherency means that answers to queries are coherent within the + bounds of data replication between authoritative servers (as + controlled by the administrator of the zone) and caching behavior by + recursive name servers. Today, this term increasingly must also + include load-balancing or related features that rely on the source IP + address of the resolver. 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. + + + + + + + + + + + + +Peterson, et al. Informational [Page 23] + +RFC 6950 Application Features in DNS October 2013 + + + It is likely that the DNS provides a good match whenever the needs of + applications are aligned with the following properties: + + o 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 + + o Data stored in the DNS is indexed by keys that do not violate the + syntax or semantics of domain names + + o Applications invoke the DNS to resolve complete names, not + fragments + + o Answers do not depend on an application-layer identity of the + entity doing the query + + o Ultimately, applications invoke the DNS to assist in communicating + with a service whose name is resolved through the DNS + + Whenever one of the five 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, if one has to worry about + the following items, then these items are good indicators that the + DNS is not the appropriate tool for solving problems: + + o Populating metadata about domain boundaries within the tree -- the + points of administrative delegation in the DNS are something that + applications are not in general aware of + + o Domain names derived from identifiers that do not share a semantic + or administrative model compatible with the DNS + + o Selective disclosure of data stored in and provided by the DNS + + o DNS responses not fitting into UDP packets, unless EDNS(0) is + available, and only then with the caveats discussed in + Section 3.2.1 + + In cases where applications require these sorts of features, they are + likely better instantiated by independent application-layer protocols + than the DNS. For example, the objects that HTTP can carry in both + 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 + + + +Peterson, et al. Informational [Page 24] + +RFC 6950 Application Features in DNS October 2013 + + + the redirection properties discussed in Section 3.4. These + differences highlight the fact that the DNS and HTTP offer very + different services and have different applicabilities; while both are + query-response protocols, HTTP should not be doing the job of DNS, + and DNS should not be doing the job of HTTP. Similarly, DNS should + not be doing the job of Diameter, LDAP, or other application-layer + protocols. The overhead of using any application-layer protocol may + not be appropriate for all environments, of course, but even in + environments where a more lightweight protocol is appropriate, DNS is + usually 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 [URI-RR] Resource Records + can contain URIs, those URIs can in turn point to an external query- + response service such as an HTTP service where more syntactically and + semantically rich queries and answers might be exchanged. Any + protocol designer considering where to implement features must + perform their own gap analysis and determine whether or not + implementing some features is worth the potential cost in increased + network state, latency, and so on, but implementing some features + simply requires heavier structures than others. + +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 (regarding the use of EDNS(0) and + TCP) the presence of large sets of records (e.g., ANY queries) is not + recommended. Section 3.4 discusses a security problem concerning + redirection that has surfaced in a number of protocols (see + [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, nor a confidential mechanism. + Some implementations may support authenticating users through TSIG, + provided that the security association with a compliant server has + been pre-established, though authentication is typically not needed + + + +Peterson, et al. Informational [Page 25] + +RFC 6950 Application Features in DNS October 2013 + + + for queries in the global public DNS. The existing feature set of + DNSSEC is, however, sufficient for providing security for most of the + ways that applications traditionally have used the DNS. The + deployment of DNSSEC ([RFC4033] and related specifications) is + heartily encouraged. Nothing in this document is intended to + discourage the implementation, deployment, or use of Secure DNS + Dynamic Updates [RFC3007], though this document does recommend that + large data in the DNS be treated in accordance with the guidance in + Section 3.2.1. + +7. IAB Members at the Time of Approval + + Internet Architecture Board Members at the time this document was + approved were: + + Bernard Aboba + Jari Arkko + Marc Blanchet + Ross Callon + Alissa Cooper + Spencer Dawkins + Joel Halpern + Russ Housley + David Kessens + Danny McPherson + Jon Peterson + Dave Thaler + Hannes Tschofenig + +8. Acknowledgements + + The IAB appreciates the comments and often spirited disagreements of + Eric Osterweil, John Levine, Stephane Bortzmeyer, Ed Lewis, Dave + Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson, Patrik Faltstrom, + and Eliot Lear. + + + + + + + + + + + + + + + + +Peterson, et al. Informational [Page 26] + +RFC 6950 Application Features in DNS October 2013 + + +9. Informative References + + [DNS-REDIRECT] + Creighton, T., Griffiths, C., Livingood, J., and R. Weber, + "DNS Redirect Use by Service Providers", Work in Progress, + October 2010. + + [EDNS-CLIENT-IP] + Contavalli, C., van der Gaast, W., Leach, S., and D. + Rodden, "Client IP information in DNS requests", Work in + Progress, May 2010. + + [EDNS-OPT-CODE] + Kaplan, H., Walter, R., Gorman, P., and M. Maharishi, + "EDNS Option Code for SIP and PSTN Source Reference Info", + Work in Progress, October 2011. + + [ENUM-Send-N] + Bellis, R., "IANA Registrations for the 'Send-N' + Enumservice", Work in Progress, June 2008. + + [ENUM-UNUSED] + Stastny, R., Conroy, L., and J. Reid, "IANA Registration + for Enumservice UNUSED", Work in Progress, March 2008. + + [HARD-PROBLEM] + Barnes, R. and P. Saint-Andre, "High Assurance + Re-Direction (HARD) Problem Statement", Work in Progress, + July 2010. + + [Lindsay] Lindsay, G., "DNSSEC and DNS Amplification Attacks", + April 2012. + + [RFC0882] Mockapetris, P., "Domain names: Concepts and facilities", + RFC 882, November 1983. + + [RFC0883] Mockapetris, P., "Domain names: Implementation + specification", RFC 883, November 1983. + + [RFC0974] Partridge, C., "Mail routing and the domain system", + STD 10, 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. + + + + +Peterson, et al. Informational [Page 27] + +RFC 6950 Application Features in DNS October 2013 + + + [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, B., Karrenberg, D., de 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. + + [RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform + Resource Identifiers using the Domain Name System", + RFC 2168, June 1997. + + [RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS + Specification", RFC 2181, July 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. + + [RFC2826] Internet Architecture Board, "IAB Technical Comment on the + Unique DNS Root", RFC 2826, May 2000. + + [RFC2845] Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B. + Wellington, "Secret Key Transaction Authentication for DNS + (TSIG)", RFC 2845, 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. + + + + +Peterson, et al. Informational [Page 28] + +RFC 6950 Application Features in DNS October 2013 + + + [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. + + [RFC3596] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, + "DNS Extensions to Support IP Version 6", RFC 3596, + October 2003. + + [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. + + [RFC4367] Rosenberg, J., Ed., and IAB, "What's in a Name: False + Assumptions about DNS Names", RFC 4367, February 2006. + + [RFC4398] Josefsson, S., "Storing Certificates in the Domain Name + System (DNS)", RFC 4398, March 2006. + + [RFC4732] Handley, M., Ed., Rescorla, E., Ed., and IAB, "Internet + Denial-of-Service Considerations", RFC 4732, + December 2006. + + [RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure + Subject Alternative Name for Expression of Service Name", + RFC 4985, August 2007. + + + + +Peterson, et al. Informational [Page 29] + +RFC 6950 Application Features in DNS October 2013 + + + [RFC5486] Malas, D., Ed., and D. Meyer, Ed., "Session Peering for + Multimedia Interconnect (SPEERMINT) Terminology", + RFC 5486, March 2009. + + [RFC5507] IAB, Faltstrom, P., Ed., Austein, R., Ed., and P. Koch, + Ed., "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. + + [RFC6055] Thaler, D., Klensin, J., and S. Cheshire, "IAB Thoughts on + Encodings for Internationalized Domain Names", RFC 6055, + February 2011. + + [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and + Verification of Domain-Based Application Service Identity + within Internet Public Key Infrastructure Using X.509 + (PKIX) Certificates in the Context of Transport Layer + Security (TLS)", RFC 6125, March 2011. + + [RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and + P. Roberts, "Issues with IP Address Sharing", RFC 6269, + June 2011. + + [RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., + "DomainKeys Identified Mail (DKIM) Signatures", RFC 6376, + September 2011. + + [RFC6394] Barnes, R., "Use Cases and Requirements for DNS-Based + Authentication of Named Entities (DANE)", RFC 6394, + October 2011. + + [RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service + Discovery", RFC 6763, February 2013. + + [RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms + for DNS (EDNS(0))", STD 75, RFC 6891, April 2013. + + [URI-RR] Faltstrom, P. and O. Kolkman, "The Uniform Resource + Identifier (URI) DNS Resource Record", Work in Progress, + July 2013. + + + + + + + + +Peterson, et al. Informational [Page 30] + +RFC 6950 Application Features in DNS October 2013 + + +Authors' Addresses + + Jon Peterson + NeuStar, Inc. + + EMail: jon.peterson@neustar.biz + + + Olaf Kolkman + NLnet Labs + + EMail: olaf@nlnetlabs.nl + + + Hannes Tschofenig + Nokia Siemens Networks + + EMail: Hannes.Tschofenig@gmx.net + + + Bernard Aboba + Skype + + EMail: Bernard_aboba@hotmail.com + + + + + + + + + + + + + + + + + + + + + + + + + + + +Peterson, et al. Informational [Page 31] + |