doc: Add RFC documents

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]
+