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: [email protected]


  Olaf Kolkman
  NLnet Labs

  EMail: [email protected]


  Hannes Tschofenig
  Nokia Siemens Networks

  EMail: [email protected]


  Bernard Aboba
  Skype

  EMail: [email protected]



























Peterson, et al.              Informational                    [Page 31]


You are viewing proxied material from gopher.fnord.one. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.