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

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

Network Working Group                                         O. Kolkman
Internet-Draft                                                     NLNet
Intended status: Standards Track                             J. Peterson
Expires: April 20, 2011                                    NeuStar, Inc.
                                                           H. Tschofenig
                                                  Nokia Siemens Networks
                                                                B. Aboba
                                                   Microsoft Corporation
                                                        October 17, 2010


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

Abstract

   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 the DNS, 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 April 20, 2011.

Copyright Notice




Kolkman, et al.          Expires April 20, 2011                 [Page 1]


Internet-Draft             Applications in DNS              October 2010


   Copyright (c) 2010 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 April 20, 2011                 [Page 2]


Internet-Draft             Applications in DNS              October 2010


Table of Contents

   1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Motivation . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Overview of DNS Application Usages . . . . . . . . . . . . . .  7
     3.1.  Locating Services in a Domain  . . . . . . . . . . . . . .  7
     3.2.  NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . .  8
     3.3.  Arbitrary Data in the DNS  . . . . . . . . . . . . . . . .  9
   4.  Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11
     4.1.  Compound Queries . . . . . . . . . . . . . . . . . . . . . 11
       4.1.1.  Responses Tailored to the Originator . . . . . . . . . 12
     4.2.  Metadata about Tree Structure  . . . . . . . . . . . . . . 12
     4.3.  Using DNS as a Generic Database  . . . . . . . . . . . . . 13
       4.3.1.  Administrative Structures Misaligned with the DNS  . . 14
     4.4.  Domain Redirection . . . . . . . . . . . . . . . . . . . . 14
   5.  Principles and Guidance  . . . . . . . . . . . . . . . . . . . 16
     5.1.  Private DNS Deployments  . . . . . . . . . . . . . . . . . 17
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23





























Kolkman, et al.          Expires April 20, 2011                 [Page 3]


Internet-Draft             Applications in DNS              October 2010


1.  Terminology

   In this document, the key words "MAY", "MUST, "MUST NOT", "SHOULD",
   and "SHOULD NOT", are to be interpreted as described in [RFC2119].















































Kolkman, et al.          Expires April 20, 2011                 [Page 4]


Internet-Draft             Applications in DNS              October 2010


2.  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 MX resource record, which helped email addressed to
   the domain to find an authoritative mail service for the domain.

   The MX record was the first of a long series of DNS resource records
   that supported applications associated with a domain name.  The SRV
   resource record provided a more general mechanism for identifying
   services in a domain, complete with a weighting system and selection
   among transports.  The NAPTR resource record, especially in its
   reincarnation as the DDDS 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 DKIM has
   enabled security features of applications to be advertised through
   the DNS, via the TXT resource record.

   As the amount of application intelligence in 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 traditional domain names to IP addresses is public
   information, lacking any confidentiality requirement - any security
   needed by an application or service is invoked after the service has
   been contacted.  Typically, the translation is also global
   information, meaning that the response to a resolution 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 different queries, or even no response at
   all, which is discussed further below).  These assumptions permit the
   existence of a single authoritative unique global root of the DNS,
   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.

   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 URI, and URIs themselves are containers
   for basically arbitrary data, through the DDDS framework one can



Kolkman, et al.          Expires April 20, 2011                 [Page 5]


Internet-Draft             Applications in DNS              October 2010


   query 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 over
   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 April 20, 2011                 [Page 6]


Internet-Draft             Applications in DNS              October 2010


3.  Overview of DNS Application Usages

   While the fundamental motivation for the Domain Name System was to
   replace lengthy numeric addresses with strings that are easier to
   interpret and memorize, the hierarchical system of hosts and domains
   rendered the DNS important for its administrative properties as well
   as its mnemonics.  In so far as the DNS explained how to reach an
   administrative domain rather than simply a host, it naturally
   extended 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
   such a discovery mechanism could be built by each such application
   protocol, the universality of the DNS invites installing these such
   features in its public tree.

3.1.  Locating Services in a Domain

   The Mail Exchange (MX) DNS resource record provides the simplest
   motivating example for an application advertising its host in the
   Domain Name System.  The MX resource record contains the hostname of
   a server within the administrative domain in question that receives
   mail; that hostname 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 hosts that can receive mail when the
   primary server is offline.  One can even load balance across several
   such hosts.  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) and to learn the
   hostname 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 has
   important implications for the way that applications manage
   identifiers.  Email identifiers of the form "user@domain" require the



Kolkman, et al.          Expires April 20, 2011                 [Page 7]


Internet-Draft             Applications in DNS              October 2010


   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
   the invoked protocol based, for protocol like HTTP derived from the
   URL scheme of the identifier invoked by the application.  The
   application 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 hostname 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]

3.2.  NAPTR and DDDS

   The Naming Authority Pointer (NAPTR, originally [RFC2168]) record
   evolved to fulfill a need in the transition from Uniform Resource
   Locators (URLs) to the more mature Uniform Resource Indicators (URIs)
   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 resolved on the Internet.  Once these
   transformations resulted in a domain name, applications could receive
   NAPTR records from that zone of the DNS.  NAPTR records contain a far
   more rich and complex structure than the MX or SRV resource records.
   A NAPTR contained 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 resolve.

   The same mechanism could obviously be applied to other sorts of
   identifiers that lacked a domain component, and thus this work
   naturally combined with activities to create a system for resolving
   telephone numbers on the Internet, which became known as ENUM



Kolkman, et al.          Expires April 20, 2011                 [Page 8]


Internet-Draft             Applications in DNS              October 2010


   (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 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 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), 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.  For a query-response application, the
   DNS could effectively implement the entire application feature set.
   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 one.

3.3.  Arbitrary Data in the DNS

   NAPTR did not pioneer the possibility of storing 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.  This, an
   application that wants to store additional data in the DNS can do so
   without registering a new resource record type.

   While the laxity of policies surrounding the use of the TXT record
   has resulted in a checkered past for standardizing application usage



Kolkman, et al.          Expires April 20, 2011                 [Page 9]


Internet-Draft             Applications in DNS              October 2010


   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 because 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 April 20, 2011                [Page 10]


Internet-Draft             Applications in DNS              October 2010


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

4.1.  Compound Queries

   Traditionally, the DNS requires resolvers to supply no information
   other than the domain name (and the type and class of records sought)
   in order to receive a reply from an authoritative server.  There are,
   however, plenty of query-response applications in deployments that
   require a compound search, which takes into account more than one
   factor in formulating a response.  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.  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,
   the domain name itself can be compounded with the additional
   parameters: one could take a name like



Kolkman, et al.          Expires April 20, 2011                [Page 11]


Internet-Draft             Applications in DNS              October 2010


   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 case requires significant changes to DNS
   server behavior.  Moreover, the implications for these sorts of
   compound queries on recursion and caching are potentially serious.

4.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.  Often the source IP address is somehow mapped to the
   administrative entity of the originator in deployments with this
   requirement today.  The security implications of trusting the source
   IP address of a DNS query have prevented most solutions along these
   lines from being standardized.  Some applications require 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 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.

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



Kolkman, et al.          Expires April 20, 2011                [Page 12]


Internet-Draft             Applications in DNS              October 2010


   "overlap" dialing, a form of variable-length number plan.  In these
   plans, 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 how many
   digits 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 to reach a name for a complete number.  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.  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 is unclear why this data is better maintained by the
   DNS than in an unrelated application protocol.

4.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.
   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 be
   interpolated.  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.  Similarly the 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.






Kolkman, et al.          Expires April 20, 2011                [Page 13]


Internet-Draft             Applications in DNS              October 2010


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

4.4.  Domain Redirection

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

   Implementing domain redirection in the DNS, however, has important
   consequences for application security.  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



Kolkman, et al.          Expires April 20, 2011                [Page 14]


Internet-Draft             Applications in DNS              October 2010


   ([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 April 20, 2011                [Page 15]


Internet-Draft             Applications in DNS              October 2010


5.  Principles and Guidance

   The success of the DNS relies on the fact that it is a distributed
   database 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 and
      query type provide a direct answer

      Answers are only depended on the question (name and type), not on
      the location or identity of the entity doing the query

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

   Whenever one of the 3 properties 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

      Having to do more than one, two queries to get to ones answer
      (consider a chain of NAPTR records)

      The sensitivity of the data provided by the DNS

      Highly volatile data

      Location- or identity-dependent answers

   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



Kolkman, et al.          Expires April 20, 2011                [Page 16]


Internet-Draft             Applications in DNS              October 2010


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

5.1.  Private DNS Deployments

   Today, many deployments that want to install these 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.  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, practically by definition these techniques will not
   form the basis of a standard solution.  Moreover, as implementations
   come to support 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 April 20, 2011                [Page 17]


Internet-Draft             Applications in DNS              October 2010


6.  Security Considerations

   Many of the concerns about offloading application features to the DNS
   revolve around security.  Section 4.4 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 4.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 April 20, 2011                [Page 18]


Internet-Draft             Applications in DNS              October 2010


7.  IANA Considerations

   This document contains no considerations for the IANA.
















































Kolkman, et al.          Expires April 20, 2011                [Page 19]


Internet-Draft             Applications in DNS              October 2010


8.  Acknowledgements

   The IAB would like to thank Patrik Faltstrom for his contribution.
















































Kolkman, et al.          Expires April 20, 2011                [Page 20]


Internet-Draft             Applications in DNS              October 2010


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

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

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

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

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

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

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

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




Kolkman, et al.          Expires April 20, 2011                [Page 21]


Internet-Draft             Applications in DNS              October 2010


   [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 April 20, 2011                [Page 22]


Internet-Draft             Applications in DNS              October 2010


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 April 20, 2011                [Page 23]


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