Subject: Review of: draft-iab-dns-applications-01

From: Dave CROCKER <[email-masked]>
Date: Wed, 20 Apr 2011 07:39:04 -0700

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 <[email-masked]>
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

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Fri, 22 Apr 2011 11:57:53 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave CROCKER
> Sent: Wednesday, April 20, 2011 7:39 AM
> To: Olaf Kolkman; Jon Peterson; Hannes Tschofenig; Bernard Aboba
> Cc: IETF Discussion
> Subject: Review of: draft-iab-dns-applications-01
> 
> Review --
> 
> [...]

I concur with many of Dave's review comments here.  My own experience with the IETF starts around the time of SPF and its various successors, nearly all of which use the DNS to store some variants of policy or key data, so this is a topic near and dear to most of my endeavors, and there are more coming.

A couple of other recommendations of my own:

- Where the document enumerates requirements incompatible with the DNS, suggested alternatives might be wise to include, with some (perhaps brief, perhaps not) description of why/how the alternative is more appropriate.

- The issue of detecting administrative boundaries in the DNS keeps reappearing.  This might be good fodder for another document, since that topic plus that of the idea of "public suffix lists" has been recurring with increasing frequency.

- IETF 80's training day included a session about how to go about extending the DNS by registering new types rather than overloading existing ones.  Some of the material presented there might be useful to include here.

-MSK

---

From: Patrik Fältström <[email-masked]>
Date: Fri, 22 Apr 2011 21:32:54 +0200

FWIW, in general I think the document is good, and I am not a person that get hang up much things... Other people are much better on giving such comments ;-)

But, I think there is one section that should have an addition, of possible change, end of section 4:

>    In cases where applications require these sorts of features, they are
>    simply better instantiated by independent application-layer protocols
>    than the DNS.  The query-response semantics of the DNS are easily
>    replicated by HTTP, for example, and the objects which HTTP can carry
>    both in queries and responses can easily contain the necessary
>    structure to manage compound queries.  Similarly, HTTP has numerous
>    ways to provide the necessary authentication, authorization and
>    confidentiality properties that some features require.
> 
>    Where the administrative delegations of the DNS form a necessary
>    component in the instantiation of an application feature, there are
>    various ways that the DNS can bootstrap access to an independent
>    application-layer protocol better suited to field the queries in
>    question.  For example, since NAPTR records can contain URIs, those
>    URI can point to an external query-response service such as HTTP,
>    with a NAPTR service field that signal to applications that questions
>    of interest can be answered at that service.

FWIW, I went through (together with Olaf) a registration process of the URI Resource Record Type that would help solving exactly this problem. To be a tool in between SRV and NAPTR, where a prefix on an owner do sub selection of records (like SRV, instead of inside RDATA like NAPTR), and the RDATA is ordered set of URIs (instead of more complicated NAPTR RDATA structure that require rewrite rules in the DDDS), and be more structured that storing URIs in TXT records.

URI is registered as RR TYPE 256 since a while back (not too long though).

So, let me suggest the last sentence is changed to the following (because I think referencing a NAPTR and because of the requirement of defining a DDDS, when in reality the only thing one want is OWNER -> URI mapping):

> For example, since URI records can contain URIs, those
> URIs can point to an external query-response service such as HTTP,
> where the prefix of the URI is used by the applications to select
> the RR SET, and because of the HTTP based services, that is of interest.

   Patrik