Review --
Title: Architectural Considerations on Application Features in the DNS
By: Kolkman, Peterson, Tschofenig, Aboba
I-D: draft-iab-dns-applications-01
Reviewer: D. Crocker <dcrocker@xxxxxxxx>
Review Date: 20 April 2011
RFC 882: DNS Concepts and Facilities (1982)
--------------------------------------------
Need:
The number of resources (for example mailboxes), the number of locations
for resources, and the diversity of such an environment cause formidable
problems when we wish to create consistent methods for referencing
particular resources that are similar but scattered throughout the
environment.
...
The problem for computer mail is more severe.
...
The basic need is for a consistent name space which will be
used for referring to resources.
Solution:
The DOMAIN NAME SPACE, which is a specification for a tree
structured name space.
...
NAME SERVERS are server programs which hold information about
the domain tree's structure and set information.
...
RESOLVERS are programs that extract information from name
servers in response to user requests.
Draft Summary
-------------
The DNS provides critical infrastructure service to the public Internet.
Proposed enhancements must have a "first do no harm" basis, with respect to
existing operations. However, DNS capabilities and experiences already support
addition of new data and new types of data, so that all enhancements are not
equally suspect.
The draft lays out its goals in terms of a a set of increasing functional
demands being made, considered or possible by applications wishing to use the DNS:
"Proposals to piggyback more sophisticated application behavior on top
of the DNS, however, have raised questions about the propriety of
instantiating some features in that way, especially those with
security sensitivities."
This establishes the actual focus of the draft on fears of misuse, rather than
on guidance for proper enhancement.
It offers to explore "architectural consequences of installing application
features in the DNS" and to offer guidance for such efforts. However it does
not explain what it means by "application features in the DNS", and it offers
little discussion and less substance about architecture or guidance.
The draft has four major sections.
Motivations:
This summarizes DNS background, goals and earlier enhancements. The section
demonstrates a misunderstanding of the basis and history of the DNS, forming its
premises from a simplistic and narrow assessment of popular DNS usage, rather
than from the service's design, as captured in the above RFC 882 text. For
example the draft treats some features as unexpected enhancements when they were
part of the original vision. The draft also appears to be unaware that mnemonic
host names were in use for more than 10 years before the DNS was defined and
that the primary motivations for the DNS were administration and operations
scaling, not merely the creation of symbolic names. The statement that the
principal "purpose" of the DNS is to translate names to IP Addresses suggests
that the in-addr.arpa use and any use of CNAME do not represent principal
purposes. The original DNS design discussion is in terms that are more generic
than this draft acknowledges. Hence the original use of "resource" rather than
the draft's focus on "host" and "address".
Overview of DNS Applications Usages:
This lays out three basic services, covering service lookup, transforming one
name into another using NAPTR or DDDS, and storage of arbitrary content. The
draft appears to misunderstand that DDDS is an independent layered service,
which merely has a sub-component that is specified to map onto existing DNS
services. Rather, the draft discusses it as if DDDS makes a change to the DNS.
It makes no change and there is nothing obvious in the design or operation
of the mapping component that will cause problems for the DNS.
Challenges for the DNS:
This lists service needs that might be problematic, covering compound queries
and including requester-specific responses, as well as "metadata about tree
structure", and domain redirection. The first two have no apparent constituency
in current DNS work and discussion of the latter provides no explanation of the
substantive problems that supposedly would be caused.
Principles and Guidance:
This offers advice for the types of services that do and do not make sense
to attempt via the DNS. It postulates use of HTTP as an alternative, but without
any concrete design or operational experience. As always, untested and
unimplemented, hypothetical alternatives fare better in an analysis against
real-world ones, because they are not required to suffer real-world constraints
and costs nor to demonstrate real-world operational superiority.
In general, the document needs to be much more careful with technical terms and
statements. It has various inaccuracies about use of SRV RR, DNSSEC, zone,
authority and delegation concerning overlap dialing, and aspects of the Send-N
proposal.
Review
------
Broadly the document should be extremely careful to distinguish whether a
proposal would make changes to DNS protocol functions, data definitions,
administration, deployment, traffic and/or use. It should draw clear lines
among these, versus changes that are actually to an application, which is merely
a client of the DNS and that requires nothing of the DNS but the addition of
more data using existing RRs. This draft generally does not do that, and it is
the essential failure that permeates the draft.
Rather, the draft considers an enhancement that is a new way of using existing
DNS capabilities -- that is, one that makes no technical or operational changes
to the DNS -- to be a change to the DNS. Although some such simple uses might
have detrimental operational effects, such as overloading a server or destroying
the utility of a cache, the draft makes almost no reference to these issues.
Generally, the draft conflates DNS usage with DNS internals. It is equivalent
to saying that the DNS is changed by each, specific resource record that is
stored for each new name.
A document intending to give architectural advice needs to provide careful
citation or summary of the architecture and to link the advice it gives to that
architecture. This draft does not do that.
It also needs to be careful to distinguish between DNS architecture and the
architecture of services that use the DNS, with particular focus on the
separable demands made by the latter on the former. This draft does not do that.
For example it tends to cast the enhancements that are to be feared as moving
the DNS into being a "database" service, without carefully defining the
functional differences. Historically, the most basic distinction that is drawn
between the DNS and typical database services is the functionality of the lookup
key. For the DNS, the query string is used for an exact match. For databases,
the string can be used for fuzzy searching.
Hence, the DNS is an exact-match mapping service whereas databases are
partial-match searching services. (It is unfortunate that many DNS documents do
use the term "search" since what is meant is simple mapping. There is also the
small confusion added by common resolver implementation behavior of "searching"
variations on a name, such as adding "www".) The draft does raise the issue of
multi-attribute query key specification; this definitely is a characteristic
present for database services but not the DNS. However there are no efforts to
make such a fundamental change to the DNS. At best, the draft confuses schemes
for a layered encoding of multiple attributes into a normal DNS domain name,
with a proposal to change DNS internals. The former uses existing DNS services
and represents stylized application conventions, not DNS changes.
If the draft is to be pragmatic when raising concerns, it should carefully
distinguish among proposals that have come from significant community effort,
random individuals, or from an abstract analysis that does not yet have any
real-world impetus. This draft does not do that. Hence there is no basis for
assessing the actual concern the reader should have; nor why the particular list
of the draft's concerns is included while possible concerns are not.
The draft should explore and substantiate possibilities of damaging the DNS's
models, limits or performance, in terms of the service's details for design,
protocol, data representation, operations or usage. Will it affect clients or
servers, caches or long-term storage? And so on. This draft does not do that.
Finally the brief, summary effort to provide guidance that is at the end of the
draft only offers generic comments lacking technical detail. It reduces to a
template for each concern in the form of "X might cause problems so be careful
about doing X." Engineers need more substance to guidance they are given, and
they need it better integrated.
Recommendation
--------------
After writing this review, I was pointed to earlier comments on the previous
version of the draft:
<http://trac.tools.ietf.org/group/iab/trac/ticket/22>
<http://trac.tools.ietf.org/group/iab/trac/ticket/23>
Some of my own observations are redundant with theirs. This means that their
concerns were not fixed in the latest draft, in spite of the trac tickets' being
closed.
Simply put, the draft needs a fresh start, beginning with clearer goals, better
organization, better attention to technical details, and much more substance to
its analyses.
If the primary purpose is to criticize sundry proposals made over the years --
or current ones now in play -- then it should be titled accordingly and it
should ensure that each criticism is substantial, substantiated and much more
carefully distinguishes how the DNS is affected.
If its primary purpose is to provide guidance for enhancement, then it needs
architectural rigor and, again, substantive analysis, including comparison of
tradeoffs.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf