Network Working Group O. Kolkman
Internet-Draft NLNet
Intended status: Informational J. Peterson
Expires: May 3, 2012 NeuStar, Inc.
H. Tschofenig
Nokia Siemens Networks
B. Aboba
Microsoft Corporation
October 31, 2011
Architectural Considerations on Application Features in the DNS
draft-iab-dns-applications-03
Abstract
A number of Internet applications rely on the Domain Name System
(DNS) to support their operations. Many applications use the DNS to
locate services for a domain, for example; more recently, some
applications have begun transforming identifiers other than domain
names into formats that the DNS can process. Proposals to
incorporate more sophisticated application behavior into the DNS,
however, have raised questions about the applicability and
extensibility of the DNS. This document explores the architectural
consequences of installing certain application features in the DNS,
and provides guidance to future application designers as to the sorts
of ways that application can make use of the DNS.
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 May 3, 2012.
Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the
Kolkman, et al. Expires May 3, 2012 [Page 1]
Internet-Draft Applications in DNS October 2011
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 May 3, 2012 [Page 2]
Internet-Draft Applications in DNS October 2011
Table of Contents
1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Overview of DNS Application Usages . . . . . . . . . . . . . . 6
2.1. Locating Services in a Domain . . . . . . . . . . . . . . 6
2.2. NAPTR and DDDS . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9
3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 11
3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 11
3.1.1. Responses Tailored to the Originator . . . . . . . . . 13
3.2. Using DNS as a Generic Database . . . . . . . . . . . . . 14
3.2.1. Large Data in the DNS . . . . . . . . . . . . . . . . 14
3.3. Administrative Structures Misaligned with the DNS . . . . 16
3.3.1. Metadata about Tree Structure . . . . . . . . . . . . 17
3.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 19
4. Private DNS and Split Horizon . . . . . . . . . . . . . . . . 21
5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 23
6. Security Considerations . . . . . . . . . . . . . . . . . . . 25
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 27
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
10. Informative References . . . . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33
Kolkman, et al. Expires May 3, 2012 [Page 3]
Internet-Draft Applications in DNS October 2011
1. Motivation
The Domain Name System (DNS) has long provided a general means of
translating easily-memorized domain names into numeric Internet
Protocol addresses, which makes the Internet easier to use by
providing a valuable layer of indirection between well-known names
and lower-layer protocol elements. [RFC0974] documented a further
use of the DNS: to manage application services operating in a domain
with the Mail Exchange (MX) resource record, which helped email
addressed to the domain to find a mail service for the domain
sanctioned by the zone administrator.
The seminal MX record served as a prototype for other DNS resource
records that supported applications associated with a domain name.
The SRV resource record [RFC2052] provided a more general mechanism
for locating services in a domain, complete with a weighting system
and selection among transports. The Naming Authority Pointer (NAPTR,
originally [RFC2168]) resource record, especially as it evolved into
the more general Dynamic Delegation Discovery System (DDDS, [RFC3401]
passim) framework, added a new wrinkle - an algorithm for
transforming a string into a domain name, which might then be
resolved by the DNS to find NAPTR records. This enabled the
resolution of identifiers that do not have traditional host
components through the DNS; the best-known example of this are
telephone numbers, as resolved by the DDDS application ENUM. Recent
work such as Domain Keys Identified Mail (DKIM, [RFC4871]) has
enabled security features of applications to be advertised through
the DNS, via the TXT resource record.
As the amount of application intelligence available to the DNS has
increased, however, some proposed usages and extensions have become
misaligned with both the architecture and underlying protocols of the
DNS. In the global public DNS, for example, the resolution of domain
names to IP addresses is public information with no expectation of
confidentiality, and thus the underlying query/response protocol has
no authentication or encryption mechanism - typically, any security
required by an application or service is invoked after the DNS query,
when the resolved service has been contacted. Only in private DNS
environments (including split horizon DNS) where the identity of the
querier is assured through some external means does the DNS maintain
confidential records in this sense - although for load balancing
reasons, localization or related optimizations, the public DNS may
return different addresses in response to queries from different
sources, or even no response at all, which is discussed further in
Section 3.1.1. Applications in many environments require these sorts
of features from databases, and as the contexts in which applications
rely on the DNS have increased, some application protocols have
looked to extend the DNS to include these sorts of capabilities.
Kolkman, et al. Expires May 3, 2012 [Page 4]
Internet-Draft Applications in DNS October 2011
This document therefore provides guidance to designers of
applications and application protocols on the use or extension of the
DNS to provide features to applications. It offers an overview of
ways that applications have used the DNS in the past, as well as
proposed ways that applications could use the DNS that might raise
concerns. It gives some reasons to decide the question, "Should I
store this information in the DNS, or use some other means?" when
that question arises during protocol development. These guidelines
remind application protocol designers of the strengths and weaknesses
of the DNS in order to make it easier for designers to decide what
features the DNS should provide for their application.
The guidance in this document complements the guidance on extending
the DNS given in [RFC5507]. Whereas [RFC5507] considers the
preferred ways to add new information to the underlying syntax of the
DNS (such as defining new resource records or adding prefixes or
suffixes to labels), the current document considers broader
implications of offloading application features to the DNS, be it
through extending the DNS or simply reusing existing protocol
capabilities - implications that may concern the invocation of the
resolver by applications, the behavior of name servers, resolvers or
caches, extensions to the underlying DNS protocol, the operational
responsibilities of zone administrators, security, or the overall
architecture of names. When existing DNS protocol fields are used in
ways that their designers did not intend to handle new applications,
those applications may require further changes and extensions that
are fundamentally at odds with the strengths of the DNS.
Kolkman, et al. Expires May 3, 2012 [Page 5]
Internet-Draft Applications in DNS October 2011
2. Overview of DNS Application Usages
[RFC0882] identifies the original and fundamental connection between
the DNS and applications. It begins by describing how the
interdomain scope of applications creates "formidable problems when
we wish to create consistent methods for referencing particular
resources that are similar but scattered throughout the environment."
This motivated "the need to have a mapping between host names... and
ARPA Internet addresses" transition from a global table (the original
"hosts.txt" file) to a "distributed database that performs the same
function." [RFC0882] also envisioned some ways to find the resources
associated with mailboxes in a domain: without these extensions, a
user trying to send mail to a foreign domain lacked a discovery
mechanism to locate the right host in the remote domain to which to
connect.
While a special-purpose discovery mechanism could be built by each
such application protocol that needed this functionality, the
universality of the DNS invites installing these features into its
public tree. Over time, several other applications leveraged
resource records for locating services in a domain or for storing
application data associated with a domain in the DNS. This section
gives an overview of such application usage to date.
2.1. Locating Services in a Domain
The MX resource record provides the simplest motivating example for
an application advertising its resources in the Domain Name System.
The MX resource record contains the domain name of a server that
receives mail on behalf of the administrative domain in question;
that domain name must itself be resolved to one or more IP addresses
through the DNS in order to reach the mail server. While naming
conventions for applications might serve a similar purpose (a host
might be named "mail.example.com" for example), approaching service
location through the creation of a new resource record yields
important benefits. For example, one can put multiple MX records
under the same name, in order to designate backup resources or to
load balance across several such servers (see [RFC1794]); these
properties could not easily be captured by naming conventions (see
[RFC4367]).
While the MX record represents a substantial improvement over naming
conventions as a means of service location, it remains specific to a
single application. Thus, the general approach of the MX record was
adapted to fit a broader class of application through the Service
(SRV) resource record (originally [RFC2052]). The SRV record allows
DNS resolvers to query for particular services and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
Kolkman, et al. Expires May 3, 2012 [Page 6]
Internet-Draft Applications in DNS October 2011
learn a host name and port where that service resides in a given
domain. It also provides a weighting mechanism to allow load
balancing across several instances of a service.
The reliance of applications on the existence of MX and SRV records
has important implications for the way that applications manage
identifiers, and that way that applications pass DNS names to
resolvers. Email identifiers of the form "user@domain" rely on MX
records to provide the convenience of simply specifying a "domain"
component rather requiring to guess which particular host handles
mail on behalf of the domain. While for applications like web
browsing, naming conventions continue to abound ("www.example.com"),
SRV records allow applications to query for an application-specific
protocol and transport. For HTTP, the SRV service name corresponds
to the URL scheme of the identifier invoked by the application (e.g.,
when "http://example.com" is the identifier, the SRV query is for
"_http._tcp.example.com"); for other applications, the SRV service
that the application passes to the resolver may be implicit in the
identifier. The identifier used at the application layer thus
designates the desired protocol and domain, but the application
offloads to the DNS finding the location of the host of that service
for the domain, the port where the service resided on that host, load
balancing and fault tolerance, and related application features.
Ultimately, resolvers that acquire MX or SRV records may use them as
intermediate transformations in order to arrive at an eventual domain
name that will resolve to the IP addresses to contact for the
service.
Locating specific services for a domain is thus the first major
function that applications offloaded to the DNS in addition to simple
name resolution. SRV broadened and generalized the precedent of MX
to make service location available to any application, rather than
just to mail. As the domain name of the located service might
require a second DNS query to resolve, [RFC1034] shows that the
Additional Data section of DNS responses may contain the
corresponding address records for the names of services designated by
the MX record; this optimization, which requires support in the
authoritative server and the resolver, is an initial example of how
support for application features requires changes to DNS operation.
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
[RFC3986] framework, which incorporated Uniform Resources Names
(URNs). Unlike URLs, URNs typically do not convey enough semantics
internally to resolve them through the DNS, and consequently a
separate URI-transformation mechanism is required to convert these
Kolkman, et al. Expires May 3, 2012 [Page 7]
Internet-Draft Applications in DNS October 2011
types of URIs into domain names. This allowed identifiers with no
recognizable domain component to be treated as DNS names for the
purpose of name resolution. Once these transformations resulted in a
domain name, applications could retrieve NAPTR records under that
name in the DNS. NAPTR records contain a far more rich and complex
structure than MX or SRV resource records. A NAPTR record contains
two different weighting mechanisms ("order" and "preference"), a
"service" field to designate the application that the NAPTR record
described, and then two fields that 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 designates another domain name where
one would look for records associated with this service in the
domain. The "regexp," on the other hand, allows regular expression
transformations on the original URI intended to transform it into an
identifier that the DNS could resolve.
As the Abstract of [RFC2915] says, "This allows the DNS to be used to
lookup services for a wide variety of resource names (including URIs)
which are not in domain name syntax." Any sort of hierarchical
identifier can potentially be encoded as a DNS name, and thus
historically the DNS has often been used to resolve identifiers that
were never devised as a name for an Internet host. A prominent early
example is the in-addr domain [RFC0882], which transposes an IPv4
address into a domain name in order to query the DNS for name(s)
associated with the address. Similar mechanisms could obviously be
applied to other sorts of identifiers that lacked a domain component.
Eventually, this idea connected with activities to create a system
for resolving telephone numbers on the Internet, which became known
as ENUM (originally [RFC2916]). ENUM borrowed from an earlier
proposal, the "tpc.int" domain [RFC1530], which provided a means for
encoding telephone numbers as domain names by applying a string
preparation algorithm that required reversing the digits and treating
each individual digit as a label in a DNS name - thus, for example,
the number +15714345400 became 0.0.4.5.4.3.4.1.7.5.1.tpc.int.
In the ENUM system, in place of "tpc.int" the special domain
"e164.arpa" was reserved for use. In its more mature form in the
Dynamic Delegation and Discovery Service (DDDS) ([RFC3401] passim)
framework, this initial transformation of the telephone number to a
domain name was called the "First Well Known Rule." Its flexibility
has inspired a number of proposals beyond ENUM to encode and resolve
unorthodox identifiers in the DNS. Provided that the identifiers
transformed by the First Well Known Rule have some meaningful
structure and are not overly lengthy, virtually anything can serve as
an input for the DDDS structure: for example, civic addresses.
Though [RFC3402] stipulates of the identifier that "the lexical
structure of this string must imply a unique delegation path," there
Kolkman, et al. Expires May 3, 2012 [Page 8]
Internet-Draft Applications in DNS October 2011
is no requirement that the identifier be hierarchical, nor that the
points of delegation in the domain name created by the First Well
Known Rule correspond to any points of administrative delegation
implied by the structure of the identifier.
While this ability to look up names "which are not in the domain name
syntax" does not change the underlying DNS protocols - the names
generated by the DDDS algorithm are still just domain names - it does
change the context in which applications pass name to resolvers, and
can potentially require very different operational practices of zone
administrators(see Section 3.3). In terms of the results of a DNS
query, the presence of the "regexp" field of NAPTR records enabled
unprecedented flexibility in the types of identifiers that
applications could resolve with the DNS. Since the output of the
regular expression frequently took the form of a URI (in ENUM
resolution, for example, a telephone number might be converted into a
SIP URI [RFC3261]), anything that could be encoded as a URI might be
the result of resolving a NAPTR record - which, as the next section
explores, essentially means arbitrary data.
2.3. Arbitrary Data in the DNS
Since URI encoding has ways of carrying basically arbitrary data,
resolving a NAPTR record might result in an output other than an
identifier which would subsequently be resolved to IP addresses and
contacted for a particular application - it could give a literal
result consumed by the application. Originally, in [RFC2168], the
intended applicability of the regular expression field in NAPTR was
much more narrow: the regexp field contained a "substitution
expression that is applied to the original URI in order to construct
the next domain name to lookup," in order "change the host that is
contacted to resolve a URI" or as a way of "changing the path or host
once the URL has been assigned." The regular express tools available
to NAPTR record authors, however, grant much broader powers to alter
the input string, and thus applications began to rely on NAPTR to
perform more radical transformations. By [RFC3402], the output of
DDDS is wholly application-specific: "the Application must determine
what the expected output of the Terminal Rule should be," and the
example given in the document is one of identifying automobile parts
by inputting a part number is receiving at the end of the process
receiving information about the manufacturer (though this example
reflects that the DNS is only one database to which the DDDS
framework might apply).
NAPTR did not however pioneer the storage of arbitrary data in the
DNS. At the start, [RFC0882] observed that "it is unlikely that all
users of domain names will be able to agree on the set of resources
or resource information that names will be used to retrieve," and
Kolkman, et al. Expires May 3, 2012 [Page 9]
Internet-Draft Applications in DNS October 2011
consequently places little restriction on the information that DNS
records might carry: it might be "host addresses, mailbox data, and
other as yet undetermined information." [RFC1035] defined the TXT
record, a means to store arbitrary strings in the DNS; [RFC1034]
specifically stipulates that a TXT contains "descriptive text" and
that "the semantics of the text depends on the domain where it is
found." The existence of TXT records has long provided new
applications with a rapid way of storing data associated with a
domain name in the DNS, as adding data in this fashion require no
registration process. [RFC1464] added a means of incorporating name/
value pairs to the TXT record structure, which allowed applications
to differentiate different chunks of data stored in a TXT record. In
this fashion, an application that wants to store additional data in
the DNS can do so without registering a new resource record type -
though [RFC5507] points out that it is "difficult to reliably
distinguish one application's record from otters, and for its parser
to avoid problems when it encounters other TXT records."
While open policies surrounding the use of the TXT record have
resulted in a checkered past for standardizing application usage of
TXT, TXT has been used as a technical solution for DKIM [RFC4871] to
store necessary information about the security of email in DNS,
though within a narrow naming convention (records stored under
"_domainkey" subdomains). Storing keys in the DNS became the
preferred solution for DKIM for several reasons: notably, because the
public keys associated with email required wide public distribution,
and because email identifiers contain a domain component that
applications can easily use to consult the DNS. If the application
had to negotiate support for the DKIM mechanism with mail servers, it
would give rise to bid-down attacks (where attackers misrepresent
that DKIM is unsupported in the domain) that are not possible if the
DNS delivers the keys (provided that DNSSEC [RFC4033] guarantees
authenticity of the data). However, there are potential issues with
story large data in the DNS, as discussed in Section 3.2.1.
Kolkman, et al. Expires May 3, 2012 [Page 10]
Internet-Draft Applications in DNS October 2011
3. Challenges for the DNS
The methods discussed in the previous section for transforming
arbitrary identifiers into domain names, and for returning arbitrary
data in response to DNS queries, both represent significant
departures from the basic function of translating host names to IP
addresses, yet neither fundamentally alters the underlying semantics
of the DNS. When we consider, however, that the URIs returned by
DDDS might be base 64 encoded binary data in the data URL [RFC2397],
the DNS could effectively implement the entire application feature
set of any simple query-response protocol. Effectively, the DDDS
framework overlays the DNS with a generic database - indeed, the DDDS
framework was designed to work with any sort of underlying database;
as [RFC3403] shows, the DNS is only one potential database for DDDS
to use. Whether the DNS as an underlying database can support the
features that some applications of DDDS require, however, is a more
complicated question.
As the following subsections will show, the potential that
applications might rely on the DNS as a generic database gives rise
to additional requirements that one might expect to find in a
database access protocol: authentication of the source of queries for
comparison to access control lists, formulating complex relational
queries, and asking questions about the structure of the database
itself. DNS was not designed to provide these sorts of properties,
and extending the DNS to encompass them would represent a fundamental
alteration to its model. Ultimately, this document concludes that
efforts to retrofit these capabilities into the DNS would be better
invested in selecting, or if necessary inventing, other Internet
services with broader powers than the DNS. If an application
protocol designer wants these properties from a database, in general
this is a good indication that the DNS cannot meet the needs of the
application in question.
Since many of these new requirements have emerged from the ENUM
space, the following sections use ENUM as an illustrative example;
however, any application using the DNS as a feature-rich database
could easily end up with similar requirements.
3.1. Compound Queries
Traditionally, the DNS requires resolvers to supply no information
other than the domain name, the type and the class of records sought
in order to receive a reply from an authoritative server. Outside of
the DNS space, however, there are plenty of query-response
applications that require a compound or relational search, which
takes into account more than one factor in formulating a response or
uses no single factor as a key to the database. For example, in the
Kolkman, et al. Expires May 3, 2012 [Page 11]
Internet-Draft Applications in DNS October 2011
telephony space, telephone call routing often takes into account
numerous factors aside from the dialed number, including originating
trunk groups, interexchange carrier selection, number portability
data, time of day, and so on. All are considered simultaneously in
generating a route. While in its original conception, ENUM hoped to
circumvent the traditional PSTN and route directly to Internet-
enabled devices, the infrastructure ENUM effort to support the
migration of traditional carrier routing functions to the Internet
aspires to achieve feature parity with traditional number routing.
However, [RFC3402] explicitly states that "it is an assumption of the
DDDS that the lexical element used to make a delegation decision is
simple enough to be contained within the Application Unique String
itself. The DDDS does not solve the case where a delegation decision
is made using knowledge contained outside the AUS and the Rule (time
of day, financial transactions, rights management, etc.)."
Consequently, some consideration has been given to ways to add
additional data to ENUM queries to give the DNS server sufficient
information to return a suitable URI (see Section 3.1.1).
From a sheer syntactical perspective, however, domain names do not
admit of this sort of rich structure. Several workarounds have
attempted to instantiate these sorts of features in DNS queries.
Most commonly, proposals piggyback additional query parameters as
EDNS0 extensions (see [RFC2671]); alternatively, the domain name
itself could be compounded with the additional parameters: one could
take a name like 0.0.4.5.4.3.4.1.7.5.1.e164.arpa and append a trunk
group identifier to it, for example, of the form
tg011.0.0.4.5.4.3.4.1.7.5.1.e164.arpa. While in the latter case, a
DNS server can adhere to its traditional behavior in locating
resource records, the syntactical viability of encoding additional
parameters in this fashion is very dubious, especially if more than
one additional parameter is required and the presence of parameters
is optional. The former EDNS0 case requires significant changes to
name server behavior. The intended applicability of the EDNS0
mechanism, as the [RFC2761] states, is to "a particular transport
level message and not to any actual DNS data," and consequently the
OPT Resource Records it specifies are never to be forwarded; the use
of EDNS0 for compound queries, however, clearly is intended to
discriminate actual DNS data rather than to facilitate transport-
layer handling. [RFC2761] also specifies that only one OPT pseudo-
Resource Record can appear in a single request, so the use of this
mechanism can only compound a query by a single field. For these
reasons, this draft recommends against the use of eDNS0 as a
mechanism for crafting compound DNS queries.
Moreover, the implications of these sorts of compound queries for
recursion and caching are potentially serious. The logic used by the
authoritative server to respond to a compound query may not be
Kolkman, et al. Expires May 3, 2012 [Page 12]
Internet-Draft Applications in DNS October 2011
understood by any recursive servers or caches; intermediaries that
naively assume that the response was selected based on the domain
name, type and class alone might serve responses to queries in a
different way than the authoritative server intends. Even
comparatively unambiguous expressions of server preference like the
time-to-live parameter are not always honored by caches.
3.1.1. Responses Tailored to the Originator
The most important subcase of the compound queries are DNS responses
tailored to the identity of their originator, where some sort of
administrative identity of the originator must be conveyed to the
DNS. We must first distinguish this from cases where the originating
IP address or a similar indication is used to serve a location-
specific name. For those sorts of applications, which generally lack
security implications, relying on factors like the source IP address
introduces little harm for example, when providing a web portal
customized to the region of the client, it would not be a security
breech if the client saw the localized portal of the wrong country.
Because recursive resolvers may obscure the origination network of
the DNS client, a recent proposal suggested introducing a new DNS
query parameter to be populated by DNS recursive resolvers in order
to preserve the originating IP address (see
[I-D.vandergaast-edns-client-ip]). However, aside from purely
cosmetic uses, these approaches have known limitations due to the
prevalence of private IP addresses, VPNs and so on which obscure the
source IP address and instead supply the IP address of an
intermediary that may be very distant from the originating endpoint.
Implementing vandergaast does require significant changes in the
operation of recursive resolvers and the authoritative servers that
would rely on the original source IP address to select Resource
Records, and moreover a fundamental change to caching behavior as
well.
In other deployments in use today, including those based on the BIND
"views" feature, the source IP address is used to grant access to a
private set of resource records. The security implications of
trusting the source IP address of a DNS query have prevented most
solutions along these lines from being standardized (see [RFC6269]),
though the practice remains widespread in "split horizon" private DNS
deployment (see Section 4) which typically rely on an underlying
security layer, such as a physical network or an IPsec VPN, to
prevent spoofing of the source IP address. These deployments do have
a confidentiality requirement to prevent information intended for a
constrained audience (internal to an enterprise, for example) from
leaking to the public Internet -- while these internal network
resources may use private IP addresses which would not be useful on
the public Internet anyway, in some cases this leakage would reveal
Kolkman, et al. Expires May 3, 2012 [Page 13]
Internet-Draft Applications in DNS October 2011
topology or other information that the name server provisioner hopes
to keep private.
These first two cases, regardless of their acceptance by the
standards community, have widespread acceptance in the field. Some
applications, however, go even further and propose extending the DNS
to add an application-layer identifier of the originator rather than
an IP address; for example,
[I-D.kaplan-dnsext-enum-sip-source-ref-opt-code] provides a SIP URI
in an eDNS0 parameter (though without any specific provision for
cryptographically verifying the claimed identity). Effectively, the
conveyance of application-layer information about the administrative
identity of the originator through the DNS is a weak authentication
mechanism, on the basis of which the DNS server makes an
authorization decision before sharing resource records. This can
parlay into a per-Resource Record confidentiality mechanism, where
only a specific set of originators are permitted to see resource
records, or a case where a query for the same name by different
entities results in completely different resource record sets. The
DNS, however, substantially lacks the protocol semantics to manage
access control lists for data, and again, caching and recursion
introduce significant challenges for applications that attempt to
offload this responsibility to the DNS. Achieving feature parity
with even the simplest authentication mechanisms available at the
application layer would like require significant rearchitecture of
the DNS.
3.2. Using DNS as a Generic Database
As previously noted, the use of the First Well Known Rule of DDDS
combined with data URLs (or potentially TXT records) effectively
allows the DNS to answer queries for arbitrary strings and to return
arbitrary data as a value. Some query-response applications,
however, require queries and responses that simply fall outside the
syntactic capabilities of the DNS. Domain names themselves must
conform to certain syntactic constraints: they must consist of labels
that do not exceed 63 characters while the total length of the
encoded name may not exceed 255 octets, they must obey fairly strict
encoding rules, and so on. The DNS therefore cannot be a completely
generic database. Similar concerns apply to the size of DNS
responses.
3.2.1. Large Data in the DNS
While the data URL specification [RFC2397] notes that it is "only
useful for short values," unfortunately it gives no particular
guidance about what "short" might mean. Many applications today use
quite large data URLs (containing a megabyte or more of data) as
Kolkman, et al. Expires May 3, 2012 [Page 14]
Internet-Draft Applications in DNS October 2011
workarounds in environments where only URIs can syntactically appear.
The meaning of "short" in an application context is probably very
different from how we should understand it in a DNS message.
Referring to a typical public DNS deployment, [RFC5507] observes that
"there's a strong incentive to keep DNS messages short enough to fit
in a UDP datagram, preferably a UDP datagram short enough not to
require IP fragmentation," which entails a maximum size of 512
octets. While the use of TCP and eDNS0 allows DNS responses to be
quite long, this requires stateful operation of servers which can be
costly in deployments where servers have only fleeting connections to
many clients. Ultimately, there are forms of data that an
application might store in the DNS that exceed reasonable limits: in
the ENUM context, for example, something like storing base 64 encoded
mp3 files of custom ringtones.
Designs relying on storage of large amounts of data within DNS RRs
furthermore need to minimize the potential damage achievable in a
reflection attack (see [RFC4732], Section 3), in which the attacker
sends DNS queries with a forged source address, and the victim
receives the response. By generating a large response to a small
query, the attacker can magnify the bandwidth directed at the victim.
Where the responder supports EDNS0, an attacker may set the requester
maximum payload size to a larger value while querying for a large
Resource Record, such as a certificate [RFC4398]. Thus the
combination of large data stored in DNS RRs and responders supporting
large payload sizes has the potential to increase the potential
damage achievable in a reflection attack. Since a reflection attack
can be launched from any network that does not implement source
address validation, these attacks are difficult to eliminate absent
the ubiquitous deployment of source address validation. 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.
Since it is difficult to complete a TCP three-way handshake begun
from a forged source address, DNS reflection attacks utilize UDP
queries. Unless the attacker uses EDNS0 [RFC2671] to enlarge the
requester's maximum payload size, a response can only reach 576
octets before the truncate bit is set in the response. This limits
the maximum magnification achievable from a DNS query that does not
Kolkman, et al. Expires May 3, 2012 [Page 15]
Internet-Draft Applications in DNS October 2011
utilize EDNS0. As the large disparity between the size of a query
and size of the response creates this amplification, implementations
should limit EDNS0 responses to a specific ratio compared to the
request size. The precise ratio can be configured on a per-
deployment basis, but without this limitation, EDNS0 can cause
significant harm.
3.3. Administrative Structures Misaligned with the DNS
While the DDDS framework enables any sort of alphanumeric data to
serve as a DNS name through the application of the First Well Known
Rule, the delegative structure of the resulting DNS name may not
reflect the division of responsibilities for the resources that the
alphanumeric data indicates. While [RFC3402] requires only that
"Application Unique String has some kind of regular, lexical
structure that the rules can be applied to," DDDS is first and
foremost a delegation system: its abstract stipulates that "Well-
formed transformation rules will reflect the delegation of management
of information associated with the string." Telephone numbers in the
United States, for example, are assigned and delegated in a
relatively complex manner. Historically, the first six digits of a
nationally specific number (called the "NPA/NXX") reflected a point
of administrative delegation from the number assignment agency to a
carrier; from these blocks of ten thousand numbers, the carrier would
in turn delegate individual assignments of the last four digits (the
"XXXX" portion) to particular customers. However, after the rise of
North American telephone number portability in the 1990s, the first
point of delegation went away: the delegation is effectively from the
number authority to the carrier for each the complete ten-digit
number (NPA/NXX-XXXX). While technical implementation details differ
from nation to nation, number portability systems with similar
administrative delegations now exist worldwide.
To render these identifiers as domain names in accordance with the
DDDS Rule for ENUM yields a large flat zone with no points of
administrative delegation (or zone cuts) from the country-code
administrator, e.g. 1.e164.arpa, down to the ultimately assignee of a
number. The scalability difficulties of maintaining a single DNS
zone with potentially over five billion names in it manifest in a
number of areas (in practice, there are closer to 300M allocated
telephone numbers in the United States today, but that is still more
than three times the number of .com domain names). The scalability
that results from caching depends on points of delegation so that
cached results for intermediate servers take the load off higher tier
servers. If there are no such delegations, then as in the telephone
number example the zone apex server must bear the entire load for
queries. Worse still, number portability also introduces far more
dynamism in number assignment, where in some regions updated
Kolkman, et al. Expires May 3, 2012 [Page 16]
Internet-Draft Applications in DNS October 2011
assignees for ported numbers must propagate within fifteen minutes of
a change in administration. Jointly, these two problems cacheing the
zone extremely problematic. Moreover, traditional tools for DNS
replication, such as the zone transfer protocol AXFR [RFC1034] and
IXFR [RFC1995], are not designed to accommodate zones with these
dimensions and properties. When traditional DNS management tools no
longer apply to the structures that an application tries to provision
in the DNS, this is another clue that the DNS might not be the right
place for an application to store its data.
DDDS provides a capability that transforms arbitrary strings into
domain names, but those names play well with the DNS only when the
input string have an administrative structure that maps on DNS
delegations. In the first place, delegation implies some sort of
hierarchical structure. Any mechanism to map a hierarchical
identifier into a DNS name should be constructed such that the
resulting DNS name does match the natural hierarchy of the original
identifier. Although telephone numbers, even in North America, have
some hierarchical qualities (like the geographical areas
corresponding to their first three digits), after the implementation
of number portability these points no longer mapped onto an
administrative delegation. If the input string to the DDDS does not
have a hierarchical structure representing administrative delegations
that can map onto the DNS distribution system, that string probably
is not a good candidate for translating into a domain name.
The difficulty of mapping the DNS to administrative structures can
even occur with traditional domain names, where applications expect
clients to infer or locate zone cuts. In the web context, for
example, it can be difficult for applications to determine whether
two domain names represent the same "site" when
3.3.1. Metadata about Tree Structure
There are also other ways in which the delegative structure of an
identifier may not map well onto the DNS. Traditionally, DNS
resolvers assume that when they receive a domain name from an
application, that the name is complete - that it is not a fragment of
a DNS name that a user is still in the middle of typing. For some
communications systems, however, this assumption does not apply.
ENUM use cases have surfaced a couple of optimization requirements to
reduce unnecessary calls and queries by including metadata in the DNS
that describes the contents and structure of ENUM DNS trees to help
applications to handle incomplete queries or queries for domains not
in use. In particular, the "send-n" proposal
[I-D.bellis-enum-send-n] hopes to reduce the number of DNS queries
sent in regions with variable-length numbering plans. When a dialed
number potentially has a variable length, a telephone switch
Kolkman, et al. Expires May 3, 2012 [Page 17]
Internet-Draft Applications in DNS October 2011
ordinarily cannot anticipate when a dialed number is complete, as
only the numbering plan administrator (who may be a national
regulator, or even in open number plans a private branch exchange)
knows how long a telephone number needs to be. Consequently, a
switch trying to resolve such a number through a system like ENUM
might send a query for a telephone number that has only partially
been dialed in order to test its completeness. The "send-n" proposal
installs in the DNS a hint informing the telephone switch of the
minimum number of digits that must be collected by placing in zones
corresponding to incomplete telephone numbers some Resource Records
which state how many more digits are required - effectively how many
steps down the DNS tree one must take before querying the DNS again.
Unsurprisingly, those boundaries reflect points of administrative
delegation, where the parent in a number plan yields authority to a
child. With this information, the application is not required to
query the DNS every time a new digit is dialed, but can wait to
collect sufficient digits to receive a response. As an optimization,
this practice thus saves the resources of the DNS server - though the
call cannot complete until all digits are collected, so at best this
mechanism only reduces the time the system will wait before sending
an ENUM query after collecting the final dialed digit. A
tangentially related proposal, [I-D.ietf-enum-unused], similarly
places resource records in the DNS that tell the application that it
need not attempt to reach a number on the telephone network, as the
number is unassigned - a comparable general DNS mechanism would
identify, for a domain name with no heather or not the domain had
been allocated to an owner.
Both proposals optimize application behavior by placing metadata in
the DNS that predicts the success of future queries or application
invocation by identifying points of administrative delegation or
assignment in the tree. In some respects, marking a point in the
tree where a zone begins or end has some features in common with the
traditional parent zone use of the NS record type, except instead of
pointing to a child zone, these metadata proposals point to distant
grandchildren. While this does not change resolver behavior as such
(instead, it changes the way that applications invoke the resolver),
it does have implications for the practices for zone administrators.
Metadata in the authoritative server 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.
Who gets to supply records for unassigned names? While in the
original but little-used "golden" root model of ENUM, this would
almost certainly be a numbering plan administrator, it is far less
clear who that would be in the more common and successful
Kolkman, et al. Expires May 3, 2012 [Page 18]
Internet-Draft Applications in DNS October 2011
"infrastructure" ENUM models (see Section 4). Ultimately, these
metadata proposals share some qualities with DNS redirection services
offered by ISPs (for example, [I-D.livingood-dns-redirect]) which
"help" web users who try to browser to sites that do not exist -
though in those cases, at least the existence or non-existence of a
domain name is a fact about the Internet, rather than about an
external network like the telephone system which must be synchronized
with the DNS tree in the metadata proposals. In send-n, different
leaf zones, who administer telephone numbers of different lengths,
can only provision their hints at their own apex, which provides an
imperfect optimization: they cannot install it in a parent, both
because they lack the authority and because different zones would
want to provision contradictory data. An application protocol
designer who wants to manage identifiers whose administrative model
does not map well onto the DNS would be better served to implement
such features outside the DNS.
3.4. Domain Redirection
Most Internet application services provide a redirection feature -
when you attempt to contact a service, the service may refer you to a
different service instance, potentially in another domain, that is
for whatever reason better suited to address a request. In HTTP and
SIP, for example, this feature is implemented by the 300 class
responses containing one or more better URIs that may indicate that a
resource has moved temporarily or permanently to another service.
Several tools in the DNS, including the SRV record, can provide a
similar feature at a DNS level, and consequently some applications as
an optimization offload the responsibility for redirection to the
DNS; NAPTR can also provide this capability on a per-application
basis, and numerous DNS resource records can provide redirection on a
per-domain basis. This can prevent the unnecessary expenditure of
application resources on a function that could be performed as a
component of a DNS lookup that is already a prerequisite for
contacting the service. Consequently, in some deployment
architectures this DNS-layer redirection is used for virtual hosting
services.
Implementing domain redirection in the DNS, however, has important
consequences for application security. In the absence of universal
DNSSEC, applications must blindly trust that their request has not
been hijacked at the DNS layer and redirected to a potentially
malicious domain, unless some subsequent application mechanism can
provide the necessary assurance. By way of contrast, application-
layer redirections protocols like HTTP and SIP have 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.
Kolkman, et al. Expires May 3, 2012 [Page 19]
Internet-Draft Applications in DNS October 2011
A number of applications have attempted to provide an after-the-fact
security mechanism that verifies the authority of a DNS delegation in
the absence of DNSSEC. The specification for dereferencing SIP URIs
([RFC3263], reaffirmed in [RFC5922]), requires that during TLS
establishment, the site eventually reached by a SIP request present a
certificate corresponding to the original URI expected by the user
(in other words, if example.com redirects to example.net in the DNS,
this mechanism expects that example.net will supply a certificate for
example.com in TLS, per the HTTP precedent in [RFC2818]), which
requires a virtual hosting service to possess a certificate
corresponding to the hosted domain. This restriction rules out many
styles of hosting deployments common in the web world today, however.
[I-D.barnes-hard-problem] explores this problem space, and
[I-D.saintandre-tls-server-id-check] proposes a solution for all
applications that use TLS. Potentially, new types of certificates
(similar to [RFC4985]) might bridge this gap, but support for those
certificates would require changes to existing certificate authority
practices as well as application behavior.
All of these application-layer measures attempt to mirror the
delegation of authority in the DNS, when the DNS itself serves as the
ultimate authority on how domains are delegated. Synchronizing a
static instrument like a certificate with a delegation in the DNS,
however, is problematic because delegations are not static: revoking
and reissuing a certificate every time a delegation changes is
cumbersome operationally. In environments where DNSSEC is not
available, the problems with securing DNS-layer redirections would be
avoided by performing redirections in the application-layer.
Kolkman, et al. Expires May 3, 2012 [Page 20]
Internet-Draft Applications in DNS October 2011
4. Private DNS and Split Horizon
The classic view of the uniqueness of DNS names is given in
[RFC2826]:
DNS names are designed to be globally unique, that is, for any
one DNS name at any one time there must be a single set of DNS
records uniquely describing protocol addresses, network resources and
services associated with that DNS name. All of the applications
deployed on the Internet which use the DNS assume this, and Internet
users expect such behavior from DNS names.
However, [RFC2826] "does not preclude private networks from operating
their own private name spaces," but notes that if private networks
"wish to make use of names uniquely defined for the global Internet,
they have to fetch that information from the global DNS naming
hierarchy." There are various DNS deployments outside of the global
public DNS, including "split horizon" deployments and DNS usages on
private (or virtual private) networks. In a split horizon, an
authoritative server gives different responses to queries from the
public Internet than they do to internal resolvers; as they typically
differentiate internal from public queries by the source IP address,
the concerns in Section 3.1.1 apply to such deployments. When the
internal address space range is private [RFC1918], this both makes it
easier for the server to discriminate public from private and harder
for public entities to impersonate nodes in the internal network.
Networks that are made private physically, or logically by
cryptographic tunnels, make these private deployments more secure.
The most complex deployments along these lines use multiple virtual
private networks to serve different answers for the same name to many
networks.
The use cases that motivate split horizon DNS typically involve
restricting access to some network services - intranet resources like
internal web site, development servers or directories, for example -
while preserving the ease of use offered by domain names for internal
users. While for many of these resources, the split horizon would
not return answers to public resolvers for those internal resources
(those records are kept confidential from the public), in some cases,
the same name (e.g., "mail.example.com") might resolve to one host
internally but another externally. The requirements for multiple-VPN
private deployments, however, are different: in this case the
authoritative server gives different, and confidential, answers to a
set of resolvers querying for the same name. While these sorts of
use cases rarely arise for traditional domain names, where, as
[RFC2826] says, users and applications expect a unique resolution for
a name, they can easily arise when other sorts of identifiers have
been translated by a mechanism like DDDS into "domain name syntax."
Kolkman, et al. Expires May 3, 2012 [Page 21]
Internet-Draft Applications in DNS October 2011
Telephone calls, for example, are traditionally routed through highly
mediated networks, and an attempt to find a route for a call often
requires finding an appropriate intermediary based on the source
network and location rather than finding an endpoint (see the
distinction between the Look-Up Function and Location Routing
Function in [RFC5486]). Moreover, the need for selective responses
and confidentially is easily motivated when the data returned by the
DNS is no longer "describing protocol addresses, network resources
and services," but instead arbitrary data. Although ENUM was
originally intended for deployment in the global public root of the
DNS (under e164.arpa), for example, the requirements of maintaining
telephone identifiers in the DNS quickly steered operators into
private deployments.
In private environments, it is also easier to deploy any necessary
extensions than it is in the public DNS: in the first place,
proprietary non-standard extensions and parameters can easily be
integrated into DNS queries or responses as the implementations of
resolvers and servers can likely be controlled; secondly,
confidentiality and custom responses can be provided by deploying,
respectively, underlying physical or virtual private networks to
shield the private tree from public queries, and effectively
different virtual DNS trees for each administrative entity that might
launch a query; thirdly, in these constrained environments, caching
and recursive resolvers can be managed or eliminated in order to
prevent any unexpected intermediary behavior. While these private
deployments serve an important role in the marketplace, there are
risks in using techniques intended only for deployment in private and
constrained environments as the basis of a standard solution. When
proprietary parameters or extensions are deployed in these private
environments, experience teaches us that these implementations will
begin to interact with the public DNS, and that the private practices
will leak. The history of SIP, for example, was full of supposedly
private extensions (notably the "P-" headers) which saw widespread
success and use outside of the constrained environments for which
they were specifically designed. Therefore, keeping these features
within higher-layer applications rather than offloading them to the
DNS is preferred.
Kolkman, et al. Expires May 3, 2012 [Page 22]
Internet-Draft Applications in DNS October 2011
5. Principles and Guidance
The success of the DNS relies on the fact that it is a distributed
database, one that has the property that it is loosely coherent and
that it offers lookup instead of search functionality. Loose
coherency means that answers to queries are coherent within the
bounds of data replication between authoritative servers and caching
behavior by recursive name servers. It is critical that application
designers who intend to use the DNS to support their applications
consider the implications that their uses have for the behavior of
resolvers, intermediaries including caches and recursive resolvers,
and authoritative servers.
It is likely that the DNS provides a good match whenever applications
needs are aligned with the following properties:
Data stored in the DNS can be propagated and cached using
conventional DNS mechanisms, without intermediaries needing to
understand exceptional logic (considerations beyond the name, type
and class of the query) used by the authoritative server to
formulate responses
Data stored in the DNS is indexed by keys that do not violate the
syntax or semantics of domain names
Applications invoke the DNS to resolve complete names, not
fragments
Answers do not depend on an application-layer identity of the
entity doing the query
Ultimately, applications invoke the DNS to assist in communicating
with the domain of the name they are resolving
Whenever one of the four properties above does not apply to one's
data, one should seriously consider whether the DNS is the best place
to store actual data. On the other hand, good indicators that the
DNS is not the appropriate tool for solving problems is when you have
to worry about:
Populating metadata about domain boundaries within the tree - the
points of administrative delegation in the DNS are something that
applications should in general not be aware off
Domain names derived from identifiers that do not share a
semantics or administrative model compatible with the DNS
Kolkman, et al. Expires May 3, 2012 [Page 23]
Internet-Draft Applications in DNS October 2011
Selective confidentiality of data stored in and provided by the
DNS
DNS responses not fitting into UDP packets, unless EDNS0 is
available, and only then with the caveats discussed above
In cases where applications require these sorts of features, they are
simply better instantiated by independent application-layer protocols
than the DNS. The query-response semantics of the DNS are similar to
HTTP, for example, and the objects which HTTP can carry both in
queries and responses can easily contain the necessary structure to
manage compound queries. Many applications already use HTTP because
of widespread support for it in middleboxes. Similarly, HTTP has
numerous ways to provide the necessary authentication, authorization
and confidentiality properties that some features require, as well as
the redirection properties discussed in Section 3.4. The overhead of
using HTTP may not be appropriate for all environments, but even in
environments where a more lightweight protocol is appropriate, DNS is
not the only alternative.
Where the administrative delegations of the DNS form a necessary
component in the instantiation of an application feature, there are
various ways that the DNS can bootstrap access to an independent
application-layer protocol better suited to field the queries in
question. For example, since NAPTR or URI resource
[I-D.faltstrom-uri] records can contain URIs, those URIs can in turn
point to an external query-response service such as HTTP where more
syntactically and semantically rich queries and answers might be
exchanged.
Kolkman, et al. Expires May 3, 2012 [Page 24]
Internet-Draft Applications in DNS October 2011
6. Security Considerations
Many of the concerns about how applications use the DNS discussed in
this document involve security. The perceived need to authenticate
the source of DNS queries (see Section 3.1.1) and authorize access to
particular resource records also illustrates the fundamental security
principles that arise from offloading certain application features to
the DNS. As Section 3.2.1 observes, large data in the DNS can
provide a means of generating reflection attacks, and without the
remedies discussed in that section (especially the use of EDNS0 and
TCP) the presence of large records is not recommended. Section 3.4
discusses a security problem concerning redirection that has surfaced
in a number of protocols (see [I-D.barnes-hard-problem]).
While DNSSEC, were it deployed universally, can play an important
part in securing application redirection in the DNS, DNSSEC does not
provide a means for a resolver to authenticate itself to a server,
nor a framework for servers to return selective answers based on the
authenticated identity of resolvers. The existing feature set of
DNSSEC is however sufficient for providing security for most of the
ways that applications traditionally have used the DNS. Nothing in
this document is intended to discourage either the implementation,
deployment, or use of Secure DNS Dynamic Updates ([RFC2136],
[RFC3007]) to the DNS system, DNS Security ([RFC4033] and related
specifications), or the use of Secure DNS Dynamic Updates in
combination with DNS Security.
Kolkman, et al. Expires May 3, 2012 [Page 25]
Internet-Draft Applications in DNS October 2011
7. IANA Considerations
This document contains no considerations for the IANA.
Kolkman, et al. Expires May 3, 2012 [Page 26]
Internet-Draft Applications in DNS October 2011
8. IAB Members
Internet Architecture Board Members at the time this document was
published were:
[TO BE INSERTED]
Kolkman, et al. Expires May 3, 2012 [Page 27]
Internet-Draft Applications in DNS October 2011
9. Acknowledgements
The IAB appreciates the comments and often spirited disagreements of
Ed Lewis, Dave Crocker, Ray Bellis, Lawrence Conroy, Ran Atkinson,
Patrik Faltstrom and Eliot Lear.
Kolkman, et al. Expires May 3, 2012 [Page 28]
Internet-Draft Applications in DNS October 2011
10. Informative References
[I-D.barnes-hard-problem]
Barnes, R. and P. Saint-Andre, "High Assurance Re-
Direction (HARD) Problem Statement",
draft-barnes-hard-problem-00 (work in progress),
July 2010.
[I-D.bellis-enum-send-n]
Bellis, R., "IANA Registrations for the 'Send-N'
Enumservice", draft-bellis-enum-send-n-02 (work in
progress), June 2008.
[I-D.faltstrom-uri]
Faltstrom, P. and O. Kolkman, "The Uniform Resource
Identifier (URI) DNS Resource Record",
draft-faltstrom-uri-06 (work in progress), October 2010.
[I-D.ietf-enum-unused]
Stastny, R., Conroy, L., and J. Reid, "IANA Registration
for Enumservice UNUSED", draft-ietf-enum-unused-04 (work
in progress), March 2008.
[I-D.kaplan-dnsext-enum-sip-source-ref-opt-code]
Kaplan, H., Walter, R., Gorman, P., and M. Maharishi,
"EDNS Option Code for SIP and PSTN Source Reference Info",
draft-kaplan-dnsext-enum-sip-source-ref-opt-code-03 (work
in progress), October 2011.
[I-D.livingood-dns-redirect]
Creighton, T., Griffiths, C., Livingood, J., and R. Weber,
"DNS Redirect Use by Service Providers",
draft-livingood-dns-redirect-03 (work in progress),
October 2010.
[I-D.saintandre-tls-server-id-check]
Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity
in Certificates Used with Transport Layer Security",
draft-saintandre-tls-server-id-check-09 (work in
progress), August 2010.
[I-D.vandergaast-edns-client-ip]
Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
"Client IP information in DNS requests",
draft-vandergaast-edns-client-ip-01 (work in progress),
May 2010.
Kolkman, et al. Expires May 3, 2012 [Page 29]
Internet-Draft Applications in DNS October 2011
[RFC0882] Mockapetris, P., "Domain names: Concepts and facilities",
RFC 882, November 1983.
[RFC0974] Partridge, C., "Mail routing and the domain system",
RFC 974, January 1986.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1464] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993.
[RFC1530] Malamud, C. and M. Rose, "Principles of Operation for the
TPC.INT Subdomain: General Principles and Policy",
RFC 1530, October 1993.
[RFC1794] Brisco, T., "DNS Support for Load Balancing", RFC 1794,
April 1995.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC1995] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995,
August 1996.
[RFC2052] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the
location of services (DNS SRV)", RFC 2052, October 1996.
[RFC2136] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound,
"Dynamic Updates in the Domain Name System (DNS UPDATE)",
RFC 2136, April 1997.
[RFC2168] Daniel, R. and M. Mealling, "Resolution of Uniform
Resource Identifiers using the Domain Name System",
RFC 2168, June 1997.
[RFC2397] Masinter, L., "The "data" URL scheme", RFC 2397,
August 1998.
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)",
RFC 2671, August 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Kolkman, et al. Expires May 3, 2012 [Page 30]
Internet-Draft Applications in DNS October 2011
[RFC2826] Internet Architecture Board, "IAB Technical Comment on the
Unique DNS Root", RFC 2826, May 2000.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000.
[RFC2916] Faltstrom, P., "E.164 number and DNS", RFC 2916,
September 2000.
[RFC3007] Wellington, B., "Secure Domain Name System (DNS) Dynamic
Update", RFC 3007, November 2000.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3401] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm", RFC 3402, October 2002.
[RFC3403] Mealling, M., "Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database",
RFC 3403, October 2002.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005.
[RFC4366] Blake-Wilson, S., Nystrom, M., Hopwood, D., Mikkelsen, J.,
and T. Wright, "Transport Layer Security (TLS)
Extensions", RFC 4366, April 2006.
[RFC4367] Rosenberg, J. and IAB, "What's in a Name: False
Assumptions about DNS Names", RFC 4367, February 2006.
[RFC4732] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006.
Kolkman, et al. Expires May 3, 2012 [Page 31]
Internet-Draft Applications in DNS October 2011
[RFC4871] Allman, E., Callas, J., Delany, M., Libbey, M., Fenton,
J., and M. Thomas, "DomainKeys Identified Mail (DKIM)
Signatures", RFC 4871, May 2007.
[RFC4985] Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007.
[RFC5486] Malas, D. and D. Meyer, "Session Peering for Multimedia
Interconnect (SPEERMINT) Terminology", RFC 5486,
March 2009.
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design
Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5922] Gurbani, V., Lawrence, S., and A. Jeffrey, "Domain
Certificates in the Session Initiation Protocol (SIP)",
RFC 5922, June 2010.
[RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P.
Roberts, "Issues with IP Address Sharing", RFC 6269,
June 2011.
Kolkman, et al. Expires May 3, 2012 [Page 32]
Internet-Draft Applications in DNS October 2011
Authors' Addresses
Olaf Kolkman
NLNet
Email: olaf@nlnetlabs.nl
Jon Peterson
NeuStar, Inc.
Email: jon.peterson@neustar.biz
Hannes Tschofenig
Nokia Siemens Networks
Email: Hannes.Tschofenig@gmx.net
Bernard Aboba
Microsoft Corporation
Email: bernarda@microsoft.com
Kolkman, et al. Expires May 3, 2012 [Page 33]