From: Jonas Lindberg (jonaslin@cs.washington.edu)
Date: Wed Nov 17 2004 - 01:23:30 PST
P. V. Mockapetris et al. "Development of the Domain Name System"
Reviewed by Jonas Lindberg
In this paper Mockapetris et al. discusses why the need for a distributed
name system suddenly increased, what the requirements for the system were
and the reasons for why the designers made certain choices. They also give a
lot of comments on how things could have been done better and what
unexpected problems emerged.
Before DNS, all host names and their corresponding IP addresses were stored
in one big text file, HOSTS.TXT. Everyone that wanted to use host names
rather than IP addresses had a local copy of this file which they searched
whenever they wanted to resolve a hosts IP addresses. This file was
maintained at a host at the SRI Network Information Center and distributed
periodically to all other hosts via direct or indirect file transfers.
The need for a better solution came with the ever increasing number of
connected hosts which was leading causing a rapid increase in the cost for
distributing the hosts file. The solution was going to be a distributed
naming system that could be administrated in a distributed manner. For this
purpose the name space was divided into zones that can match different
administrative units. This solution seems to me to have been a good choice,
and probably was not as obvious then as it may be today.
One interesting trade-off the designers had to make was to balance between a
lean service and more general design. On one hand, a lean service could be
built quickly and deployed early. A more general design, on the other hand,
would provide a greater functionality and be useful to a greater number of
applications, but would take more time to develop.
The most interesting parts in this paper, in my opinion, are the numerous
descriptions of mistakes and lessons learned. Building, introducing and fine
tuning an important distributed system of this size is certainly not an easy
thing and many aspects need to be considered: how to convert applications to
using the system; how well does the distributed responsibility work; what
features is needed and what features can be disregarded; difficulties with
motivating the developers, and much more.
This paper is interesting both because of its explanation of the non
technical issues and because it gives an explanation for the rationale
behind the design of DNS.
This archive was generated by hypermail 2.1.6 : Wed Nov 17 2004 - 01:23:41 PST