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]
