Shepherd writeup

ISE write-up for: draft-klensin-dns-function-considerations-04

  The basic design of the Domain Name System was completed almost 30
   years ago.  The last half of that period has been characterized by
   significant changes in requirements and expectations, some of which
   either require changes to how the DNS is used or that can be
   accommodated only poorly or not at all.  This document asks the
   question of whether it is time to either redesign and replace the DNS
   to match contemporary requirements and expectations (rather than
   continuing to try to design and implement incremental patches that
   are not fully satisfactory) or to draw some clear lines about
   functionality that is not really needed or that should be performed
   in some other way."
Since this drfat was first posted, comments on it have been requested -
and received from - the DNSOP and IETF lists.
It was reviewed for me by Craig Partridge; it's author has updated
it to answer Craig's comments.

This draft has no requests for IANA.

- - - - - - -

Craig Partridge's review:

A useful document.  Obviously the kind of thing the ISE should publish.
But I found lots of places where the document failed to make its case
and in a few instances, I thought the document was in error.

* p. 3, background -- should cite Mockapetris' SIGCOMM '88 paper on the
  DNS where he talks about the initial design and where it had already
  proved better and worse and/or forced changes.  It may actually provide
  a useful companion to the analysis here (in that one may be able to say a
  certain problem has persisted).

* p. 5, 3.1 - requiring the "ANY" be used.  "ANY" what?? I believe that's
  the ANY in the QTYPE field in the query.

  I think the idea of a single address QTYPE ignores what we learned
  with MAILA (the QTYPE for MD and MF).  One of the bugs that killed
  MD and MF is that one could query for MD, or MF, or both (MAILA),
  and intermediate nameservers would cache the result.  So if someone
  queried for MF (but not MD) and that was followed by a MAILA,
  the caching nameserver would return MF RRs without the MDs -
  and mail could be misrouted (or looped).   There's an analogous
  bug in addressing -- party 1 queries for A records, then party 2
  does a general address query -- party 2 will receive just the IPv4
  addresses, which can lead to various issues (e.g. the IPv4 addresses
  for the desired name are behind a firewall, but IPv6 addresses are
  globally routable).  Similar issues arise if the TTLs of one type of
  address are different from that of another type of address (so that
  some addresses drop out of a cache first... note that separate queries
  for A and AAAA cause the same woes).

  I would argue that 3.1, as written, does not make a case for unified
  query for addresses and does not explain the fixes required to support
  such a query.  I'd get rid of the section or revise it to point out the
  technical issues of unified queries for multiple types.

* p. 6, 3.4 "ideographic character sets, characters have meanings rather
  than representing sounds."  I actually track some work in linguistics
  and character sets and that community doesn't believe this.  It views
  "ideographic" as a nonsense category and divides
  the world into logographic, semantic and alphabetic.  Chinese is
  in that it uses symbols that represent a morpheme (which sometimes
  are also a complete word). So, while I don't know Simplified vs.
  my guess is that the characters mapped to the same morpheme.

  SImilarly, the 2nd para is pointing out an issue that isn't simply about
  meanings associated with characters (though that's an issue -- e.g.
  trademarks are for a particular image/character), but rather that the
  same word can have multiple written forms.  E.g. classic Mayan
  had rules for combining logograms into words and those combination
  rules allow you to use multiple different combinations of logograms
  to achieve the same set of sounds == the same word.

  I don't think this impacts the resulting insights of the section, though
  I think getting this right cleans up some of the confusions.

p. 7, end of 3.4 "same ownerwhip" - while the notion of "ownerwhip"
  especially in the context of owners who wish to impose rules on names
  is amusing, I think "ownership" is intended.

p. 8, last para of 3.6 is a statement that CLASS doesn't work without
   any explanation or citation that would give the reader confidence the
   statement is true.

p. 8-9, 3.7 on Loose Synchronization.  Here's a case where citing
    Grapevine may help.  It represents another data point re:
    loose synchronization and robustness and also the epidemic
    algorithm paper (in SIGCOMM '89) for Grapevine shows the
    strengths and limits of various updating approaches in multi-domain
    databases such as the DNS.  A key point, as I recall, of the
    epidemic algorithms paper is if the master doesn't know who its
    slaves are, push is pretty awful -- pull is better [but when do the
    slaves know when to pull??? - so you end up with a dynamic
    contact process.

p. 9, 3.9  on encoding. This section seems out of character with
   the introduction which says the primary intent of the document
   is to identify stresses
   that cannot be solved with patching.  But this section suggests
   the patches should just work.  Where's the stress?

p. 10, 3.10 on root server distribution -- says casually that it is
   obvious that a DNS successor... could handle these problems
   in a more appropriate and less controversial way.  Not obvious to
   this reader.  I can see that there's a wider range of choices but
   it is not at all clear that picking one of them would lead to less
   controversy.  More justification required for this conclusion.

p. 10-11, 3.11 -- says last decade or two has raised this issue.
   Nope, it hit in 1987 or 1988.  Originally the DNS rules did not
   permit names starting with a number -- this was to distinguish
   IP addresses from names.  Then 3com showed up and wanted
   a domain name.  Oops!  Rules changed (and with consequences -
   my belief is the failure of many apps to handle IP addresses in place
   of names was partially due to this change).

p. 11, 3.12 - this section glosses over the issue of single namespace.
   There's the issue of centrally controlled root and there's the question
   of can everyone see the same set of names.  Those are two different
   issues and yet this section runs them together.  Historically they
   were run together but that's no longer needed. If we believe
   blockchain permits separation of the two issues -- that's an important
   shift and should be reflected here.

p. 12, 3.13.1, URI/URL -- I view the Web situation as a mistake in
    application design that ends up hitting the DNS.  I know this is
    a protocol designer being shirty and saying "hey, you're misusing
    my stuff" -- but perhaps still useful in that it exposes tensions.
    Some of these "protocol demands" are the results of application
    limitations that they hope the DNS can fix under the covers.

p. 13, end of 3.13.1 -- isn't the issue of incremental deployment
   a universal issue not something to bury here?  One could imagine
   a redesign of the DNS in which some functions are done in
   embedded code.  E.g. imagine that the name comparison
   was coded in Lua and the DNS could download new Lua to
   all resolvers/caching servers.  Obvious security issues but
   we do similar things all the time with virus checking systems....
   And the moment that the Lua API is changed and a new release
   of the DNS comparison uses the new API, voila there's another
   incremental issue, but it is a much rarer incremental deployment issue.

   The larger point is I think the issue of incremental deployment is
   a higher level issue deserving its own section.

p. 13, start of 3.13.2 -- again, 1st para is raising incremental deployment
   issues.  Another reason to pull it into its own section.

p. 14, personal comment -- I always view the SOA encoding as a bug
    but so minor that who cared?  I gather someone is now getting bit by it?

p. 14, 3.14, "More recent decisions..." this is a non-sentence or, at least
    I can't parse it.

p. 16, section 7 - Security Considerations.  This isn't a security
    considerations -- it is a nasty comment.  Something that says:

    A wide range of security issues related to both securing
    the DNS and also to abilities to use namespaces for nefarious
    purposes have arisen.  Issues of securing the DNS would obviously
    be essential to a replacement of the DNS.  Issues of preventing
    nefarious use of the namespace (e.g. the name that appears or
    disappears as a signal to bots) would appear to be harder to
    solve within the naming system.

    With citations (of course), a para like this would be an improvement.


* Top of p. 4, "(e.g. the WKS..." lacks closing paren.

* p. 12, 3.13.1 "(a problem slightly related..." lacks a closing paren.


- - - - - - -