Ticket #165: draft-iab-dns-applications-04.txt

Network Working Group                                        J. Peterson
Internet-Draft                                             NeuStar, Inc.
Intended status: Informational                                O. Kolkman
Expires: September 13, 2012                                   NLnet Labs
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                                B. Aboba
                                                   Microsoft Corporation
                                                          March 12, 2012


    Architectural Considerations on Application Features in the DNS
                     draft-iab-dns-applications-04

Abstract

   A number of Internet applications rely on the Domain Name System
   (DNS) to support their operations.  Many applications use the DNS to
   locate services for a domain.  For example, some applications
   transform identifiers other than domain names into formats that the
   DNS can process and then fetch application data or service location

[BA] "into formats that the DNS can process": does this mean domain names?

   from the DNS.  Proposals to incorporate more sophisticated
   application behavior into the DNS, however, have raised questions
   about the applicability and extensibility of the DNS.  

[BA] I would rephrase this "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 for storing
   and retrieving certain application features, and provides guidance to

[BA] I might say "using the DNS to implement certain application features"

   future application designers as to the sorts of ways that application
   can make use of the DNS.

[BA] Might say "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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 13, 2012.

Copyright Notice




Peterson, et al.       Expires September 13, 2012               [Page 1]

Internet-Draft             Applications in DNS                March 2012


   Copyright (c) 2012 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.



























Peterson, et al.       Expires September 13, 2012               [Page 2]

Internet-Draft             Applications in DNS                March 2012


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of DNS Application Usages . . . . . . . . . . . . . .  6
     2.1.  Locating Services in a Domain  . . . . . . . . . . . . . .  6
     2.2.  NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Arbitrary Data in the DNS  . . . . . . . . . . . . . . . .  9
   3.  Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11
     3.1.  Compound Queries . . . . . . . . . . . . . . . . . . . . . 11
       3.1.1.  Responses Tailored to the Originator . . . . . . . . . 13
     3.2.  Using DNS as a Generic Database  . . . . . . . . . . . . . 14
       3.2.1.  Large Data in the DNS  . . . . . . . . . . . . . . . . 15
     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  . . . . . . . . . . . . . . . . 22
   5.  Principles and Guidance  . . . . . . . . . . . . . . . . . . . 25
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 28
   8.  IAB Members  . . . . . . . . . . . . . . . . . . . . . . . . . 29
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 30
   10. Informative References . . . . . . . . . . . . . . . . . . . . 31
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35




























Peterson, et al.       Expires September 13, 2012               [Page 3]

Internet-Draft             Applications in DNS                March 2012


1.  Motivation

   The Domain Name System (DNS) has long provided a general means of
   translating easily-memorized domain names into numeric Internet
   Protocol addresses, which makes the Internet easier to use by
   providing a valuable layer of indirection between well-known names
   and lower-layer protocol elements.  [RFC0974] documented a further
   use of the DNS: to manage application services operating in a domain
   with the Mail Exchange (MX) resource record, which helped email
   addressed to the domain to find a mail service for the domain
   sanctioned by the zone administrator.

   The seminal MX record served as a prototype for other DNS resource
   records that supported applications associated with a domain name.
   The SRV resource record [RFC2052] provided a more general mechanism
   for locating services in a domain, complete with a weighting system
   and selection among transports.  The Naming Authority Pointer (NAPTR,
   originally [RFC2168]) resource record, especially as it evolved into
   the more general Dynamic Delegation Discovery System (DDDS, [RFC3401]
   passim) framework, added a generic mechanism for storing application
   data in the DNS - an algorithm for transforming a string into a
   domain name, which might then be resolved by the DNS to find NAPTR
   records.  This enabled the resolution of identifiers that do not have
   traditional host components through the DNS; the best-known example
   of this are telephone numbers, as resolved by the DDDS application
   ENUM.  Recent work such as Domain Keys Identified Mail (DKIM,
   [RFC4871]) has enabled security features of applications to be
   advertised through the DNS, via the TXT resource record.

   The amount of application intelligence that uses the DNS has thus
   increased over time.  However, some proposed usages of, and

[BA] I would say "The development of DNS features to support
application usage has thus increased over time." 


   extensions to the DNS have become misaligned with both the DNS
   architecture and the DNS protocols.  An example of such misalignment
   is illustrated through the expectation of confidentiality: In the
   global public DNS the resolution of domain names to IP addresses is
   public information with no expectation of confidentiality, and thus
   the underlying query/response protocol has no authentication or
   encryption mechanism - typically, any security required by an
   application or service is invoked after the DNS query, when the
   resolved service has been contacted.  

[BA] The example of misalignment is given without referring to an
application that requires confidentiality and therefore can be
said to be "misaligned".  

I might introduce these considerations by stating:

   "Applications in many environments require features such as confidentiality,
   source-specific responses and database capabilities that are not easily
   provided by the DNS.  As applications have increasingly relied upon the
   DNS, proposals have emerged for incorporating these capabilities into the
   DNS." 

   Only in private DNS
   environments (including split horizon DNS) where the identity of the
   querier is assured through some external means does the DNS maintain
   confidential records in this sense by providing answers to the
   private and public users of the DNS.

   Another type of differentiation in answers is done for load balancing
   reasons, localization or related optimizations, whereby the public
   DNS returns different addresses in response to queries from different



Peterson, et al.       Expires September 13, 2012               [Page 4]

Internet-Draft             Applications in DNS                March 2012


   sources, or even no response at all, which is discussed further in
   Section 3.1.1.

   Applications in many environments require these sorts of features
   like confidentiality, differentiation from databases, and as the
   contexts in which applications rely on the DNS have increased, some
   application protocols have looked to extend the DNS to include these
   sorts of capabilities.

[BA] It is probably best for the arguments in this paragraph to be moved upfront. 

   This document therefore provides guidance to designers of
   applications and application protocols on the use or extension of the
   DNS to provide features to applications.  It offers an overview of
   ways that applications have used the DNS in the past, as well as
   proposed ways that applications could use the DNS.  It identifies
   concerns and trade-offs and gives some reasons to decide the
   question, "Should I store this information in the DNS, or use some
   other means?" when that question arises during protocol development.
   These guidelines remind application protocol designers of the
   strengths and weaknesses of the DNS in order to make it easier for
   designers to decide what features the DNS should provide for their
   application.

   The guidance in this document complements the guidance on extending
   the DNS given in [RFC5507].  Whereas [RFC5507] considers the
   preferred ways to add new information to the underlying syntax of the
   DNS (such as defining new resource records or adding prefixes or
   suffixes to labels), the current document considers broader
   implications of application that rely on the DNS for the
   implementations 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
   require further changes and extensions that are fundamentally at odds
   with the strengths of the DNS.













Peterson, et al.       Expires September 13, 2012               [Page 5]

Internet-Draft             Applications in DNS                March 2012


2.  Overview of DNS Application Usages

   [RFC0882] identifies the original and fundamental connection between
   the DNS and applications.  It begins by describing how the
   interdomain scope of applications creates "formidable problems when
   we wish to create consistent methods for referencing particular
   resources that are similar but scattered throughout the environment."
   This motivated "the need to have a mapping between host names... and
   ARPA Internet addresses" transition from a global table (the original
   "hosts.txt" file) to a "distributed database that performs the same
   function."  [RFC0882] also envisioned some ways to find the resources
   associated with mailboxes in a domain: without these extensions, a
   user trying to send mail to a foreign domain lacked a discovery
   mechanism to locate the right host in the remote domain to which to
   connect.

   While a special-purpose discovery mechanism could be built by each
   such application protocol that needed this functionality, the
   universality of the DNS invites installing these features into its
   public tree.  Over time, several other applications leveraged
   resource records for locating services in a domain or for storing
   application data associated with a domain in the DNS.  This section
   gives examples of various types of DNS usage by applications to date.

2.1.  Locating Services in a Domain

   The MX resource record provides the simplest motivating example for
   an application advertising its resources in the Domain Name System.
   The MX resource record contains the domain name of a server that
   receives mail on behalf of the administrative domain in question;
   that domain name must itself be resolved to one or more IP addresses
   through the DNS in order to reach the mail server.  While naming
   conventions for applications might serve a similar purpose (a host
   might be named "mail.example.com" for example), approaching service
   location through the creation of a new resource record yields
   important benefits.  For example, one can put multiple MX records
   under the same name, in order to designate backup resources or to
   load balance across several such servers (see [RFC1794]); these
   properties could not easily be captured by naming conventions (see
   [RFC4367]).

   While the MX record represents a substantial improvement over naming
   conventions as a means of service location, it remains specific to a
   single application.  Thus, the general approach of the MX record was
   adapted to fit a broader class of application through the Service
   (SRV) resource record (originally [RFC2052]).  The SRV record allows
   DNS resolvers to query for particular services and underlying
   transports (for example, HTTP running over TLS, see [RFC2818]) and to



Peterson, et al.       Expires September 13, 2012               [Page 6]

Internet-Draft             Applications in DNS                March 2012


   learn a host name and port where that service resides in a given
   domain.  It also provides a weighting mechanism to allow load
   balancing across several instances of a service.

   The reliance of applications on the existence of MX and SRV records
   has important implications for the way that applications manage
   identifiers, and that way that applications pass DNS names to

[BA] "and that way" -> "and the way"

   resolvers.  Email identifiers of the form "user@domain" rely on MX
   records to provide the convenience of simply specifying a "domain"
   component rather requiring to guess which particular host handles
   mail on behalf of the domain.  While for applications like web
   browsing, naming conventions continue to abound ("www.example.com"),
   SRV records allow applications to query for an application-specific
   protocol and transport.  For HTTP, the SRV service name corresponds
   to the URL scheme of the identifier invoked by the application (e.g.,
   when "http://example.com" is the identifier, the SRV query is for
   "_http._tcp.example.com"); for other applications, the SRV service
   that the application passes to the resolver may be implicit in the
   identifier.  The identifier used at the application layer thus
   designates the desired protocol and domain, but the application uses
   the DNS to find the location of the host of that service for the
   domain, the port where the service resided on that host, load
   balancing and fault tolerance, and related application features.
   Ultimately, applications that acquire MX or SRV records may use them
   as intermediate transformations in order to arrive at an eventual
   domain name that will resolve to the IP addresses to contact for the
   service.

   Locating specific services for a domain is thus the first major
   function for which applications started using the DNS in addition to
   simple name resolution.  SRV broadened and generalized the precedent
   of MX to make service location available to any application, rather
   than just to mail.  As the domain name of the located service might
   require a second DNS query to resolve, [RFC1034] shows that the
   Additional Data section of DNS responses may contain the
   corresponding address records for the names of services designated by
   the MX record; this optimization, which requires support in the
   authoritative server and the resolver, is an initial example of how
   support for application features requires changes to DNS operation.
   At the same time this is an example of an extension of the DNS that
   cannot be relied on: Many DNS resolver implementations will remove
   the addresses in the additional section of the DNS answers because of
   the trustworthiness issues described in [RFC2181].

[BA] Does it make sense to include a discussion of DNS-SD and its additional
level of indirection?

2.2.  NAPTR and DDDS

   The NAPTR resource record evolved to fulfill a need in the transition
   from Uniform Resource Locators (URLs) to the more mature URI



Peterson, et al.       Expires September 13, 2012               [Page 7]

Internet-Draft             Applications in DNS                March 2012


   [RFC3986] framework, which incorporated Uniform Resources Names
   (URNs).  Unlike URLs, URNs typically do not convey enough semantics
   internally to resolve them through the DNS, and consequently a
   separate URI-transformation mechanism is required to convert these
   types of URIs into domain names.  This allows identifiers with no
   recognizable domain component to be treated as DNS 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
   described, and then two fields that can contain translations: a
   "replacement" or "regular expression" field, only one of which
   appears in given NAPTR record.  A "replacement," like NAPTR's
   ancestor the PTR record, simply designates another domain name where
   one would look for records associated with this service in the
   domain.  The "regexp," on the other hand, allows regular expression
   transformations on the original URI intended to transform it into an
   identifier that the DNS 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 DNS name, and thus
   historically the DNS has often been used to resolve identifiers that
   were never devised as a name for an Internet host.  A prominent early
   example is found in the in-addr domain [RFC0882], in which IPv4
   address are transposed into a domain name in order to query the DNS
   for name(s) associated with the address.  Similar mechanisms could
   obviously be applied to other sorts of identifiers that lacked a
   domain component.  Eventually, this idea connected with activities to
   create a system for resolving telephone numbers on the Internet,
   which became known as ENUM (originally [RFC2916]).  ENUM borrowed
   from an earlier proposal, the "tpc.int" domain [RFC1530], which
   provided a means for encoding telephone numbers as domain names by
   applying a string preparation algorithm that required reversing the
   digits and treating each individual digit as a label in a DNS name -
   thus, for example, the number +15714345400 became
   0.0.4.5.4.3.4.1.7.5.1.tpc.int.

   In the ENUM system, in place of "tpc.int" the special domain
   "e164.arpa" was reserved for use.  In its more mature form in the
   Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim)
   framework, this initial transformation of the telephone number to a
   domain name was called the "First Well Known Rule."  Its flexibility
   has inspired a number of proposals beyond ENUM to encode and resolve
   unorthodox identifiers in the DNS.  Provided that the identifiers



Peterson, et al.       Expires September 13, 2012               [Page 8]

Internet-Draft             Applications in DNS                March 2012


   transformed by the First Well Known Rule have some meaningful
   structure and are not overly lengthy, virtually anything can serve as
   an input for the DDDS structure: for example, civic addresses.
   Though [RFC3402] stipulates of the identifier that "the lexical
   structure of this string must imply a unique delegation path," there
   is no requirement that the identifier be hierarchical, nor that the
   points of delegation in the domain name created by the First Well
   Known Rule correspond to any points of administrative delegation
   implied by the structure of the identifier.

   While this ability to look up names "which are not in the domain name
   syntax" does not change the underlying DNS protocols - the names
   generated by the DDDS algorithm are still just domain names - it does
   change the context in which applications pass name to resolvers, and
   can potentially require very different operational practices of zone
   administrators(see Section 3.3).  In terms of the results of a DNS
   query, the presence of the "regexp" field of NAPTR records enabled
   unprecedented flexibility in the types of identifiers that
   applications could resolve with the DNS.  Since the output of the
   regular expression frequently took the form of a URI (in ENUM
   resolution, for example, a telephone number might be converted into a
   SIP URI [RFC3261]), anything that could be encoded as a URI might be
   the result of resolving a NAPTR record - which, as the next section
   explores, essentially means arbitrary data.

2.3.  Arbitrary Data in the DNS

   Since URI encoding has ways of carrying basically arbitrary data,
   resolving a NAPTR record might result in an output other than an
   identifier which would subsequently be resolved to IP addresses and
   contacted for a particular application - it could give a literal
   result consumed by the application.  Originally, in [RFC2168], the
   intended applicability of the regular expression field in NAPTR was
   much more narrow: the regexp field contained a "substitution
   expression that is applied to the original URI in order to construct
   the next domain name to lookup," in order "change the host that is
   contacted to resolve a URI" or as a way of "changing the path or host
   once the URL has been assigned."  The regular express tools available
   to NAPTR record authors, however, grant much broader powers to alter
   the input string, and thus applications began to rely on NAPTR to
   perform more radical transformations.  By [RFC3402], the output of
   DDDS is wholly application-specific: "the Application must determine
   what the expected output of the Terminal Rule should be," and the
   example given in the document is one of identifying automobile parts
   by inputting a part number is receiving at the end of the process
   receiving information about the manufacturer (though this example
   reflects that the DNS is only one database to which the DDDS
   framework might apply).



Peterson, et al.       Expires September 13, 2012               [Page 9]

Internet-Draft             Applications in DNS                March 2012


   NAPTR did not however pioneer the storage of arbitrary data in the
   DNS.  At the start, [RFC0882] observed that "it is unlikely that all
   users of domain names will be able to agree on the set of resources
   or resource information that names will be used to retrieve," and
   consequently places little restriction on the information that DNS
   records might carry: it might be "host addresses, mailbox data, and
   other as yet undetermined information."  [RFC1035] defined the TXT
   record, a means to store arbitrary strings in the DNS; [RFC1034]
   specifically stipulates that a TXT contains "descriptive text" and
   that "the semantics of the text depends on the domain where it is
   found."  The existence of TXT records has long provided new
   applications with a rapid way of storing data associated with a
   domain name in the DNS, as adding data in this fashion require no
   registration process.  [RFC1464] experimented with a means of
   incorporating name/value pairs to the TXT record structure, which
   allowed applications to differentiate different chunks of data stored
   in a TXT record.  In this fashion, an application that wants to store
   additional data in the DNS can do so without registering a new
   resource record type - though [RFC5507] points out that it is
   "difficult to reliably distinguish one application's record from
   otters, and for its parser to avoid problems when it encounters other
   TXT records."

   While open policies surrounding the use of the TXT record have
   resulted in a checkered past for standardizing application usage of
   TXT, TXT has been used as a technical solution for DKIM [RFC4871] to
   store necessary information about the security of email in DNS,
   though within a narrow naming convention (records stored under
   "_domainkey" subdomains).  Storing keys in the DNS became the
   preferred solution for DKIM for several reasons: notably, because the
   public keys associated with email required wide public distribution,
   and because email identifiers contain a domain component that
   applications can easily use to consult the DNS.  If the application
   had to negotiate support for the DKIM mechanism with mail servers, it
   would give rise to bid-down attacks (where attackers misrepresent
   that DKIM is unsupported in the domain) that are not possible if the
   DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees
   authenticity of the data).  However, there are potential issues with
   story large data in the DNS, as discussed in Section 3.2.1 as well as
   with the DKIM namespace conventions that prevent the use of DNS
   wildcards (as discussed in section 3.6.2.1. of [RFC4871] and in more
   general terms in [RFC5507]).









Peterson, et al.       Expires September 13, 2012              [Page 10]

Internet-Draft             Applications in DNS                March 2012


3.  Challenges for the DNS

   The methods discussed in the previous section for transforming
   arbitrary identifiers into domain names, and for returning arbitrary
   data in response to DNS queries, both represent significant
   departures from the basic function of translating host names to IP
   addresses, yet neither fundamentally alters the underlying semantics
   of the DNS.  When we consider, however, that the URIs returned by
   DDDS might be base 64 encoded binary data in the data URL [RFC2397],
   the DNS could effectively implement the entire application feature
   set of any simple query-response protocol.  Effectively, the DDDS
   framework considers the DNS a generic database - indeed, the DDDS
   framework was designed to work with any sort of underlying database;
   as [RFC3403] shows, the DNS is only one potential database for DDDS
   to use.  Whether the DNS as an underlying database can support the
   features that some applications of DDDS require, however, is a more
   complicated question.

   As the following subsections will show, the potential that
   applications might rely on the DNS as a generic database gives rise
   to additional requirements that one might expect to find in a
   database access protocol: authentication of the source of queries for
   comparison to access control lists, formulating complex relational
   queries, and asking questions about the structure of the database
   itself.  DNS was not designed to provide these sorts of properties,
   and extending the DNS to encompass them would represent a fundamental
   alteration to its model.  Ultimately, this document concludes that
   efforts to retrofit these capabilities into the DNS would be better
   invested in selecting, or if necessary inventing, other Internet
   services with broader powers than the DNS.  If an application
   protocol designer wants these properties from a database, in general
   this is a good indication that the DNS cannot, or 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 information is uniquely identified by the 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.       Expires September 13, 2012              [Page 11]

Internet-Draft             Applications in DNS                March 2012


   compound or relational search, which takes into account more than one
   factor in formulating a response or uses no single factor as a key to
   the database.  For example, in the telephony space, telephone call
   routing often takes into account numerous factors aside from the
   dialed number, including originating trunk groups, interexchange
   carrier selection, number portability data, time of day, and so on.
   All are considered simultaneously in generating a route.  While in
   its original conception, ENUM hoped to circumvent the traditional
   PSTN and route directly to Internet-enabled devices, the
   infrastructure ENUM effort to support the migration of traditional
   carrier routing functions to the Internet aspires to achieve feature
   parity with traditional number routing.  However, [RFC3402]
   explicitly states that "it is an assumption of the DDDS that the
   lexical element used to make a delegation decision is simple enough
   to be contained within the Application Unique String itself.  The
   DDDS does not solve the case where a delegation decision is made
   using knowledge contained outside the AUS and the Rule (time of day,
   financial transactions, rights management, etc.)."  Consequently,
   some consideration has been given to ways to add additional data to
   ENUM queries to give the DNS server sufficient information to return
   a suitable URI (see Section 3.1.1).

   From a sheer syntactical perspective, however, domain names do not
   admit of this sort of rich structure.  Several workarounds have
   attempted to instantiate these sorts of features in DNS queries.  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.

   More commonly, proposals piggyback additional query parameters as
   EDNS0 extensions (see [RFC2671]).  This might be problematic for
   three reasons.  First, supporting EDNS0 extensions requires
   significant changes to name server behavior that needs to be
   supported by the authoritative and recursive nameservers on which the
   application relies and might be very hard to realize on a global
   scale.  In addition, the intended applicability of the EDNS0
   mechanism, as the [RFC2761] states, is to "a particular transport
   level message and not to any actual DNS data," and consequently the
   OPT Resource Records it specifies are never to be forwarded; the use
   of EDNS0 for compound queries, however, clearly is intended to



Peterson, et al.       Expires September 13, 2012              [Page 12]

Internet-Draft             Applications in DNS                March 2012


   discriminate actual DNS data rather than to facilitate transport-
   layer handling.  Finally, [RFC2761] also specifies that OPT pseudo-
   Resource Records are never cached (see the next paragraph).  For
   these reasons, this memo recommends against the use of EDNS0 as a
   mechanism for crafting compound DNS queries.

   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.

3.1.1.  Responses Tailored to the Originator

   The most important subcase of the compound queries are DNS responses
   tailored to the identity of their originator, where some sort of
   administrative identity of the originator must be conveyed to the
   DNS.  We must first distinguish this from cases where the originating
   IP address or a similar indication is used to serve a location-
   specific name.  For those sorts of applications, which generally lack
   security implications, relying on factors like the source IP address
   introduces little harm; for example, when providing a web portal
   customized to the region of the client, it would not be a security
   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
   [I-D.vandergaast-edns-client-ip]).  However, aside from purely
   cosmetic uses, these approaches have known limitations due to the
   prevalence of private IP addresses, VPNs and so on which obscure the
   source IP address and instead supply the IP address of an
   intermediary that may be very distant from the originating endpoint.
   Implementing technology such as the one described by
   [I-D.vandergaast-edns-client-ip] does require significant changes in
   the operation of recursive resolvers and the authoritative servers
   that would rely on the original source IP address to select Resource
   Records, and moreover a fundamental change to caching behavior as
   well.  As a result such technology can only be deployed after
   bilateral (authoritative-resolver) agreement and is not likely to
   deploy to ubiquitous Internet scale use.

   In other deployments in use today, including those based on the BIND
   "views" feature, the source IP address is used to grant access to a
   private set of resource records.  The security implications of
   trusting the source IP address of a DNS query have prevented most



Peterson, et al.       Expires September 13, 2012              [Page 13]

Internet-Draft             Applications in DNS                March 2012


   solutions along these lines from being standardized (see [RFC6269]),
   though the practice remains widespread in "split horizon" private DNS
   deployment (see Section 4) which typically rely on an underlying
   security layer, such as a physical network or an IPsec VPN, to
   prevent spoofing of the source IP address.  These deployments do have
   a confidentiality requirement to prevent information intended for a
   constrained audience (internal to an enterprise, for example) from
   leaking to the public Internet -- while these internal network
   resources may use private IP addresses which would not be useful on
   the public Internet anyway, in some cases this leakage would reveal
   topology or other information that the name server provisioner hopes
   to keep private.

   These first two cases, regardless of their acceptance by the
   standards community, have widespread acceptance in the field.  Some
   applications, however, go even further and propose extending the DNS
   to add an application-layer identifier of the originator rather than
   an IP address; for example,
   [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] provides a SIP URI
   in an eDNS0 parameter.  Effectively, the conveyance of application-
   layer information about the administrative identity of the originator
   through the DNS is a weak authentication mechanism, on the basis of
   which the DNS server makes an authorization decision before sharing
   resource records.  This can parlay into a per-Resource Record
   confidentiality mechanism, where only a specific set of originators
   are permitted to see resource records, or a case where a query for
   the same name by different entities results in completely different
   resource record sets.  The DNS, however, substantially lacks the
   protocol semantics to manage access control lists for data, and
   again, caching, 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 like require significant rearchitecture of the DNS.

3.2.  Using DNS as a Generic Database

   As previously noted, applications can use the DNS by transferring an
   arbitrary string into a query (using a method like the First Well
   Known Rule of DDDS) and receiving arbitrary data stored in custom
   resource records (or potentially TXT RRs).  Some query-response
   applications, however, require queries and responses that simply fall
   outside the syntactic capabilities of the DNS.  Domain names
   themselves must conform to certain syntactic constraints: they must
   consist of labels that do not exceed 63 characters while the total
   length of the encoded name may not exceed 255 octets, they must obey
   fairly strict encoding rules, and so on.  The DNS therefore cannot be
   a completely generic database.  Similar concerns apply to the size of



Peterson, et al.       Expires September 13, 2012              [Page 14]

Internet-Draft             Applications in DNS                March 2012


   DNS responses.

3.2.1.  Large Data in the DNS

   While the data URL specification [RFC2397] notes that it is "only
   useful for short values," unfortunately it gives no particular
   guidance about what "short" might mean.  Many applications today use
   quite large data URLs (containing a megabyte or more of data) as
   workarounds in environments where only URIs can syntactically appear.
   The meaning of "short" in an application context is probably very
   different from how we should understand it in a DNS message.
   Referring to a typical public DNS deployment, [RFC5507] observes that
   "there's a strong incentive to keep DNS messages short enough to fit
   in a UDP datagram, preferably a UDP datagram short enough not to
   require IP fragmentation".  And while EDNS0 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 EDNS0 is not available, or the negotiated
   EDNS0 packet size is too small to fit the data, or UDP fragments are
   dropped, the DNS will (eventually) resort to use 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 DNS queries with a forged source address, and the victim
   receives the response.  By generating a large response to a small
   query, the attacker can magnify the bandwidth directed at the victim.
   Where the responder supports EDNS0, an attacker may set the requester
   maximum payload size to a larger value while querying for a large
   Resource Record, such as a certificate [RFC4398].  Thus the
   combination of large data stored in DNS RRs and responders supporting
   large payload sizes has the potential to increase the potential
   damage achievable in a reflection attack.

   Since a reflection attack can be launched from any network that does
   not implement source address validation, these attacks are difficult
   to eliminate absent the ubiquitous deployment of source address
   validation.

   The bandwidth that can be mustered in a reflection attack directed by
   a botnet reflecting of a recursive nameserver on a high bandwidth



Peterson, et al.       Expires September 13, 2012              [Page 15]

Internet-Draft             Applications in DNS                March 2012


   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 2000
   Gbps of traffic on the victim, more than sufficient to congest any
   site on the Internet.

   Since it is prohibitively difficult to complete a TCP three-way
   handshake begun from a forged source address, DNS reflection attacks
   utilize UDP queries.  Unless the attacker uses EDNS0 [RFC2671] to
   enlarge the requester's maximum payload size, a response can only
   reach 576 octets before the truncate bit is set in the response.
   This limits the maximum magnification achievable from a DNS query
   that does not utilize EDNS0.  As the large disparity between the size
   of a query and size of the response creates this amplification,
   implementations should limit EDNS0 responses to a specific ratio
   compared to the request size.  The precise ratio can be configured on
   a per-deployment basis (taking into account DNSSEC response sizes),
   but without this limitation, EDNS0 can cause significant harm.

[BA] Dan Kaminsky has written a good article on DNSSEC and amplification
attacks:
http://technet.microsoft.com/en-us/security/hh972393.aspx

As noted in the article, limiting EDNS0 replies to a maximum of 4K can
limit the amplication factor while not impacting the scalability of
DNSSEC.  Extending the maximum UDP packet size beyond this is probably
inadvisable. 

   In summary, there are two operational forces that tend to drive the
   practically available EDNS0 sizes down: possible UDP fragmentation
   and minimizing magnification 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
   EDNS0 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 of
   several hundreds 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 DNS name through the application of the First Well Known
   Rule, the delegative structure of the resulting DNS name may not
   reflect the division of responsibilities for the resources that the
   alphanumeric data indicates.  While [RFC3402] requires only that
   "Application Unique String has some kind of regular, lexical
   structure that the rules can be applied to," DDDS is first and
   foremost a delegation system: its abstract stipulates that "Well-
   formed transformation rules will reflect the delegation of management
   of information associated with the string."  Telephone numbers in the
   United States, for example, are assigned and delegated in a
   relatively complex manner.  Historically, the first six digits of a
   nationally specific number (called the "NPA/NXX") reflected a point
   of administrative delegation from the number assignment agency to a
   carrier; from these blocks of ten thousand numbers, the carrier would
   in turn delegate individual assignments of the last four digits (the



Peterson, et al.       Expires September 13, 2012              [Page 16]

Internet-Draft             Applications in DNS                March 2012


   "XXXX" portion) to particular customers.  However, after the rise of
   North American telephone number portability in the 1990s, the first
   point of delegation went away: the delegation is effectively from the
   number authority to the carrier for each the complete ten-digit
   number (NPA/NXX-XXXX).  While technical implementation details differ
   from nation to nation, number portability systems with similar
   administrative delegations now exist worldwide.

   To render these identifiers as domain names in accordance with the
   DDDS Rule for ENUM yields a large flat administrative domain with no
   points of administrative delegation from the country-code
   administrator, e.g. 1.e164.arpa, down to the ultimately 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 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 as the zone transfer
   protocol 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 clue
   that the DNS might not be the right place for an application to store
   its data.

   DDDS provides a capability that transforms arbitrary strings into
   domain names, but those names play well with the DNS only when the
   input string have an administrative structure that maps on DNS
   delegations.  In the first place, delegation implies some sort of
   hierarchical structure.  Any mechanism to map a hierarchical
   identifier into a DNS name should be constructed such that the
   resulting DNS name does match the natural hierarchy of the original
   identifier.  Although telephone numbers, even in North America, have
   some hierarchical qualities (like the geographical areas



Peterson, et al.       Expires September 13, 2012              [Page 17]

Internet-Draft             Applications in DNS                March 2012


   corresponding to their first three digits), after the implementation
   of number portability these points no longer mapped onto an
   administrative delegation.  If the input string to the DDDS does not
   have a hierarchical structure representing administrative delegations
   that can map onto the DNS distribution system, that string probably
   is not a good candidate for translating into a domain name.

   The difficulty of mapping the DNS to administrative structures can
   even occur with traditional domain names, where applications expect
   clients to infer or locate zone cuts.  In the web context, for
   example, it can be difficult for applications to determine whether
   two domains represent the same "site" when comparing security
   credentials with URLs (see Section 3.4 below for more on this).

3.3.1.  Metadata about Tree Structure

   There are also other ways in which the delegative structure of an
   identifier may not map well onto the DNS.  Traditionally, DNS
   resolvers assume that when they receive a domain name from an
   application, that the name is complete - that it is not a fragment of
   a DNS name that a user is still in the middle of typing.  For some
   communications systems, however, this assumption does not apply.
   ENUM use cases have surfaced a couple of optimization requirements to
   reduce unnecessary calls and queries by including metadata in the DNS
   that describes the contents and structure of ENUM DNS trees to help
   applications to handle incomplete queries or queries for domains not
   in use.  In particular, the "send-n" proposal
   [I-D.bellis-enum-send-n] hopes to reduce the number of DNS queries
   sent in regions with variable-length numbering plans.  When a dialed
   number potentially has a variable length, a telephone switch
   ordinarily cannot anticipate when a dialed number is complete, as
   only the numbering plan administrator (who may be a national
   regulator, or even in open number plans a private branch exchange)
   knows how long a telephone number needs to be.  Consequently, a
   switch trying to resolve such a number through a system like ENUM
   might send a query for a telephone number that has only partially
   been dialed in order to test its completeness.  The "send-n" proposal
   installs in the DNS a hint informing the telephone switch of the
   minimum number of digits that must be collected by placing in zones
   corresponding to incomplete telephone numbers some Resource Records
   which state how many more digits are required - effectively how many
   steps down the DNS tree one must take before querying the DNS again.
   Unsurprisingly, those boundaries reflect points of administrative
   delegation, where the parent in a number plan yields authority to a
   child.  With this information, the application is not required to
   query the DNS every time a new digit is dialed, but can wait to
   collect sufficient digits to receive a response.  As an optimization,
   this practice thus saves the resources of the DNS server - though the



Peterson, et al.       Expires September 13, 2012              [Page 18]

Internet-Draft             Applications in DNS                March 2012


   call cannot complete until all digits are collected, so at best this
   mechanism only reduces the time the system will wait before sending
   an ENUM query after collecting the final dialed digit.  A
   tangentially related proposal, [I-D.ietf-enum-unused], similarly
   places resource records in the DNS that tell the application that it
   need not attempt to reach a number on the telephone network, as the
   number is unassigned - a comparable general DNS mechanism would
   identify, for a domain name with no records available in the DNS,
   whether or not the domain had been allocated to an owner.

   Both proposals optimize application behavior by placing metadata in
   the DNS that predicts the success of future queries or application
   invocation by identifying points of administrative delegation or
   assignment in the tree.  In some respects, marking a point in the
   tree where a zone begins or end has some features in common with the
   traditional parent zone use of the NS record type, except instead of
   pointing to a child zone, these metadata proposals point to distant
   grandchildren.  While this does not change resolver behavior as such
   (instead, it changes the way that applications invoke the resolver),
   it does have implications for the practices for zone administrators.
   Metadata in one administrative domain needs to remain synchronized
   with the state of the resources it predicts in another administrative
   domain in the DNS namespace, or resources associated with other
   namespaces.  Besides, maintaining that synchronization requires that
   the DNS have semi-real time updates that may conflict with scale and
   caching mechanisms of the DNS.

   It may also raise questions about the authority and delegation model.
   Who gets to supply records for unassigned names?  While in the
   original but little-used "golden" root model of ENUM, this would
   almost certainly be a numbering plan administrator, it is far less
   clear who that would be in the more common and successful
   "infrastructure" ENUM models (see Section 4).  Ultimately, these
   metadata proposals share some qualities with DNS redirection services
   offered by ISPs (for example, [I-D.livingood-dns-redirect]) which
   "help" web users who try to browser to sites that do not exist -
   though in those cases, at least the existence or non-existence of a
   domain name is a fact about the Internet namespace, rather than about
   an external namespace like the telephone's e.164 namespace which must
   be synchronized with the DNS tree in the metadata proposals.  In
   send-n, different leaf zones, who administer telephone numbers of
   different lengths, can only provision their hints at their own apex,
   which provides an imperfect optimization: they cannot install it in a
   parent, both because they lack the authority and because different
   zones would want to provision contradictory data.  An application
   protocol designer who wants to manage identifiers whose
   administrative model does not map well onto the DNS namespace and
   delegations structure would be better served to implement such



Peterson, et al.       Expires September 13, 2012              [Page 19]

Internet-Draft             Applications in DNS                March 2012


   features outside the DNS.

3.4.  Domain Redirection

   Most Internet application services provide a redirection feature -
   when you attempt to contact a service, the service may refer you to a
   different service instance, potentially in another domain, that is
   for whatever reason better suited to address a request.  In HTTP and
   SIP, for example, this feature is implemented by the 300 class
   responses containing one or more better URIs that may indicate that a
   resource has moved temporarily or permanently to another service.
   Several tools in the DNS, including the SRV record, can provide a
   similar feature at a DNS level, and consequently some applications as
   an optimization offload the responsibility for redirection to the
   DNS; NAPTR can also provide this capability on a per-application
   basis, and numerous DNS resource records can provide redirection on a
   per-domain basis.  This can prevent the unnecessary expenditure of
   application resources on a function that could be performed as a
   component of a DNS lookup that is already a prerequisite for
   contacting the service.  Consequently, in some deployment
   architectures this DNS-layer redirection is used for virtual hosting
   services.

   Implementing domain redirection in the DNS, however, has important
   consequences for application security.  In the absence of universal
   DNSSEC, applications must blindly trust that their request has not
   been hijacked at the DNS layer and redirected to a potentially
   malicious domain, unless some subsequent application mechanism can
   provide the necessary assurance.  By way of contrast, application-
   layer redirections protocols like HTTP and SIP have available

[BA] Might say "application-layer protocol supporting redirection such
as HTTP and SIP" 

   security mechanisms such as TLS that can use certificates to vouch
   that a 300 response came from the domain that the originator
   initially hoped to contact.

   A number of applications have attempted to provide an after-the-fact
   security mechanism that verifies the authority of a DNS delegation in
   the absence of DNSSEC.  The specification for dereferencing SIP URIs
   ([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
   establishment, the site eventually reached by a SIP request present a
   certificate corresponding to the original URI expected by the user
   (in other words, if example.com redirects to example.net in the DNS,
   this mechanism expects that example.net will supply a certificate for
   example.com in TLS, per the HTTP precedent in [RFC2818]), which
   requires a virtual hosting service to possess a certificate
   corresponding to the hosted domain.  This restriction rules out many
   styles of hosting deployments common in the web world today, however.
   [I-D.barnes-hard-problem] explores this problem space, and
   [I-D.saintandre-tls-server-id-check] proposes a solution for all

[BA] The saintandre draft has subsequently been published as RFC 6125.
Section 3 provides recommendations, including:

   o  Does your technology use DNS SRV records to resolve the DNS domain
      names of application services?  If so, consider recommending or
      requiring support for the SRV-ID identifier type in PKIX
      certificates issued and used in your technology community.  (Note
      that many existing application technologies use DNS SRV records to
      resolve the DNS domain names of application services, but do not
      rely on representations of those records in PKIX certificates by
      means of SRV-IDs as defined in [SRVNAME].)

   o  Does your technology use URIs to identify application services?
      If so, consider recommending or requiring support for the URI-ID
      identifier type.  (Note that many existing application
      technologies use URIs to identify application services, but do not
      rely on representation of those URIs in PKIX certificates by means
      of URI-IDs.)

Note that RFC 6125, the original URI is verified against the SRV-ID or
URI-ID identifier in the certificate supplied by the virtual hosting
service.


Peterson, et al.       Expires September 13, 2012              [Page 20]

Internet-Draft             Applications in DNS                March 2012


   applications that use TLS.  Potentially, new types of certificates
   (similar to [RFC4985]) might bridge this gap, but support for those
   certificates would require changes to existing certificate authority
   practices as well as application behavior.

   All of these application-layer measures attempt to mirror the
   delegation of 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.


































Peterson, et al.       Expires September 13, 2012              [Page 21]

Internet-Draft             Applications in DNS                March 2012


4.  Private DNS and Split Horizon

   The classic view of the uniqueness of DNS names is given in
   [RFC2826]:

   DNS names are designed to be globally unique, that is, for any
   one DNS name at any one time there must be a single set of DNS
   records uniquely describing protocol addresses, network resources and
   services associated with that DNS name.  All of the applications
   deployed on the Internet which use the DNS assume this, and Internet
   users expect such behavior from DNS names.

   However, [RFC2826] "does not preclude private networks from operating
   their own private name spaces," but notes that if private networks
   "wish to make use of names uniquely defined for the global Internet,
   they have to fetch that information from the global DNS naming
   hierarchy."  There are various DNS deployments outside of the global
   public DNS, including "split horizon" deployments and DNS usages on
   private (or virtual private) networks.  In a split horizon, an
   authoritative server gives different responses to queries from the
   public Internet than they do to internal resolvers; as they typically
   differentiate internal from public queries by the source IP address,
   the concerns in Section 3.1.1 apply to such deployments.  When the
   internal address space range is private [RFC1918], this both makes it
   easier for the server to discriminate public from private and harder
   for public entities to impersonate nodes in the internal network.
   Networks that are made private physically, or logically by
   cryptographic tunnels, make these private deployments more secure.
   The most complex deployments along these lines use multiple virtual
   private networks to serve different answers for the same name to many
   networks.

   The use cases that motivate split horizon DNS typically involve
   restricting access to some network services - intranet resources like
   internal web site, development servers or directories, for example -
   while preserving the ease of use offered by domain names for internal
   users.  While for many of these resources, the split horizon would
   not return answers to public resolvers for those internal resources
   (those records are kept confidential from the public), in some cases,
   the same name (e.g., "mail.example.com") might resolve to one host
   internally but another externally.  The requirements for multiple-VPN
   private deployments, however, are different: in this case the
   authoritative server gives different, and confidential, answers to a
   set of resolvers querying for the same name.  While these sorts of
   use cases rarely arise for traditional domain names, where, as
   [RFC2826] says, users and applications expect a unique resolution for
   a name, they can easily arise when other sorts of identifiers have
   been translated by a mechanism like DDDS into "domain name syntax."



Peterson, et al.       Expires September 13, 2012              [Page 22]

Internet-Draft             Applications in DNS                March 2012


   Telephone calls, for example, are traditionally routed through highly
   mediated networks, and an attempt to find a route for a call often
   requires finding an appropriate intermediary based on the source
   network and location rather than finding an endpoint (see the
   distinction between the Look-Up Function and Location Routing
   Function in [RFC5486]).  Moreover, the need for selective responses
   and confidentially is easily motivated when the data returned by the
   DNS is no longer "describing protocol addresses, network resources
   and services," but instead arbitrary data.  Although ENUM was
   originally intended for deployment in the global public root of the
   DNS (under e164.arpa), for example, the requirements of maintaining
   telephone identifiers in the DNS quickly steered operators into
   private deployments.

   In private environments, it is also easier to deploy any necessary
   extensions than it is in the public DNS: in the first place,
   proprietary non-standard extensions and parameters can easily be
   integrated into DNS queries or responses as the implementations of
   resolvers and servers can likely be controlled; secondly,
   confidentiality and custom responses can be provided by deploying,
   respectively, underlying physical or virtual private networks to
   shield the private tree from public queries, and effectively
   different virtual DNS trees for each administrative entity that might
   launch a query; thirdly, in these constrained environments, caching
   and recursive resolvers can be managed or eliminated in order to
   prevent any unexpected intermediary behavior.  While these private
   deployments serve an important role in the marketplace, there are
   risks in using techniques intended only for deployment in private and
   constrained environments as the basis of a standard solution.  When
   proprietary parameters or extensions are deployed in 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 extension
   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.  However, the use of a dedicated suffix
   (Section 3.3 [RFC5507]) in a private environment might cause
   confusion if leaked to the public internet, for example.

   That this kind of leakage leakage of protocol elements from private
   deployments to public deployments does happen has been demonstrated,
   for example, with SIP: SIP implemented a category supposedly private
   extensions (notably the "P-" headers) which 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



Peterson, et al.       Expires September 13, 2012              [Page 23]

Internet-Draft             Applications in DNS                March 2012


   protocols would not similarly end up in use in public environments.


















































Peterson, et al.       Expires September 13, 2012              [Page 24]

Internet-Draft             Applications in DNS                March 2012


5.  Principles and Guidance

   The success of the DNS relies on the fact that it is a distributed
   database, one that has the property that it is loosely coherent and
   that it offers lookup instead of search functionality.  Loose
   coherency means that answers to queries are coherent within the
   bounds of data replication between authoritative servers (as
   controlled by the administrator of the zone) and caching behavior by
   recursive name servers.  It is critical that application designers
   who intend to use the DNS to support their applications consider the
   implications that their uses have for the behavior of resolvers,
   intermediaries including caches and recursive resolvers, and
   authoritative servers.

   It is likely that the DNS provides a good match whenever applications
   needs are aligned with the following properties:

      Data stored in the DNS can be propagated and cached using
      conventional DNS mechanisms, without intermediaries needing to
      understand exceptional logic (considerations beyond the name, type
      and class of the query) used by the authoritative server to
      formulate responses

      Data stored in the DNS is indexed by keys that do not violate the
      syntax or semantics of domain names

      Applications invoke the DNS to resolve complete names, not
      fragments

      Answers do not depend on an application-layer identity of the
      entity doing the query

      Ultimately, applications invoke the DNS to assist in communicating
      with the domain of the name they are resolving

   Whenever one of the four properties above does not apply to one's
   data, one should seriously consider whether the DNS is the best place
   to store actual data.  On the other hand, good indicators that the
   DNS is not the appropriate tool for solving problems is when you have
   to worry about:

      Populating metadata about domain boundaries within the tree - the
      points of administrative delegation in the DNS are something that
      applications should in general not be aware off

      Domain names derived from identifiers that do not share a
      semantics or administrative model compatible with the DNS




Peterson, et al.       Expires September 13, 2012              [Page 25]

Internet-Draft             Applications in DNS                March 2012


      Selective confidentiality of data stored in and provided by the
      DNS

      DNS responses not fitting into UDP packets, unless EDNS0 is
      available, and only then with the caveats discussed above

   In cases where applications require these sorts of features, they are
   simply better instantiated by independent application-layer protocols
   than the DNS.  The query-response semantics of the DNS are similar to
   HTTP, for example, and the objects which HTTP can carry both in
   queries and responses can easily contain the necessary structure to
   manage compound queries.  Many applications already use HTTP because
   of widespread support for it in middleboxes.  Similarly, HTTP has
   numerous ways to provide the necessary authentication, authorization
   and confidentiality properties that some features require, as well as
   the redirection properties discussed in Section 3.4.  The overhead of
   using HTTP may not be appropriate for all environments, but even in
   environments where a more lightweight protocol is appropriate, DNS is
   not the only alternative.

   Where the administrative delegations of the DNS form a necessary
   component in the instantiation of an application feature, there are
   various ways that the DNS can bootstrap access to an independent
   application-layer protocol better suited to field the queries in
   question.  For example, since NAPTR or URI resource
   [I-D.faltstrom-uri] records can contain URIs, those URIs can in turn
   point to an external query-response service such as HTTP where more
   syntactically and semantically rich queries and answers might be
   exchanged.






















Peterson, et al.       Expires September 13, 2012              [Page 26]

Internet-Draft             Applications in DNS                March 2012


6.  Security Considerations

   Many of the concerns about how applications use the DNS discussed in
   this document involve security.  The perceived need to authenticate
   the source of DNS queries (see Section 3.1.1) and authorize access to
   particular resource records also illustrates the fundamental security
   principles that arise from offloading certain application features to
   the DNS.  As Section 3.2.1 observes, large data in the DNS can
   provide a means of generating reflection attacks, and without the
   remedies discussed in that section (especially the use of EDNS0 and
   TCP) the presence of large records is not recommended.  Section 3.4
   discusses a security problem concerning redirection that has surfaced
   in a number of protocols (see [I-D.barnes-hard-problem]).

[BA] Might be better to refer to RFC 6125. 

   While DNSSEC, were it deployed universally, can play an important
   part in securing application redirection in the DNS, DNSSEC does not
   provide a means for a resolver to authenticate itself to a server,
   nor a framework for servers to return selective answers based on the
   authenticated identity of resolvers.  The existing feature set of
   DNSSEC is however sufficient for providing security for most of the
   ways that applications traditionally have used the DNS.  The
   deployment of DNSSEC ([RFC4033] and related specifications) is
   therefore encouraged.  Nothing in this document is intended to
   discourage either the implementation, deployment, or use of Secure
   DNS Dynamic Updates ([RFC2136].


























Peterson, et al.       Expires September 13, 2012              [Page 27]

Internet-Draft             Applications in DNS                March 2012


7.  IANA Considerations

   This document contains no considerations for the IANA.
















































Peterson, et al.       Expires September 13, 2012              [Page 28]

Internet-Draft             Applications in DNS                March 2012


8.  IAB Members

   Internet Architecture Board Members at the time this document was
   published were:

   [TO BE INSERTED]













































Peterson, et al.       Expires September 13, 2012              [Page 29]

Internet-Draft             Applications in DNS                March 2012


9.  Acknowledgements

   The IAB appreciates the comments and often spirited disagreements of
   Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson,
   Patrik Faltstrom and Eliot Lear.














































Peterson, et al.       Expires September 13, 2012              [Page 30]

Internet-Draft             Applications in DNS                March 2012


10.  Informative References

   [I-D.barnes-hard-problem]
              Barnes, R. and P. Saint-Andre, "High Assurance Re-
              Direction (HARD) Problem Statement",
              draft-barnes-hard-problem-00 (work in progress),
              July 2010.

   [I-D.bellis-enum-send-n]
              Bellis, R., "IANA Registrations for the 'Send-N'
              Enumservice", draft-bellis-enum-send-n-02 (work in
              progress), June 2008.

   [I-D.faltstrom-uri]
              Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record",
              draft-faltstrom-uri-06 (work in progress), October 2010.

   [I-D.ietf-enum-unused]
              Stastny, R., Conroy, L., and J. Reid, "IANA Registration
              for Enumservice UNUSED", draft-ietf-enum-unused-04 (work
              in progress), March 2008.

   [I-D.kaplan-dnsext-enum-sip-source-ref-opt-code]
              Kaplan, H., Walter, R., Gorman, P., and M. Maharishi,
              "EDNS Option Code for SIP and PSTN Source Reference Info",
              draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work
              in progress), October 2011.

   [I-D.livingood-dns-redirect]
              Creighton, T., Griffiths, C., Livingood, J., and R. Weber,
              "DNS Redirect Use by Service Providers",
              draft-livingood-dns-redirect-03 (work in progress),
              October 2010.

   [I-D.saintandre-tls-server-id-check]
              Saint-Andre, P. and J. Hodges, "Representation and
              Verification of Domain-Based Application Service Identity
              in Certificates Used with Transport Layer Security",
              draft-saintandre-tls-server-id-check-09 (work in
              progress), August 2010.

   [I-D.vandergaast-edns-client-ip]
              Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
              "Client IP information in DNS requests",
              draft-vandergaast-edns-client-ip-01 (work in progress),
              May 2010.




Peterson, et al.       Expires September 13, 2012              [Page 31]

Internet-Draft             Applications in DNS                March 2012


   [RFC0882]  Mockapetris, P., "Domain names: Concepts and facilities",
              RFC 882, November 1983.

   [RFC0974]  Partridge, C., "Mail routing and the domain system",
              RFC 974, January 1986.

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, November 1987.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, November 1987.

   [RFC1464]  Rosenbaum, R., "Using the Domain Name System To Store
              Arbitrary String Attributes", RFC 1464, May 1993.

   [RFC1530]  Malamud, C. and M. Rose, "Principles of Operation for the
              TPC.INT Subdomain: General Principles and Policy",
              RFC 1530, October 1993.

   [RFC1794]  Brisco, T., "DNS Support for Load Balancing", RFC 1794,
              April 1995.

   [RFC1918]  Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
              E. Lear, "Address Allocation for Private Internets",
              BCP 5, RFC 1918, February 1996.

   [RFC1995]  Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
              August 1996.

   [RFC2052]  Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
              location of services (DNS SRV)", RFC 2052, October 1996.

   [RFC2136]  Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
              "Dynamic Updates in the Domain Name System (DNS UPDATE)",
              RFC 2136, April 1997.

   [RFC2168]  Daniel, R. and M. Mealling, "Resolution of Uniform
              Resource Identifiers using the Domain Name System",
              RFC 2168, June 1997.

   [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.



Peterson, et al.       Expires September 13, 2012              [Page 32]

Internet-Draft             Applications in DNS                March 2012


   [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.

   [RFC2915]  Mealling, M. and R. Daniel, "The Naming Authority Pointer
              (NAPTR) DNS Resource Record", RFC 2915, September 2000.

   [RFC2916]  Faltstrom, P., "E.164 number and DNS", RFC 2916,
              September 2000.

   [RFC3007]  Wellington, B., "Secure Domain Name System (DNS) Dynamic
              Update", RFC 3007, November 2000.

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              June 2002.

   [RFC3263]  Rosenberg, J. and H. Schulzrinne, "Session Initiation
              Protocol (SIP): Locating SIP Servers", RFC 3263,
              June 2002.

   [RFC3401]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part One: The Comprehensive DDDS", RFC 3401, October 2002.

   [RFC3402]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Two: The Algorithm", RFC 3402, October 2002.

   [RFC3403]  Mealling, M., "Dynamic Delegation Discovery System (DDDS)
              Part Three: The Domain Name System (DNS) Database",
              RFC 3403, October 2002.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 2005.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, March 2005.

   [RFC4366]  Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
              and T. Wright, "Transport Layer Security (TLS)
              Extensions", RFC 4366, April 2006.

   [RFC4367]  Rosenberg, J. and IAB, "What's in a Name: False
              Assumptions about DNS Names", RFC 4367, February 2006.




Peterson, et al.       Expires September 13, 2012              [Page 33]

Internet-Draft             Applications in DNS                March 2012


   [RFC4732]  Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
              Service Considerations", RFC 4732, December 2006.

   [RFC4871]  Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
              J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
              Signatures", RFC 4871, May 2007.

   [RFC4985]  Santesson, S., "Internet X.509 Public Key Infrastructure
              Subject Alternative Name for Expression of Service Name",
              RFC 4985, August 2007.

   [RFC5486]  Malas, D. and D. Meyer, "Session Peering for Multimedia
              Interconnect (SPEERMINT) Terminology", RFC 5486,
              March 2009.

   [RFC5507]  IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
              Choices When Expanding the DNS", RFC 5507, April 2009.

   [RFC5922]  Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
              Certificates in the Session Initiation Protocol (SIP)",
              RFC 5922, June 2010.

   [RFC6269]  Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
              Roberts, "Issues with IP Address Sharing", RFC 6269,
              June 2011.


























Peterson, et al.       Expires September 13, 2012              [Page 34]

Internet-Draft             Applications in DNS                March 2012


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
   Microsoft Corporation

   Email: bernarda@microsoft.com



























Peterson, et al.       Expires September 13, 2012              [Page 35]