Review: draft-iab-dns-applications-07

[Dave Crocker <[e-mail]>]

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 [phone] 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