Development of the Domain Name System

Summary

This paper presents the original design, implementation, surprises, successes and shortcomings of the Domain Name System.

Before DNS, the HOSTS.TXT system was used to lookup the mapping from domain names to IP addresses. This system was essentially a single file, centrally located at the SRI Network Information Center and distributed to all hosts. As the network was growing larger and the number of hosts change from number of organizations to number of workstations, this was not a feasible solution. Existing systems at the time were IEN116 and XEROX. Neither fit their requirements and so they set out to design a new system.

The specification for DNS was that it should be a hierarchical name space with typed data at the nodes. Following are some of the requirements/assumptions for the DNS:

• it should provide at least all the info in the HOSTS.TXT file
• database should be maintable in a distributed manner
• there should no obvious size limits for names, name components, data associated with a name, etc.
• should interoperate across the DARPA internet and other environments
• provide tolerable performance

DNS has 2 major active components: name servers and resolvers. Name servers store information and answer queries. Resolvers interface with the client programs and are responsible for finding the name server that has the information that the client wants.

The name space is a vairable-depth tree where each node has an associated label. There is not standard printing rule for the name format and it decouples the structre of the tree from any semantics.

There are 2 mechanisms for transferring data from source to destination: zones and caching. A zone includes a contiguous section of the tree, usually controlled by an organization and is responble for maintaining the zone's data and provide redudancy for the zone. DNS resolvers cache responses for the TTL specified by the zone.

The basic algorithm used by the DNS resolver is to search "downward" from domains that it can access already.

While building this system, they came across the following surprises:

• refinements of semantics
• performance of the network was much worse than the original design had expected, but lookups that required no network access did really well.
• the need for negative caching

Some successes of the DNS system:

• variable depth hierarchy
• organizational structure of names
• datagram access
• additional section processing: responding server can anticipate next query and include that information in the response
• caching
• mail address cooperating

Some shortcomings of the DNS system:

• type and class growth
• easy upgrade of applications: hard to convert existing apps to use DNS
  
• distribution of control vs. distribution of expertise/responsibility
  

Critique & Questions

Very interesting paper to read. It was nice to see the thought process around DNS. It is interesting to note that this paper deems caching as a success of DNS while the other paper we read shows that caching of A records is not very effective. This can probably be attributed to all the changes in the internet in the past 20 years. I wonder if the distribution of domain names when this paper was written (1988) would be Zipf-like, since there would presumably be fewer domain names. It's also important to note the lack of any authenticity and integrity checking of the data, which poses a security concern, something that was never considered in the original design.