ISE write-up for: draft-klensin-dns-function-considerations-04
Abstract:
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
logographic,
in that it uses symbols that represent a morpheme (which sometimes
are also a complete word). So, while I don't know Simplified vs.
Traditional
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.
Nits
* Top of p. 4, "(e.g. the WKS..." lacks closing paren.
* p. 12, 3.13.1 "(a problem slightly related..." lacks a closing paren.
Craig
- - - - - - -