[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 RFC 6950

Network Working Group                                         O. Kolkman
Internet-Draft                                                     NLNet
Intended status: Informational                               J. Peterson
Expires: January 12, 2012                                  NeuStar, Inc.
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                                B. Aboba
                                                   Microsoft Corporation
                                                           July 11, 2011


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

Abstract

   A number of Internet applications have integrated supplemental
   features into the Domain Name System (DNS) to support their
   operations.  Many of these features assist in locating the
   appropriate service in a domain, or in transforming intermediary
   identifiers into names that the DNS can process.  Proposals to
   incorporate more sophisticated application behavior into the DNS,
   however, have raised questions about the applicability and
   extensibility of the DNS.  This document explores the architectural
   consequences of installing certain application features in the DNS,
   and provides guidance to future application designers.

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 January 12, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.



Kolkman, et al.         Expires January 12, 2012                [Page 1]


Internet-Draft             Applications in DNS                 July 2011


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

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






























Kolkman, et al.         Expires January 12, 2012                [Page 2]


Internet-Draft             Applications in DNS                 July 2011


Table of Contents

   1.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Overview of DNS Application Usages . . . . . . . . . . . . . .  6
     2.1.  Locating Services in a Domain  . . . . . . . . . . . . . .  6
     2.2.  NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . .  7
     2.3.  Arbitrary Data in the DNS  . . . . . . . . . . . . . . . .  9
   3.  Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 10
     3.1.  Compound Queries . . . . . . . . . . . . . . . . . . . . . 10
       3.1.1.  Responses Tailored to the Originator . . . . . . . . . 11
     3.2.  Metadata about Tree Structure  . . . . . . . . . . . . . . 13
     3.3.  Using DNS as a Generic Database  . . . . . . . . . . . . . 13
       3.3.1.  Large Data in the DNS  . . . . . . . . . . . . . . . . 14
     3.4.  Administrative Structures Misaligned with the DNS  . . . . 15
     3.5.  Domain Redirection . . . . . . . . . . . . . . . . . . . . 15
   4.  Principles and Guidance  . . . . . . . . . . . . . . . . . . . 17
     4.1.  Private DNS Deployments  . . . . . . . . . . . . . . . . . 18
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 21
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26





























Kolkman, et al.         Expires January 12, 2012                [Page 3]


Internet-Draft             Applications in DNS                 July 2011


1.  Motivation

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

   The seminal MX record served as a prototype for a long series of 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 in its reincarnation as the Dynamic Delegation Discovery
   System (DDDS, [RFC3401] passim) framework, added a new wrinkle - an
   algorithm for transforming a string into a domain name, which might
   then be resolved by the DNS to find NAPTR records.  This enabled the
   resolution of identifiers that do not have traditional host
   components through the DNS; the best-known example of this are
   telephone numbers, as resolved by the DDDS application ENUM.  Recent
   work such as DomainKeys Identified Mail (DKIM, [RFC4871]) has enabled
   security features of applications to be advertised through the DNS,
   via the TXT resource record.

   As the amount of application intelligence available to the DNS has
   increased, however, some proposed usages and extensions have become
   misaligned with both the architecture and underlying protocols of the
   DNS.  In the global public DNS, for example, the resolution of domain
   names to IP addresses is public information with no need for
   confidentiality, and thus the underlying query/response protocol has
   no authentication or encryption mechanism - typically, any security
   required by an application or service is invoked after the DNS query,
   when the resolved service has been contacted.  Only in private DNS
   environments (including split horizon DNS) where the identity of the
   querier is assured through some external means does the DNS maintain
   confidential records in this sense - although for load balancing
   reasons, localization or related optimizations, the public DNS may
   return different addresses in response to queries from different
   sources, or even no response at all, which is discussed further in
   Section 3.1.1.  To take another example, the query/response protocol
   of the DNS assumes queries for a single name, and requires
   significant extension to support queries that cover ranges of names
   or scan for names matching certain criteria.  Applications in many



Kolkman, et al.         Expires January 12, 2012                [Page 4]


Internet-Draft             Applications in DNS                 July 2011


   environments require these sorts of features from databases, and as
   the features of the DNS have increased, some application protocols
   have looked to leverage the DNS for databases that include these
   capabilities.

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

   The guidance in this document complements the guidance on extending
   the DNS given in [RFC5507].  Whereas [RFC5507] considers the
   preferred ways to add new information to the underlying syntax of the
   DNS (such as defining new resource records or adding prefixes or
   suffixes to labels), the current document considers broader
   implications of offloading application features to the DNS, be it
   through extending the DNS or simply reusing existing protocol
   capabilities - implications that may concern the behavior of name
   servers, resolvers or caches, the DNS protocol, security or the
   overall architecture.
























Kolkman, et al.         Expires January 12, 2012                [Page 5]


Internet-Draft             Applications in DNS                 July 2011


2.  Overview of DNS Application Usages

   [RFC0882] identifies the original and fundamental connection between
   the DNS and applications.  It begins by describing how the
   interdomain scope of applications creates "formidable problems when
   we wish to create consistent methods for referencing particular
   resources that are similar but scattered throughout the environment."
   This motivated "the need to have a mapping between host names... and
   ARPA Internet addresses" move away from a global table (the original
   "hosts.txt" file) and to a "distributed database that performs the
   same function."  RFC0822 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 to for mail.

   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 on overview of such application usage to date.

2.1.  Locating Services in a Domain

   The MX resource record provides the simplest motivating example for
   an application advertising its resources in the Domain Name System.
   The MX resource record contains the domain name of a server within
   the administrative domain in question that receives mail; 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 in a zone, 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
   learn a host name and port where that service resides in a given



Kolkman, et al.         Expires January 12, 2012                [Page 6]


Internet-Draft             Applications in DNS                 July 2011


   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.  Email identifiers of the form "user@domain" require the
   presence of something like MX records to provide the convenience of
   simply specifying that "domain" component rather than a "host.domain"
   structure.  While for applications like HTTP, naming conventions
   continue to abound ("www.example.com"), the SRV algorithm queries for
   an application-specific label combining the protocol and transport.
   For a protocol like HTTP, the SRV service name derives corresponds to
   the URL scheme of the identifier invoked by the application
   ("_http._tcp.example.com").  The application identifier thus retained
   sole responsibility for carrying the desired protocol and domain, but
   could offload to the DNS the location of the host of that service
   within the domain, the port where the service resided on that host,
   load balancing and fault tolerance, and related application features.
   Ultimately, resolvers that acquire MX or SRV records may use them as
   intermediate transformations in order to arrive at an eventual domain
   name that will resolve to the IP addresses to contact for the service
   (as optimization, the Additional Data section of these DNS responses
   may contain the corresponding address records).

   [TBD: Potentially incorporate some discussion of Hammer's hostmeta or
   the Webfingers approach as alternatives to using the DNS to identify
   additional resources required for services]

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
   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 allowed identifiers with no recognizable
   domain component to be treated as DNS names for the purpose of name
   resolution.  Once these transformations resulted in a domain name,
   applications could retrieve NAPTR records from that zone in the DNS.
   NAPTR records contain a far more rich and complex structure than MX
   or SRV resource records.  A NAPTR record contains two different
   weighting mechanisms ("order" and "preference"), a "service" field to
   designate the application that the NAPTR record described, and then
   two fields that could contain translations: a "replacement" or
   "regular expression" field, only one of which appeared in given NAPTR
   record.  A "replacement," like NAPTR's ancestor the PTR record,
   simply designated another zone where one would look for records



Kolkman, et al.         Expires January 12, 2012                [Page 7]


Internet-Draft             Applications in DNS                 July 2011


   associated with this service in the domain.  The "regexp," on the
   other hand, allowed regular expression transformations on the
   original URI intended to transform it into an identifier that the DNS
   could resolve.

   Any sort of hierarchical identifier can potentially be encoded as a
   DNS name, and thus the DNS has often been used to resolve identifiers
   that where never devised as a name for an Internet host.  A prominent
   early example is the in-addr domain [RFC0882], which transposes an
   IPv4 address into a domain name in order to query the DNS for name
   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 zone of the DNS - thus, for example, the
   number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int.

   In the ENUM system, in place of "tpc.int" the special domain
   "e164.arpa" was reserved for use.  In its more mature form in the
   Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim)
   framework, this initial transformation of the telephone number to a
   domain name was called the "First Well Known Rule."  Its flexibility
   has inspired a number of proposals beyond ENUM to encode and resolve
   unorthodox identifiers in the DNS.  Provided that the identifiers
   transformed by the First Well Known Rule have some meaningful
   structure and are not overly lengthy, virtually anything can serve as
   an input for the DDDS structure: for example, civic addresses (see
   draft-rosen-dns-sos).  Though DDDS[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.

   In terms of the results of a DNS query, the presence of the "regexp"
   field of NAPTR records enabled unprecedented flexibility in the
   transformations that DNS resolution could perform.  Since the output
   of the regular expression frequently took the form of a URI (in ENUM
   resolution, for example, a telephone 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.






Kolkman, et al.         Expires January 12, 2012                [Page 8]


Internet-Draft             Applications in DNS                 July 2011


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.  RFC0882 identified 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."

   NAPTR did not however pioneer the storage of arbitrary data in the
   DNS.  [RFC1035] defined the TXT record, a means to store arbitrary
   strings in the DNS; RFC1035 specifically stipulates that a TXT
   contains "descriptive text" and that "the semantics of the text
   depends on the domain where it is found."  The existence of TXT
   records has long provided new applications with a rapid way of
   storing data associated with a domain name in the DNS, as adding data
   in this fashion require no registration process.  [RFC1464] added a
   means of incorporating name/value pairs to the TXT record structure,
   which allowed applications to differentiate different chunks of data
   stored in a TXT record.  Thus, an application that wants to store
   additional data in the DNS can do so without registering a new
   resource record type.

   While open policies surrounding the use of the TXT record have
   resulted in a checkered past for standardizing application usage of
   TXT, it has provided a technical solution for DKIM ([RFC4871]) to
   necessary information about the security of email in DNS.  Storing
   keys in the DNS for DKIM made sense 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 that are not
   possible if the DNS delivers the keys (provided that DNSSEC[RFC4033]
   guarantees authenticity of the data).












Kolkman, et al.         Expires January 12, 2012                [Page 9]


Internet-Draft             Applications in DNS                 July 2011


3.  Challenges for the DNS

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

   The promise that applications might rely on the DNS as a generic
   database often 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.  If an application
   protocol designer wants these properties from a database, in general
   this is a good indication that the DNS cannot meet the needs of the
   application in question.

   Since many of these new requirements have emerged from the ENUM
   space, the following sections use ENUM as an illustrative example;
   however, any application using the DNS as a feature-rich database
   could easily end up with similar requirements.

3.1.  Compound Queries

   Traditionally, the DNS requires resolvers to supply no information
   other than the domain name, the type and the class of records sought
   in order to receive a reply from an authoritative server.  Outside of
   the DNS space, however, there are plenty of query-response
   applications that require a compound or relational search, which
   takes into account more than one factor in formulating a response or
   uses no single factor as a key to the database.  For example, in the
   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



Kolkman, et al.         Expires January 12, 2012               [Page 10]


Internet-Draft             Applications in DNS                 July 2011


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

   From a sheer syntactical perspective, however, domain names do not
   admit of this sort of rich structure.  Several workaround have
   attempted to instantiate these sorts of features in DNS queries.
   Most commonly, proposals piggyback additional query parameters as
   eDNS0 extensions (see [RFC2671]).  Alternatively, the domain name
   itself could be compounded with the additional parameters: one could
   take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk
   group identifier to it, for example, of the form
   tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa.  While in the latter case, a
   DNS server can adhere to its traditional behavior in locating
   resource records, the syntactical viability of encoding additional
   parameters in this fashion is very dubious, especially if more than
   one additional parameter is required and the presence of parameters
   is optional.  The former eDNS0 case requires significant changes to
   name server behavior.

   Moreover, the implications of these sorts of compound queries for
   recursion and caching are potentially serious.  The logic used by the
   authoritative server to respond to a compound query may not be
   followed 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
   breech if the client saw the localized portal of the wrong country.
   Because recursive resolvers may obscure the origination network of
   the DNS client, a recent proposal suggested introducing a new DNS
   query parameter to be populated by DNS recursive resolvers in order



Kolkman, et al.         Expires January 12, 2012               [Page 11]


Internet-Draft             Applications in DNS                 July 2011


   to preserve the originating IP address (see
   [draft-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 can prevent
   the source IP address from conveying useful information.

   In other deployments in use today, including those based on the BIND
   "views" feature, the source IP address is used to grant access to a
   private set of resource records.  The security implications of
   trusting the source IP address of a DNS query have prevented most
   solutions along these lines from being standardized (see
   draft-ietf-intarea-shared-addressing-issues), though the practice
   remains widespread in "split horizon" private DNS deployment (see
   Section 4.1) 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, draft-kaplan-enum-source-uri provides a
   SIP URI in an eDNS0 parameter (though without any specific provision
   for cryptographically verifying the claimed identity).  Effectively,
   the conveyance of application-layer information about the
   administrative identity of the originator through the DNS is a weak
   authentication mechanism, on the basis of which the DNS server makes
   an authorization decision before sharing resource records.  This can
   parlay into a per-RR 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
   list for data, and again, caching and recursion introduce significant
   challenges for applications that attempt to offload this
   responsibility to the DNS.  Achieving feature parity with even the
   simplest authentication mechanisms available at the application layer
   would like require significant rearchitecture of the DNS.







Kolkman, et al.         Expires January 12, 2012               [Page 12]


Internet-Draft             Applications in DNS                 July 2011


3.2.  Metadata about Tree Structure

   ENUM use cases have also surfaced a couple of optimization
   requirements to reduce unnecessary calls and queries by including
   metadata that describes the contents and structure of ENUM DNS trees.
   In particular, the "send-n" proposal [draft-bellis-enum-send-n] hopes
   to reduce the number of DNS queries sent in cases where a telephone
   system is collecting dialed digits in a region that supports
   "overlap" dialing, a practice which compensates for variable-length
   numbering plans.  When the dialed number potentially has a variable
   length, a telephone switch ordinarily cannot anticipate when a dialed
   number is complete, as only the terminating customer premise
   equipment (typically a private branch exchange) knows how long a
   telephone number needs to be.  The "send-n" proposal offloads to the
   DNS the responsibility for informing the telephone switch 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.
   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 it does
   not result in faster call set-up, as the call cannot complete until
   all digits are collected.  A tangentially related proposal,
   [draft-ietf-enum-void], similarly places resource records in the DNS
   that tell the application that it need not attempt to reach a number
   on the PSTN, as the number is unassigned.

   Both proposals optimize application behavior by placing metadata in
   the DNS that predicts the success of future queries or application
   invocations.  These predictions require that the metadata remain
   synchronized with the state of the resources it predicts.
   Maintaining that synchronization, however, requires that the DNS have
   semi-real time updates that may conflict with scale and caching
   mechanisms.  It may also raise questions about the authority and
   delegation model, and whether the entities that control the zones
   where changes occur have the authority to populate the zones where
   synchronization must be maintained; in send-n, different leaf zones
   might want to populate different information in a common parent.  An
   application protocol designer who wants to manage identifiers in this
   fashion would be better served to implement this mechanism outside
   the DNS.

3.3.  Using DNS as a Generic Database

   As previously noted, the use of the First Well Known Rule of DDDS
   combined with data URLs (or potential RFC1461 TXT records)



Kolkman, et al.         Expires January 12, 2012               [Page 13]


Internet-Draft             Applications in DNS                 July 2011


   effectively allows the DNS to answer queries for arbitrary strings
   and to return arbitrary data as a value.  Some query-response
   applications, however, require queries and responses that simply fall
   outside the syntactic capabilities of the DNS.  Domain names
   themselves must conform to certain syntactic constraints: they must
   consist of labels that do not exceed 63 characters while the total
   length of the encoded name may not exceed 255 octets, they must obey
   fairly strict encoding rules, and so on.

3.3.1.  Large Data in the DNS

   While the data URL specification [RFC2397] notes that it is "only
   useful for short values," many applications today use quite large
   data URLs as workarounds in environments where only URIs can
   syntactically appear.  While the use of TCP and eDNS0 allows DNS
   responses to be quite long, nonetheless 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.
   Since the large disparity between the size of a query and size of the
   response creates this amplification, future work might identify a
   desired proportion between the size of a query and the size of a
   response.

   Since it is difficult to complete a TCP three-way handshake begun
   from a forged source address, DNS reflection attacks utilize UDP
   queries.  Unless the attacker uses EDNS0 [RFC2671] to enlarge the
   requester's maximum payload size, a response can only reach 576
   octets before the truncate bit is set in the response.  This limits
   the maximum magnification achievable from a DNS query that does not
   utilize EDNS0.

   However, where the responder supports EDNS0, an attacker may set the
   requester maximum payload size to a larger value while querying for a
   large RR, such as a certificate [RFC4398].  Thus the combination of
   large data stored in DNS RRs and responders supporting large
   requester payload sizes has the potential to increase the potential
   damage achievable in a reflection attack.  Since a reflection attack
   can be launched from any network that does not implement source
   address validation, these attacks are difficult to eliminate absent
   the ubiquitous deployment of source address validation.  Since



Kolkman, et al.         Expires January 12, 2012               [Page 14]


Internet-Draft             Applications in DNS                 July 2011


   reflection attacks are most damaging when launched from high
   bandwidth networks, the implementation of source address validation
   on these networks is particularly important.

   The bandwidth that can be mustered in a reflection attack directed by
   a botnet controlling broadband hosts is sobering.  For example, if a
   responder could be directed to generate a 10KB response in reply to a
   50 octet query, then magnification of 200:1 would be attainable.
   This would enable a botnet controlling 10000 hosts with 1 Mbps of
   bandwidth to focus 2000 Gbps of traffic on the victim, more than
   sufficient to congest any site on the Internet.

3.4.  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.  Telephone numbers in the United States,
   for example, are assigned and delegated in a relatively complex
   manner: the first three digits of a nationally specific number are an
   "area code" which is understood as an indivisible component of the
   number, yet for the purpose of the DNS, those three digits are ranked
   hierarchically.  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.

   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.

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



Kolkman, et al.         Expires January 12, 2012               [Page 15]


Internet-Draft             Applications in DNS                 July 2011


   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 the DNS in order to believe
   that their request has not been hijacked and redirected to a
   potentially malicious domain, unless some subsequent application
   mechanism can provide the necessary assurance.  By way of contrast,
   for application-layer redirections protocols like HTTP and SIP have
   widely deployed security mechanisms such as TLS that can use
   certificates to vouch that a 300 response came from the domain that
   the originator initially hoped to contact.

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

   All of these application-layer measures attempt to mirror the
   delegation of authority in the DNS, when the itself DNS serves as the
   ultimate authority on how domains are delegated.  Synchronizing a
   static instrument like a certificate with a delegation in the DNS,
   however, is problematic because delegation are not static: revoking
   and reissuing a certificate every time a delegation changes is
   cumbersome operationally.  In environments where DNSSEC is not
   available, the problems with securing DNS-layer redirections would be
   avoided by performing redirections in the application-layer.








Kolkman, et al.         Expires January 12, 2012               [Page 16]


Internet-Draft             Applications in DNS                 July 2011


4.  Principles and Guidance

   The success of the DNS relies on the fact that it is a distributed
   database, one that has the property that it is loosely coherent and
   that it offers lookup instead of search functionality.  Loose
   coherency means that answers to queries are coherent within the
   bounds of data replication between authoritative servers and caching
   behavior by recursive name servers.

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

      Data can be stored in such a way that querying just for the domain
      name, class and type suffices to provide an answer

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

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

      Data stored in the DNS can be propagated and cached without
      intermediaries needing to understand exceptional logic used by the
      authoritative server to formulate responses

   Whenever one of the four properties above does not apply to ones 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:

      Trying to establish domain boundaries within the tree - the
      delegation point in the DNS is something that applications should
      in general not be aware off

      Working from application identifiers that cannot be resolved by
      the DNS without complex encoding

      The sensitivity of the data, especially preserving its
      confidentiality from unauthorized queries in a multilateral
      environment

      Highly volatile data that synchronizes with the state of
      applications external to the DNS

      Answers dependent on the application-layer identity of the
      originator of the query




Kolkman, et al.         Expires January 12, 2012               [Page 17]


Internet-Draft             Applications in DNS                 July 2011


   There are many useful application features that can safely be
   offloaded to the DNS: aside from locating services in a domain, the
   DNS clearly can assist in the resolution of identifiers without a
   domain component (including URNs), and moreover it can host some
   static application data, like the cryptographic keys used by DKIM for
   email, which are well suited to storage in the DNS.  However, the
   prospects for offloading application features like authentication of
   query originators, structuring compound questions and implementing
   metadata about the tree structure are more remote.  While clearly
   DNS-layer redirection is a widely deployed alternative to
   application-layer redirection, many applications that choose to
   offload this have struggled to meet the resulting security
   challenges.

   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 easily
   replicated by 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.  Similarly, HTTP has numerous
   ways to provide the necessary authentication, authorization and
   confidentiality properties that some features require.

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

4.1.  Private DNS Deployments

   Much of the guidance offered by this document refers to the
   difficulties of instantiating certain application features in the
   global public root of the DNS.  There are however various private DNS
   deployments, including split horizons that give a different view of a
   zone to the public Internet than they do to internal resolvers.
   Concerns about confidentiality, for example, are far easier to manage
   in a private environment than a public one.

   Consequently, many deployments that want to install rich application
   features in DNS do so in private environments rather than in the
   public DNS.  There are several motivations for this: 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,



Kolkman, et al.         Expires January 12, 2012               [Page 18]


Internet-Draft             Applications in DNS                 July 2011


   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
   use in private and constrained environments as the basis of a
   standard solution.  When proprietary parameters or extensions are
   deployed in these private environments, it seems almost certain that
   these implementations will begin to interact with the public DNS, and
   that the private practices will leak.  Therefore, keeping these
   features within higher-layer applications rather than offloading them
   to the DNS is preferred.


































Kolkman, et al.         Expires January 12, 2012               [Page 19]


Internet-Draft             Applications in DNS                 July 2011


5.  Security Considerations

   Many of the concerns about offloading application features to the DNS
   revolve around security.  Section 3.5 discusses a security problem
   concerning redirection that has surfaced in a number of protocols
   (see [I-D.barnes-hard-problem]).  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.

   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.



































Kolkman, et al.         Expires January 12, 2012               [Page 20]


Internet-Draft             Applications in DNS                 July 2011


6.  IANA Considerations

   This document contains no considerations for the IANA.
















































Kolkman, et al.         Expires January 12, 2012               [Page 21]


Internet-Draft             Applications in DNS                 July 2011


7.  Acknowledgements

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














































Kolkman, et al.         Expires January 12, 2012               [Page 22]


Internet-Draft             Applications in DNS                 July 2011


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

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

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

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

   [RFC2397]  Masinter, L., "The "data" URL scheme", RFC 2397,
              August 1998.

   [RFC2671]  Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
              RFC 2671, August 1999.

   [RFC2818]  Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.



Kolkman, et al.         Expires January 12, 2012               [Page 23]


Internet-Draft             Applications in DNS                 July 2011


   [RFC2826]  Internet Architecture Board, "IAB Technical Comment on the
              Unique DNS Root", RFC 2826, May 2000.

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

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

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

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

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

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

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

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

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

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

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

   [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



Kolkman, et al.         Expires January 12, 2012               [Page 24]


Internet-Draft             Applications in DNS                 July 2011


              Subject Alternative Name for Expression of Service Name",
              RFC 4985, August 2007.

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










































Kolkman, et al.         Expires January 12, 2012               [Page 25]


Internet-Draft             Applications in DNS                 July 2011


Authors' Addresses

   Olaf Kolkman
   NLNet

   Email: olaf@nlnetlabs.nl


   Jon Peterson
   NeuStar, Inc.

   Email: jon.peterson@neustar.biz


   Hannes Tschofenig
   Nokia Siemens Networks

   Email: Hannes.Tschofenig@gmx.net


   Bernard Aboba
   Microsoft Corporation

   Email: bernarda@microsoft.com



























Kolkman, et al.         Expires January 12, 2012               [Page 26]


Html markup produced by rfcmarkup 1.129b, available from https://tools.ietf.org/tools/rfcmarkup/