[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: BCP                                         J. Peterson
Expires: September 15, 2011                                NeuStar, Inc.
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                                B. Aboba
                                                   Microsoft Corporation
                                                          March 14, 2011

    Architectural Considerations on Application Features in the DNS


   While the principal purpose of the Domain Name System (DNS) is to
   translate Internet domain names to IP addresses, over time a number
   of Internet applications have integrated supplemental features into
   the 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 piggyback more sophisticated application behavior on top
   of the DNS, however, have raised questions about the propriety of
   instantiating some features in that way, especially those with
   security sensitivities.  This document explores the architectural
   consequences of installing application features in the DNS, and
   provides guidance for future work in this area.

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 15, 2011.

Copyright Notice

Kolkman, et al.        Expires September 15, 2011               [Page 1]

Internet-Draft             Applications in DNS                March 2011

   Copyright (c) 2011 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.

Kolkman, et al.        Expires September 15, 2011               [Page 2]

Internet-Draft             Applications in DNS                March 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  . . . . . . . . . . . . . . . .  8
   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  . . . . . . . . . . . . . . 12
     3.3.  Using DNS as a Generic Database  . . . . . . . . . . . . . 13
       3.3.1.  Large Data in the DNS  . . . . . . . . . . . . . . . . 13
     3.4.  Administrative Structures Misaligned with the DNS  . . . . 14
     3.5.  Domain Redirection . . . . . . . . . . . . . . . . . . . . 14
   4.  Principles and Guidance  . . . . . . . . . . . . . . . . . . . 16
     4.1.  Private DNS Deployments  . . . . . . . . . . . . . . . . . 17
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   8.  Informative References . . . . . . . . . . . . . . . . . . . . 22
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24

Kolkman, et al.        Expires September 15, 2011               [Page 3]

Internet-Draft             Applications in DNS                March 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 made the Internet easier to use by
   providing a valuable layer of indirection between well-known names
   and lower layer protocol elements.  [RFC0974], however, 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 identifying 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]) framework, added a new wrinkle - a way of
   casting any sort of string as a domain name, which might then be
   "resolved" by the DNS to find NAPTR records.  This enabled the
   resolution of identifiers other than traditional domain names 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 extensions have become misaligned
   with the foundational assumptions of the DNS.  One such assumption is
   that the resolution of domain names to IP addresses is public
   information with no need for confidentiality - any security required
   by an application or service is invoked after the DNS query, when the
   resolved service has been contacted.  Typically, the translation also
   does not depend on the identity of the querier (although for load
   balancing reasons or related optimizations, the 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).  These assumptions permit the existence of a single
   authoritative unique global root of the DNS (see [RFC2826], and also
   underlie the scaling capabilities of the DNS, notably the ability of
   intermediaries to cache responses.  At the point where these
   assumptions no longer apply to the data that an application requires,
   one can reasonably question whether or not that application should
   use the DNS to deliver that data.

Kolkman, et al.        Expires September 15, 2011               [Page 4]

Internet-Draft             Applications in DNS                March 2011

   Increasingly, however, the flexibility of the DDDS framework has
   encouraged the repurposing of the DNS into a generic database.  Since
   the output of DDDS can be a Uniform Resource Indicator (URI
   [RFC3986]), and URIs themselves are containers for basically
   arbitrary data, one can query through the DDDS framework for an
   arbitrary string (provided it can be formatted and contained within
   the syntactical limits of a domain name) and receive as a response an
   equally arbitrary chunk of data.  The use of the DNS for generic
   database lookups is especially attractive in environments that
   already use the DDDS framework, where deployments would prefer to
   reuse the existing query/response interface of the DNS rather than
   installing a new and separate database capability.

   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.  It is the
   features themselves, rather than any syntactical representation of
   those features, that are considered here.

Kolkman, et al.        Expires September 15, 2011               [Page 5]

Internet-Draft             Applications in DNS                March 2011

2.  Overview of DNS Application Usages

   While the original motivation for the Domain Name System was to
   implement as an Internet service a means of masking lengthy numeric
   addresses with strings that are easier to interpret and memorize, the
   hierarchical system of domains rendered the DNS important for its
   administrative properties as well as its mnemonics.  Since the DNS
   explained how to reach an administrative domain rather than simply a
   host, it was natural to extend the DNS further to optimize for
   reaching particular applications within a domain.  Without these
   extensions, a user trying to send mail to a foreign domain, for
   example, lacked a discovery mechanism to locate the right host in the
   remote domain 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.

2.1.  Locating Services in a Domain

   The MX resource record provides the simplest motivating example for
   an application advertising its hosts 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 an IP address 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 several important
   benefits.  Firstly, one can put multiple MX records in a zone, in
   order to designate backup servers that can receive mail when the
   primary server is offline.  One can even 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 search for particular applications and underlying
   transports (for example, HTTP running over TLS, see [RFC2818]) and to
   learn the domain name and port where that service resides in a given
   administrative domain.  It also provides a weighting mechanism to
   allow load balancing across several (presumably equivalent) instances
   of a service in a domain.

   The reliance of applications on the existence of MX and SRV records
   has important implications for the way that applications manage

Kolkman, et al.        Expires September 15, 2011               [Page 6]

Internet-Draft             Applications in DNS                March 2011

   identifiers.  Email identifiers of the form "user@domain" require the
   presence of 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 label derives from the URL scheme
   of the identifier invoked by the application.  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 use them as intermediate transformations in order to arrive
   at an eventual domain name that will resolve to the IP address of a
   host to contact for the service.

   [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 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
   associated with this service in the domain.  The "regexp," on the
   other hand, allowed sed-like transformations on the original URI
   intended to transform it into an identifier that the DNS could

   The same mechanism could obviously be applied to other sorts of
   identifiers that lacked a domain component, and thus this work

Kolkman, et al.        Expires September 15, 2011               [Page 7]

Internet-Draft             Applications in DNS                March 2011

   naturally combined 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 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  In the ENUM
   system, in place of "tpc.int" the special domain "e164.arpa" was
   reserved for use.  In its more mature form in Dynamic Delegation and
   Discovery Service (DDDS) ([RFC3401] passim) framework, this initial
   transformation 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 hierarchical 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).

   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), anything that could be encoded as
   a URI might be the result of resolving a NAPTR record.  Since URI
   encoding has ways of carrying basically arbitrary data (see for
   example, the base 64 encoded binary data in the data URL [RFC2397]),
   resolving a NAPTR record might result in an output other than an
   identifier which would subsequently be resolved to an IP address and
   contacted for a particular application - it could give a literal
   result consumed by the application.  Thus, the DNS could effectively
   implement the entire application feature set of any simple query-
   response protocol.  Effectively, the DDDS framework turned the DNS
   into a generic database - indeed, the DNS serves as but one example
   of a possible back-end for DDDS, and perhaps not the most suitable

2.3.  Arbitrary Data in the DNS

   NAPTR did not pioneer the storage of arbitrary data in the DNS.
   [RFC1464] defined the TXT record, a means to store arbitrary string
   data in the DNS using a simple attribute name/value pair syntax.  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 the attribute names require no registration process and can simply
   be minted at will.  Thus, an application that wants to store
   additional data in the DNS can do so without registering a new
   resource record type.

Kolkman, et al.        Expires September 15, 2011               [Page 8]

Internet-Draft             Applications in DNS                March 2011

   While lax policies surrounding the use of the TXT record has resulted
   in a checkered past for standardizing application usage of TXT, it
   has provided a technical solution for DKIM ([RFC4871]) to store
   cryptographic keys for 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 guarantees authenticity of zone files).

Kolkman, et al.        Expires September 15, 2011               [Page 9]

Internet-Draft             Applications in DNS                March 2011

3.  Challenges for the DNS

   These methods for transforming arbitrary identifiers into domain
   names, and for returning arbitrary data in response to DNS queries,
   both represent significant extensions from the original concept of
   the DNS, yet neither fundamentally alters the underlying model of the
   DNS.  The promise that applications might rely on the DNS as a
   generic database, however, invariably 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 desires 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 (along with the type and 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
   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.

   Several workaround have attempted to instantiate these sorts of
   features in the DNS.  Most commonly, proposals piggyback additional
   query parameters as eDNS0 extensions (see [RFC2671]).  Alternatively,

Kolkman, et al.        Expires September 15, 2011              [Page 10]

Internet-Draft             Applications in DNS                March 2011

   the domain name itself can be compounded with the additional
   parameters: one could take a name like and append a trunk group identifier
   to it, for example, of the form
   tg011.  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
   DNS server behavior.  Moreover, the implications of these sorts of
   compound queries for recursion and caching are potentially serious.

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 is used to serve a location-specific name.  For those
   sorts of applications, which general lack security implications (for
   example, providing a web portal customized to the region of the
   client), relying on the source IP address introduces little harm.
   Because recurse 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
   draft-vandergaast-edns-client-ip).  However, aside from purely
   cosmetic uses, these approaches have many known limitations due to
   the prevalence of VPNs, onion routing systems, and so on.  Some
   transitional deployments today, however, use the source IP address is
   often mapped to the administrative identity of the originator.  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 private DNS deployment (see
   Section 4.1).  Some applications 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 this
   information about the administrative identity of the originator 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 selective 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

Kolkman, et al.        Expires September 15, 2011              [Page 11]

Internet-Draft             Applications in DNS                March 2011

   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.

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

Kolkman, et al.        Expires September 15, 2011              [Page 12]

Internet-Draft             Applications in DNS                March 2011

   might want to populate different information in a common parent.  It
   is ultimately unclear why this data is better maintained by the DNS
   than in an unrelated application protocol, nor why applications
   should wait until they are collecting digits to learn this

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 effectively allows the DNS to answer queries
   for arbitrary strings and to return arbitrary data as 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 with 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
   futhermore need to minimize the potential damage achievable in a
   reflection attack, 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 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 utilizes 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

Kolkman, et al.        Expires September 15, 2011              [Page 13]

Internet-Draft             Applications in DNS                March 2011

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

   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

Kolkman, et al.        Expires September 15, 2011              [Page 14]

Internet-Draft             Applications in DNS                March 2011

   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

   Implementing domain redirection in the DNS, however, has important
   consequences for application security.  Un 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 deferencing 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), 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 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.  The difficulty of
   synchronizing a static instrument like a certificate with a
   delegation in the DNS, however, exposes the fundamentally problematic
   nature of this endeavor.  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 September 15, 2011              [Page 15]

Internet-Draft             Applications in DNS                March 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 a single query name, class
      and type provide a direct answer

      Data is indexed by keys that are semantically and syntactically

      Answers only depend on the question (name, type and class), not on
      the identity of the entity doing the query

      Data stored in the DNS is resilient to data propagation and
      caching behavior

   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 excessively complex transformations

      The sensitivity of the data provided by the DNS, especially

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

      Answers dependent on the application-layer identity or location of
      the source of the query

   There are many useful application features that can safely be
   offloaded to the DNS: aside from locating services in a domain, the

Kolkman, et al.        Expires September 15, 2011              [Page 16]

Internet-Draft             Applications in DNS                March 2011

   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

   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 records can contain URIs, those
   URI can point to an external query-response service such as HTTP,
   with a NAPTR service field that signal to applications that questions
   of interest can be answered at that service.

4.1.  Private DNS Deployments

   Today, many deployments that want to install these rich application
   features in DNS do so in private environments rather than in the
   public DNS tree.  There are two motivations for this: in the first
   place, proprietary non-standard parameters can easily be integrated
   into DNS queries or responses; secondly, confidentiality and custom
   responses can be provided by deploying, respectively, underlying VPNs
   to shield the private tree from public queries, and effectively
   different virtual DNS trees for each administrative entity that might
   launch a query (so-called "split horizon" DNS being one such
   example).  In these constrained environments, caching and recursive
   resolvers can be managed or eliminated in order to prevent any
   unexpected intermediary behavior.

   While these deployments address the requirements of applications that
   rely on them, by definition these techniques will not form the basis
   of a standard solution.  Moreover, as implementations come to support

Kolkman, et al.        Expires September 15, 2011              [Page 17]

Internet-Draft             Applications in DNS                March 2011

   these proprietary parameters, it seems almost certain that these
   private techniques will begin to leak into the public DNS.
   Therefore, keeping these features within higher-layer applications
   rather than offloading them to the DNS is preferred.

Kolkman, et al.        Expires September 15, 2011              [Page 18]

Internet-Draft             Applications in DNS                March 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 September 15, 2011              [Page 19]

Internet-Draft             Applications in DNS                March 2011

6.  IANA Considerations

   This document contains no considerations for the IANA.

Kolkman, et al.        Expires September 15, 2011              [Page 20]

Internet-Draft             Applications in DNS                March 2011

7.  Acknowledgements

   The IAB would like to thank Ed Lewis, Ray Bellis, Lawrence Conroy,
   Ran Atkinson, Patrik Faltstrom and Eliot Lear for their

Kolkman, et al.        Expires September 15, 2011              [Page 21]

Internet-Draft             Applications in DNS                March 2011

8.  Informative References

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

              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.

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

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

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

Kolkman, et al.        Expires September 15, 2011              [Page 22]

Internet-Draft             Applications in DNS                March 2011

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

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, January 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.

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

   [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 September 15, 2011              [Page 23]

Internet-Draft             Applications in DNS                March 2011

Authors' Addresses

   Olaf Kolkman

   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 September 15, 2011              [Page 24]

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