Review of: Architectural Considerations on Application Features in
the DNS
I-D: draft-iab-dns-applications-07
Reviewed by: D. Crocker
Review date: 15 March 2013
Summary:
This review follows the one I provided for the -01 draft, on 20
April 2011 and recorded in:
http://trac.tools.ietf.org/group/iab/trac/ticket/35
I recently received a note closing the ticket, with an extended
commentary (contained in the above ticket citation). It asserted that
the concerns of the previous review have been resolved.
The current review was a fresh re-reading of the document.
The current Abstract declares the purpose of the document to be:
This document explores the architectural
consequences of using the DNS to implement certain application
features, and provides guidance to future application designers as to
the limitations of the DNS as a substrate and the situations in which
alternative designs should be considered.
Alas, the -07 version of the document remains fundamentally flawed
in purpose, basic technical details, and writing style. After two years
and 6 rounds of revision, a document that remains so deeply problematic
needs very different handling than it has been getting.
For the Detailed Comments section of a review, I normally delete any
extended passages that have no comments. Given the extent of problems
with this document, I'm leaving in all the text, to ensure proper
context for the comments.
I terminated the review on page 11. It simply is not productive to
provide more detailed review, as I believe the included comments will
make abundantly clear.
My best guess is that the only way to bring this document to a level
of reasonable competence is to start over, with much, much greater care,
starting with much greater clarity about the document's purpose and how
to achieve it.
Detailed Comments:
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; some for example transform identifiers
other than domain names into formats that the DNS can process, and
then fetch application data or service location data from the DNS.
The text after the semi-colon is completely independent of the DNS. It's
an app function that occurs before the DNS is involved. Given that the
title of the document says "/in/ the DNS" the text actually distracting
to refer to it here.
The phrasing before the semi-colon seems to be trying to say something
distinctive, by virtue of asserting a scope as being "to locate
services" but nothing that follows is really about 'locating'. That
word is a term of art in the IETF and does not refer to a service
provided by the DNS.
In addition, phrasing such as "into formats that the DNS can process" is
clunky, at best, and more likely confusing. If it is meant to mean
"into a domain name" then just say that. If it is meant to mean
something else, I can't even guess what it is. A DNS query is a domain
name. That's a pretty simple, clean and invariable point.
It seems that the text is merely trying to say:
Many applications use the DNS in a context that goes beyond simply
mapping a domain name to an IP Address if a server that supports the
application. Some applications include DNS access to obtain other,
parametric information or as part of a more elaborate location mechanism.
Proposals incorporating sophisticated application behavior using DNS
as a substrate have raised questions about the role of the DNS as an
The proposals have not raised questions; the questions are not /in/ the
proposals. It's possible that you mean that the proposal prompted
others to raise questions. (Yes, I'm hassling you about awkward
sentence construction. The document needs to be very careful about its
assignments of responsibility.)
More generally, this language continues the underlying tone of suspicion
and fear that I noted about the earlier draft.
The document will benefit from simply deleting this sentence. It adds
nothing useful.
application platform. This document explores the architectural
consequences of using the DNS to implement certain application
Actually, it doesn't. It says almost nothing about architectural
consequences. It attempts quite a bit of pedagogy about existing DNS
features, but that's quite a different task.
For the most part, the features discussed in this document are not
'implemented' in the DNS. They are implemented /above/ the DNS. The
document still needs to be significantly more careful with this
distinction. The text explaining the closed tracking ticket item for my
review declared that this distinction was now made in the document; I
still don't see it.
features, and provides guidance to future application designers as to
the limitations of the DNS as a substrate and the situations in which
alternative designs should be considered.
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 . . . . . . . . . . . . . . . . . . . . . . 8
2.3. Arbitrary Data in the DNS . . . . . . . . . . . . . . . . 9
3. Challenges for the DNS . . . . . . . . . . . . . . . . . . . . 12
3.1. Compound Queries . . . . . . . . . . . . . . . . . . . . . 12
3.1.1. Responses Tailored to the Originator . . . . . . . . . 14
3.2. Using DNS as a Generic Database . . . . . . . . . . . . . 16
3.2.1. Large Data in the DNS . . . . . . . . . . . . . . . . 16
3.3. Administrative Structures Misaligned with the DNS . . . . 18
3.3.1. Metadata about Tree Structure . . . . . . . . . . . . 19
3.4. Domain Redirection . . . . . . . . . . . . . . . . . . . . 21
4. Private DNS and Split Horizon . . . . . . . . . . . . . . . . 24
5. Principles and Guidance . . . . . . . . . . . . . . . . . . . 27
6. Security Considerations . . . . . . . . . . . . . . . . . . . 29
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30
8. IAB Members at Time of Approval . . . . . . . . . . . . . . . 31
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32
10. Informative References . . . . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Peterson, et al. Expires August 30, 2013 [Page 3]
Internet-Draft Application Features in DNS February 2013
1. Motivation
The Domain Name System (DNS) has long provided a general means of
translating domain names into Internet Protocol addresses, which
makes the Internet easier to use by providing a valuable layer of
indirection between names and lower-layer protocol elements.
This is oddly phrased. For one thing, it seems to imply that there were
domain names before there was the DNS, which of course is incorrect. I
think you mean to be saying:
The DNS provides a basic mechanism for mapping domain names to
Internet Addresses, which makes the Internet easier to use. The names
are considerably more human-friendly than IP Addresses.
[RFC0974] documented a further use of the DNS: to manage application
'manage'? not really. Few, if any, "uses of the DNS" manage applications.
This sentence appears to be saying that this added email to the use; and
of course, it didn't.
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.
Again, not quite correct.
So perhaps:
[RFC0974] added special semantics when mapping from a domain name
to an IP Address, by indicating a specific service supported at the
host, namely email, through the use of a purpose-built RR, the Mail
Exchange (MX) resource record.
The seminal MX record served as a prototype for other DNS resource
records that supported applications associated with a domain name.
MX is a direct prototype for SRV. I do not understand how it qualifies
as a prototype for the other RRs that followed, since they have no
semantic or structural similarity.
The SRV resource record [RFC2052] provided a more general mechanism
provided -> provides
It's still in use.
for locating services in a domain, complete with a weighting system
Generally, "locating" is probably not a very good vocabulary choice,
since it tends to be taken to mean 'searching', which of course the DNS
doesn't do. Again, "mapping to" is the more careful and typical
language for describing the DNS' basic function.
For reference, the tutorial nature of this document and the audiences
that are likely to need to read this really do warrant considerably more
care in the document's language.
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]) framework, added a generic mechanism for storing
application data in the DNS. Primarily, this involved a client-side
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 examples of this are
telephone numbers, as resolved by the DDDS application ENUM. Recent
work such as Domain Keys Identified Mail (DKIM, [RFC6376]) has
enabled security features of applications to be advertised through
the DNS, via the TXT resource record.
The scope of application usage of the DNS has thus increased over
time. Applications in many environments require features such as
confidentiality, and as the contexts in which applications rely on
the DNS have increased, some application protocols have looked to
oh? This needs a citation and an explanation for the type of
confidentiality that was proposed, relative to the DNS, making clear how
it would have modified the DNS.
extend the DNS to include these sorts of capabilities. However, some
proposed usages of, and extensions to, the DNS have become misaligned
'become'? The proposals underwent a change?
Worse is that this goes back to the tone of fear and criticism. Given
the nature of this document, it should provide careful documentation of
inappropriate proposals and explanations that justify claiming they
were/are inappropriate.
What is especially important is to distinguish between stray crazy ideas
from random people, versus serious efforts that were problematic. The
former are mere noise and should be ignored; they do not justify the
tone of suspicion in this document. The latter are (potentially) the
real danger, if any can be documented.
with both the DNS architecture and the DNS protocol. Taking the
example of confidentiality: In the global public DNS, 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 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 policy can
the DNS maintain confidential records, by providing distinct answers
to the private and public users of the DNS. In support of load
balancing or other optimizations, a DNS server may return different
addresses in response to queries from different sources, or even no
Peterson, et al. Expires August 30, 2013 [Page 4]
Internet-Draft Application Features in DNS February 2013
response at all, which is discussed further in Section 3.1.1.
The above paragraph offers confidentiality as an example, presumably as
an inappropriate goal for the DNS, but then the text merely says that's
not what's typically done. There's no real substance in the text for
this purported example.
For example, would it be inappropriate to have the resolver/server DNS
exchange be encrypted against wiretapping (for some types of traffic
analysis)? If yes, why? Is it inappropriate to consider /any/ security
mechanisms for client/server DNS exchanges? What about server/server? Why?
For load balancing, there really is literally no substance provided
here. No sense of how it qualifies as problematic, or whatever the
point that is intended; and I can't tell what that point is.
This document provides guidance to application designers, and
application protocol designers, looking to use the DNS to support
features in their applications. It provides an overview of past
application usage of the DNS, as well as reviewing proposed new
usages. It identifies concerns and trade-offs and provides guidance
on 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 applications that rely on the DNS for the
implementation of certain features, 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
The purpose of the above sentence looks good. The sentence itself
doesn't. Too long and convoluted. Break a sequence of shorter, simpler
sentences.
existing DNS protocol fields are used in ways that their designers
did not intend to handle new applications, those applications may
demand further changes and extensions that are fundamentally at odds
with the strengths of the DNS.
Remove the silliness about intent. Nevermind that you probably are
wrong, it doesn't matter. Again, the tone of the above sentence is
focused on the fear rather than on any concrete technical or operational
substance.
The technical reality is that the DNS design permits a range of
extensibilities, albeit within constraints. The other reality is that
the modern DNS is used in a variety of application contexts. A document
like this needs to use these technical and operational realities as its
starting point.
With respect to cautions, what matters is distortions of the DNS that
actually break functionality, performance or administration. For
example, things like overloading a field have classic risks, since they
create ambiguity.
Peterson, et al. Expires August 30, 2013 [Page 5]
Internet-Draft Application Features in DNS February 2013
2. Overview of DNS Application Usages
[RFC0882] identifies the original and fundamental connection between
identifies the original and fundamental -> specifies the
{ it's inventing something, not uncovering it }
the DNS and applications. It begins by describing how the
interdomain scope of applications creates "formidable problems when
Hmmm. RFC882 doesn't use the term "interdomain". It also doesn't use
the word "scope".
Given the actual language in the RFC that precedes the portion quoted
here, I suggest:
It establishes its basis by noting the scale and diversity of
resources on the network, which creates "...
we wish to create consistent methods for referencing particular
resources that are similar but scattered throughout the environment."
This motivated transitioning the "mapping between host names... and
ARPA Internet addresses" from a global table (the original "hosts"
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 service discovery mechanism could be built
for each such application protocol that needed this functionality,
the universal support for the DNS encourages installing these
features into its public tree rather than inventing something new.
Thus, over time, several other applications leveraged DNS resource
records for locating services in a domain or for storing application
data associated with a domain in the DNS. This section gives
examples of various types of DNS usage by applications to date.
2.1. Locating Services in a Domain
The MX resource record provides the simplest example of an
application advertising its domain-level 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], though more recently, DNS-SD
([I-D.cheshire-dnsext-dns-sd]) codifies service instance naming
conventions for use across applications to locate services in a
domain).
While the MX record represents a substantial improvement over naming
conventions as a means of service location, it remains specific to a
it remains -> it is
There have been no forces attempting to change it.
single application. Thus, the general approach of the MX record was
adapted to fit a broader class of applications through the Service
Peterson, et al. Expires August 30, 2013 [Page 6]
Internet-Draft Application Features in DNS February 2013
(SRV) resource record (originally [RFC2052]). The SRV record allows
DNS resolvers to query for particular services and underlying
transports (for example, HTTP running over TLS, see [RFC2818]) and to
learn a host name and port where that service resides in a given
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 the way that applications pass domain names to
This is an interesting observation. I was under the impression that
applications pass domain names to resolvers in a consistent manner that
does not depend on the type or nature of RR being sought. Please
document this odd bit of contingent API behavior.
resolvers. Email identifiers of the form "user@domain" rely on MX
'A' records are still legal and still used for routing to email servers.
MX might dominate but is not required. The language here implies that
only MX is used.
In addition, email addresses don't 'rely' on anything other than
uniqueness and validity of their two fields. And they can be resolved
to addresses without the DNS, such as internal configuration tables. My
point is that this paragraph is entirely muddled in terms of premise and
technical details.
records to provide the convenience of simply specifying a "domain"
component rather than requiring an application to guess which
particular host handles mail on behalf of the domain. While for
The idea that a host would do guessing about IP Addresses, or that they
ever have, is silly and it's counterproductive to offer such statements.
applications like web browsing, naming conventions continue to abound
For what other applications do naming conventions 'abound'? I'm not
asking whether "some" configurations use such naming conventions, but
where they "abound".
("www.example.com"), SRV records allow applications to query for an
to query for an -> query for support of an
application-specific protocol and transport in the domain. For LDAP,
the SRV service name corresponds to the URL scheme of the identifier
invoked by the application (e.g., when "ldap://example.com"; is the
identifier, the SRV query passed to the resolver is for
"_ldap._tcp.example.com"); for other applications, the SRV service
name that the application passes to the resolver may be implicit in
huh? What does this mean and how does it work?
the identifier rather than explicit. In either case, the application
delivers the service name to the DNS to find the location of the host
1. The resolver delivers the name to the DNS
2. In terms of DNS semantics, it is not delivering a service name to the
DNS. Rather, an overlay convention encodes service name in the DNS
name, transparently to the DNS.
This is not a small point of quibbling; it's fundamental to the nature
of these kinds of enhancements. The current language could easily lead
a reader to believe that DNS query semantics are tailored to service name.
Everything being discussed here is specific to the internals of the SRV
record and the conventions of its use, not any other aspect of the DNS.
The text should make sure that the reader understands this difference
and should attribute the semantics being discussed to the details of the
SRV RR specification.
of that service for the domain, the port where the service resides on
that host, additional locations or ports for load balancing and fault
tolerance, and related application features.
Locating specific services for a domain was the first major function
for which applications started using the DNS beyond 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 applications that acquire MX (or SRV) records might need
to perform further queries or transformations in order to arrive at
an eventual domain name that will resolve to the IP addresses for the
service, [RFC1034] allowed that the Additional Data section of DNS
allowed -> allows.
It still allows it!
This text implies that the additional data feature is restricted to MX
and SRV. It isn't.
responses may contain the corresponding address records for the names
responses may contain the corresponding
->
response. These can contain information, such as the corresponding
of services designated by the MX record; this optimization, which
record; this optimization, which
->
record. This efficiency mechanism, which requires
requires support in the authoritative server and the resolver, is an
initial example of how support for application features requires
changes to DNS operation. At the same time this is an example of an
extension of the DNS that cannot be universally relied on: Many DNS
resolver implementations will ignore the addresses in the additional
section of the DNS answers because of the trustworthiness issues
described in [RFC2181].
However the cost of non-support is merely additional queries.
Peterson, et al. Expires August 30, 2013 [Page 7]
Internet-Draft Application Features in DNS February 2013
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 Resource Names
I thought the RR was core to URN support in the DNS, and is not
dependent on a transition process. That is, "a need in transition"
seems to focus on a frankly irrelevant point.
(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 allows identifiers with no
recognizable domain component to be treated as domain names for the
purpose of name resolution. Once these transformations result in a
domain name, applications can 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
describes, and then two fields that can contain translations: a
"replacement" or "regular expression" field, only one of which
appears 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 turn it into an
identifier that the DNS can resolve.
This is missing an "architectural" technical summary, such as:
So, URI support represents an integrated design consisting partly
of an overlay to the DNS and partly a new RR, but no change to basic DNS
mechanisms. The overlay performs mapping between a URI name and a
domain name, and the retrieved RR then provides a rich encoding
environment for specifying the "meaning" of the URI.
{ I might have the "meaning" phrasing wrong. }
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 domain 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 found in the in-addr domain [RFC0882], in which IPv4
addresses are encoded as domain names by applying a string
preparation algorithm that required reversing the octets and treating
each individual octet as a label in a domain name - thus, for
example, the address 192.0.2.1 became 1.2.0.192.in-addr.arpa. This
allowed resolvers to query the DNS to learn name(s) associated with
an IPv4 address. The same mechanism has been applied to IPv6
addresses [RFC3596] and other sorts of identifiers that lack 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 domain 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
Peterson, et al. Expires August 30, 2013 [Page 8]
Internet-Draft Application Features in DNS February 2013
"tpc.int" the special domain "e164.arpa" was reserved for use.
In the more mature form of the NAPTR standard, in the Dynamic
In what way is it "more mature"? What does that mean? It's more
complex. It might even be more powerful. But more "mature"???
Delegation and Discovery Service (DDDS) ([RFC3401] passim) framework,
the initial transformation of an identifier (such as a telephone
number) to a domain name was called the "First Well Known Rule." The
capability to define a "First Well Known Rule" for each application
of NAPTR generalizes the address-reversing mechanism used in-
addr.arpa. Its flexibility has inspired a number of proposals beyond
ENUM to encode and resolve unorthodox identifiers in the DNS.
"unorthodox"? I think you just mean "other" identifiers into domain names.
in the DNS -> into domain names
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
This flexibility in naming is not specific to DDDS usage. That's the
important lesson of the TPC/ENum approach. The language here is
unnecessarily tied to DDDS.
example, civic addresses. Though [RFC3402] stipulates of the
identifier that "the lexical structure of this string must imply a
unique delegation path," there is no requirement that the identifier
be hierarchical, nor that the points of delegation in the domain name
created by the "First Well Known Rule" correspond to any points of
administrative delegation inherent in the structure of the
identifier.
So? It sounds like an important point. Explain it and/or its implications.
While this ability to look up names "which are not in the domain name
syntax" does not change the underlying DNS protocol - 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
???? If that section contains statements specific to the point being
made here, refer to them explicitly. If it doesn't, then explain the
concern here.
In it current general form, this raises yet another vague fear without
making it concrete enough to be actionable.
query, the presence of the "regexp" field of NAPTR records enabled
It still enables.
unprecedented flexibility in the types of identifiers that
Drop 'unprecedented'. Again, it's unnecessarily dramatic.
But generally this sentence seems to be redundant with earlier statements.
applications could resolve with the DNS. Since the output of the
regular expression frequently took the form of a URI (in ENUM
Took? Past tense? It doesn't work anymore?
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.
Very awkward sentence form.
2.3. Arbitrary Data in the DNS
URI encoding has ways of encapsulating basically arbitrary data: the
most extreme example is data URL [RFC2397]. Thus, resolving a NAPTR
Domain names are resolved. The returned RR is not. Therefore:
Thus, resolving a NAPTR
record might result in an output other than an identifier that would
->
Thus, the returned NAPTR record might be interpreted to produce
output other than a domain name that ...
record might result in an output other than an identifier that would
subsequently be resolved to IP addresses and contacted for a
particular application - it could give a literal result which would
This two-sentence sequence appears to be a non-sequitor, since the
syntactic issue of 'encapsulation', in the first sentence, is quite a
different issue from data semantics, stated in the second.
be consumed by the application. Originally, in [RFC2168], the
intended applicability of the regular expression field in NAPTR was
narrower: 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 to "change the host that is contacted to
Peterson, et al. Expires August 30, 2013 [Page 9]
Internet-Draft Application Features in DNS February 2013
resolve a URI" or as a way of "changing the path or host once the URL
has been assigned." The regular expression tools available to NAPTR
record authors, however, grant much broader powers to alter the input
I doubt that author tools grant the power. I suspect that the NAPTR
specification document grants the power... The tools might exploit that
power, but that's a very different matter.
string, and thus applications began to rely on NAPTR to perform more
radical transformations that did not serve any of those
aforementioned needs. By [RFC3402], the output of DDDS is wholly
DDDS is an overlay capability. NAPTR is a DNS RR. The text here moves
between the layers without distinguishing where actual changes have
taken place. My guess is that the intended meaning is that the DDDS
overlay service was specified to exploit the underlying power of NAPTR,
with application-specific conventions.
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 and receiving at the end of the process
information about the manufacturer.
Historically speaking, NAPTR did not 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 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."
FWIW, note that this makes clear that the author of the DNS did not
'intend' only name-to-address mapping, as was earlier clamed, and that
he did envision a broader range of uses...
[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
requires no registration process. [RFC1464] experimented with 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 - surely not just "descriptive text" as the
TXT originally specified. 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
others, 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 many applications,
It's not the vague drama of a "checkered past" but the inherent,
technical ambiguity created by overloading the record with multiple,
uncoordinated uses that can't be readily distinguished.
most recently for DKIM [RFC6376] to store necessary information about
the security of email in DNS, though within a narrow naming
convention (records stored under "_domainkey" subdomains). Storing
This phrasing entirely misses the way that the underscore name component
restricts the TXT record to an unambiguous usage.
I suggest:
many applications. Recently a number of applications, such as
DKIM [RFC6376], have resolved the problem of TXT ambiguity by storing it
under a specialized DNS naming structure that includes the component
("_domainkeys"), which serves to restrict the scope of the TXT solely to
DKIM use.
keys in the DNS became the preferred solution for DKIM for several
reasons: notably, because email applications already queried the DNS
in their ordinary operations, 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
This implies that there have been other solutions. There hasn't.
Hence:
For DKIM, the choice of storing keys in the DNS, rather than
specifying a new and independent key distribution service, takes
advantage of the existing, Internet-wide installed base of DNS software
and operations. Email applications already queried the DNS in their
ordinary operations and the public keys associated with email require
wide public distribution.
The last clause: "and email identifiers contain a domain component that
applications can easily use to consult the DNS" doesn't make much sense
to me and doesn't appear relevant to the reasons I am aware of for
choosing the DNS as a key distribution mechanism. Given that I've been
involved with DKIM since the Yahoo Domainkeys effort, I'd have expected
to hear of that reason...
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
I'm pretty sure that this analysis is wrong. DKIM is a cooperative
service. It requires that the signer and the verifier cooperate to
achieve a validated identifier. A receiving server can simply choose to
ignore DKIM if it wants. It doesn't need to play games. A sending
server can do the same.
So what is the exact scenario that is is being hypothesized here?
(provided that DNSSEC [RFC4033] guarantees authenticity of the data).
The benefit of using DNSSEC is that the DNS response cannot be spoofed.
That's entirely different from -- or, at least, much broader than -- a
bid-down attack.
And DKIM does not rely on the presence of DNSSEC. If DNSSec is to be
cited with DKIM, it needs to be as a combinatorial enhancement that goes
beyond either mechanism independently. And it needs to be made clear
that it is a future benefit, since it does not yet have extensive
deployment. It's an appealing combination and will no doubt eventually
dominate as DNSSec use grows, but it hasn't happened yet and DKIM has
never relied on its happening, except in very generic terms, by way of
deferring reasonable concerns that the storage of DKIM keys could be
compromised.
However, there are potential issues with storing large data in the
This raises a valid point, but in a confusing manner. Perhaps:
The size of public keys, encoded as text, along with other
parameters used by DKIM, pushes towards the maximum number of characters
that can be stored in a TXT RR, as discussed in Section 3.2.1. In
addition, the domain naming convention used by DKIM and other services
limits the ability to use DNS wildcards.
(For reference, the DKIM does not 'prevent' the use of wildcards; it
limits their utility and can introduce some other surprises. But
wildcards are sometimes still possible to use effectively.)
DNS, as discussed in Section 3.2.1 as well as with the DKIM namespace
conventions that prevent the use of DNS wildcards (as discussed in
section 6.1.2 of [RFC6376] and in more general terms in [RFC5507]).
If prefixes are used to identify TXT records used by an application,
potentially the use of wildcards may furthermore cause leakages that
other applications will need to detect.
Huh? What 'leakages' are you talking about? I have no idea what this
bit of fear is about.
Peterson, et al. Expires August 30, 2013 [Page 11]
Internet-Draft Application Features in DNS February 2013
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
Sorry, but this persists in confusing dominant use with basic
architecture, even with the ending clause of the sentence.
The "basic function" of the DNS doesn't know or care that some RRs carry
IP Addresses and others don't, and it never has. And TXT records have
been used for rather too long a time to refer to them as a "departure"...
addresses, yet neither fundamentally alters the underlying semantics
Does it alter it a little bit? No. So the implication of
"fundamentally" is wrong.
of the DNS. When we consider, however, that the URIs returned by
DDDS might be base 64 encoded binary data in a data URL, the DNS
What is a "data" URL? Do you mean RFC 2397? If so, cite it.
could effectively implement the entire application feature set of any
simple query-response protocol. Effectively, the DDDS framework
considers the DNS a generic database - indeed, the DDDS framework was
No it doesn't. It considers it an indexed storage engine. That's
rather simpler than a "database", which implies richer functionality,
such as searching and content-based indexes that the DNS doesn't have.
It's frankly surprising that an IAB draft would refer to the DNS as a
database...
{review terminated }
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net