From: Shobhit Raj Mathur (shobhit@cs.washington.edu)
Date: Tue Nov 16 2004 - 22:32:09 PST
Development of the Domain Name System
=====================================
This paper describes the motivation and design for the first distributed
DNS (Domain Name System). It discusses the implementation issues,
successes and failures of the initial design.
In the original ARPANET there were only a few hundred hosts and a central
authority maintained a flat table of name-to-address bindings in a file
called hosts.txt. Every host in the network downloaded a copy of the file
and accessed the local copy to resolve names. Obviously this design did
not scale and it was decided that to sustain the growth of Internet a
distributed design would be required. The initial design of the DNS was a
hierarchical namespace rather than a flat table like hosts.txt. The
database was distributed and did not set any limits on the size of names
etc. Data for each name in the DNS is organized as a set of RRs (resource
records). Each RR is 5 tuple containing (name, value, type, class, TTL).
In the initial implementation, the clients contact the root server to
translate the name. If the root server has the corresponding RR it returns
the IP address, else it returns the name of the DNS server which it thinks
has the IP address and so on. This is feasible if the clients know the
address of the root server. This is not feasible today. This is one issue
that the authors could not foresee. In the current implementation the
local name server does all the hard work for translating names on behalf
of the client.
This paper is an excellent example of how a good design and implementation
would make deployment easier and widely acceptable. It is one of the
success stories where the Internet was facing severe problems (in this
case scalability) and a research proposal was widely accepted. The only
other paper we have read which attained such success is the one about
congestion control. Many other proposals though necessary in today's
internet like PIM, XCP, QoS have so far failed in their fight against the
existing inertia and haven't really taken off. The paper has a very unique
style. It first describes the motivation, then proposes the solution and
the implementation. The unique part was a section on the surprises in the
performance, both positive and negative. The authors also discuss the
problem that users did not want to move over to the new system easily from
the established hosts.txt approach. This is very relevant to the existing
internet where protocols like BGP which are the root cause of inefficiency
in routing are not being replaced, due to backward compatibility issues
and fear of 'surprises'.
This archive was generated by hypermail 2.1.6 : Tue Nov 16 2004 - 22:32:09 PST