From: Daniel Lowd (lowd@cs.washington.edu)
Date: Tue Nov 16 2004 - 22:58:11 PST
This paper presented a series of anecdotes and "lessons learned" from the
internet DNS upgrade, along with vague and incomplete descriptions of DNS
capabilities and implementation. The value of this paper really is in
reading the discussions of decisions made, lessons learned, mistakes, etc.
Unfortunately, the paper is its own worst enemy. Consider the following
(not atypical) passage:
"While various measures have reduced the vulnerability to error, the
security of the present system does depend on the integrity of the network
addressing mechanism, and this is questionable in an era of local networks
and PCs."
This appears in the context of a section on caching, in a paragraph
discussing the dangers of caching bad data values. The previous sentence
contained an anecdote about a TTL that was mistakenly set for years,
rather than hours or days. Unfortunately, it never describes the "various
measures." In fact, it is somewhat unclear what "the present system"
refers to -- is it DNS, or is it the internet? And how is this a security
issue? That much is never explained. We are left to infer how badly
cached information will weaken system security by sometimes giving bad
values. Finally -- what do local networks and PCs have to do with this?
Are they more likely to be poorly administered, and thus contribute to the
bad caching problem? Or is it the fact that they have less processing
power and memory, and more easily crashed? The mind boggles. There may
be a perfectly reasonable explanation, but it is *never* given.
Other problems include referencing things without defining them. Maybe
IN-ADDR.ARPA was common knowledge back then, so that one may simply be a
case of being dated. But it also refers to different email naming systems
without ever describing them, or how DNS changes them. And it talks a lot
about all these different types of service that are being offered, without
ever giving complete and concrete examples.
Some pieces of text simply seemed wrong. For instance, it described the
challenge of updating software to use DNS in place of HOSTS.TXT as a
"chicken-and-egg problem," when in fact it's nothing of the sort.
Updating software can be a chicken-and-egg problem, but that assertion is
never justified. Why can't a single mailer be updated to use an already
in-place system? It doesn't seem like every mailer needs to be upgraded
for users to see benefits.
The technical description was particularly poorly organized. For example,
the first time that it mentioned datagram access (apart from the abstract)
was in the list of successes. This makes no sense. They had spent over 4
pages describing the design and implementation, but didn't see fit to
mention this "successful" detail until a later section. Why? A much
better structure is: describe a system first, perhaps including the
background and motivation; then describe the results, including successes
and failures. They almost followed this structure, but their system
description was horribly vague and incomplete. The datagram example
simply illustrates this negligence.
On the plus side, DNS seems to exist today, and seems to be a very
important thing. I like the emphasis on distributed management, the tree
structure, and the caching. I like the lessons learned, especially about
negative caching, something I hadn't really considered before. The
assertion that "Documentation should always be written with the assumption
that only the examples are read" was also a very important, though
humorous, lesson.
I think there's some good stuff in this paper that remains relevant.
Unfortunately, too much of it is inaccessible and self-defeating: it
assumes dated knowledge and employs incomplete descriptions.
This archive was generated by hypermail 2.1.6 : Tue Nov 16 2004 - 22:58:11 PST