From: Andrew Putnam (aputnam@cs.washington.edu)
Date: Thu Nov 25 2004 - 14:59:13 PST
Development of the Domain Name System
Paul V. Mockapetris and Kevin J. Dunlap
Summary: This paper discusses the design and motivation behind the
Domain Name System (DNS) for name resolution on the Internet. The
decisions and their repercussions are evaluated several years after
deployment.
The HOSTS.txt method for name resolution obviously was not scaling
to the rapidly growing Internet. The time and effort associated with
updating and distributing a single file from a single source seems to
be a daunting task wrought with Administrivia. Certainly the system
needed to be replaced, but the solution to the problem was not obvious.
With the choice of using an existing naming infrastructure from other
systems such as Grapevine, it is commendable that the DNS designers
recognized the constraints that reusing the old systems would impose.
The designers also took a huge risk, though, in that a new system would
be make adoption difficult.
The key design components that make DNS successful are the
hierarchical structure and caching. The hierarchical structure solves
the scalability problems of HOSTS.txt, while extensive caching makes
performance tolerable. Hierarchy seems like an obvious choice,
especially given the hierarchical structure of the Internet, but it is
not entirely a blessing. The distributed administration leads to
different interpretations on how to do things, and potential
interoperability problems that were never a concern when a single
entity handled administration.
The distributed administration also raises questions as to how to
resolve conflicts between different name servers. The potential of
servers to hold different versions of files, as well as the potential
for administrators to make errors, means that the system is vulnerable
to conflicts in information. The paper was not clear in explaining how
these conflicts were resolved, nor what the potential ramifications of
conflicting data are on the system as a whole.
One factor that lead to the adoption of DNS that the authors do not
seem to acknowledge is the backwards compatibility with HOSTS.txt. DNS
aimed to replace HOSTS.txt, but no part of the design forced users to
choose between the two options. This made it easier to adopt DNS, and
may have been the key factor in its success. This is especially true
given the poor performance of the initial DNS implementation. Users
could have frequent and critical information in their HOSTS.txt file,
and then only deal with the poorly performing DNS system when accessing
a new or atypical system.
The authors did not do a good job of describing the cache coherence
protocols, which seems to be an essential piece performance,
correctness, and manageability. I would expect that each domain should
contact other domains whenever it has an update. The only description I
saw is that when name servers contact each other, they check the
version number. Hopefully there is a way for name servers to distribute
name changes.
The name resolution for e-mail seems to be at the wrong level of
abstraction. E-mail servers should be addressed by their name, but the
actual address (the left side of the @ symbol) shouldn't have to be
handled by the naming service.
This archive was generated by hypermail 2.1.6 : Thu Nov 25 2004 - 14:59:19 PST