DOC PREVIEW
UW-Madison CS 740 - Development of the Domain Name System

This preview shows page 1-2-3-4 out of 11 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 11 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

ACM SIGCOMM -1- Computer Communication ReviewDevelopment of the Domain Name System*Paul V. MockapetrisUSC Information Sciences Institute, Marina del Rey, CaliforniaKevin J. DunlapDigital Equipment Corp., DECwest Engineering, Washington(Originally published in the Proceedings of SIGCOMM ‘88,Computer Communication Review Vol. 18, No. 4, August 1988, pp. 123–133.) *This research was supported by the Defense Advanced Research Projects Agency under contract MDA903-87-C-0719. Views andconclusions contained in this report are the authors’ and should not be interpreted as representing the official opinion or policy ofDARPA, the U.S. government, or any person or agency connected with them.Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, theACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association forComputing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission.AbstractThe Domain Name System (DNS) provides nameservice for the DARPA Internet. It is one of the largestname services in operation today, serves a highlydiverse community of hosts, users, and networks, anduses a unique combination of hierarchies, caching, anddatagram access.This paper examines the ideas behind the initial designof the DNS in 1983, discusses the evolution of theseideas into the current implementations and usages,notes conspicuous surprises, successes andshortcomings, and attempts to predict its future evo-lution.1. IntroductionThe genesis of the DNS was the observation, circa1982, that the HOSTS.TXT system for publishing themapping between host names and addresses wasencountering or headed for problems. HOSTS.TXT isthe name of a simple text file, which is centrallymaintained on a host at the SRI Network InformationCenter (SRI-NIC) and distributed to all hosts in theInternet via direct and indirect file transfers.The problems were that the file, and hence the costs ofits distribution, were becoming too large, and that thecentralized control of updating did not fit the trendtoward more distributed management of the Internet.Simple growth was one cause of these problems; an-other was the evolution of the community usingHOSTS.TXT from the NCP-based original ARPANETto the IP/TCP-based Internet. The researchARPANET’s role had changed from being a singlenetwork connecting large timesharing systems to beingone of the several long-haul backbone networks linkinglocal networks which were in turn populated withworkstations. The number of hosts changed from thenumber of timesharing systems (roughly organizations)to the number of workstations (roughly users). Thisincrease was directly reflected in the size ofHOSTS.TXT, the rate of change in HOSTS.TXT, andthe number of transfers of the file, leading to a muchlarger than linear increase in total resource use fordistributing the file. Since organizations were beingforced into management of local network addresses,gateways, etc., by the technology anyway, it was quitelogical to want to partition the database and allow localcontrol of local name and address spaces. A distributednaming system seemed in order.Existing distributed naming systems included theDARPA Internet’s IEN116 [IEN 116] and the XEROXGrapevine [Birrell 82] and Clearinghouse systems[Oppen 83]. The IEN116 services seemed excessivelylimited and host specific, and IEN116 did not providemuch benefit to justify the costs of renovation. TheXEROX system was then, and may still be, the mostsophisticated name service in existence, but it was notACM SIGCOMM -2- Computer Communication Reviewclear that its heavy use of replication, light use ofcaching, and fixed number of hierarchy levels wereappropriate for the heterogeneous and often chaoticstyle of the DARPA Internet. Importing the XEROXdesign would also have meant importing supportingelements of its protocol architecture. For these reasons,a new design was begun.The initial design of the DNS was specified in [RFC882, RFC 883]. The outward appearance is ahierarchical name space with typed data at the nodes.Control of the database is also delegated in ahierarchical fashion. The intent was that the data typesbe extensible, with the addition of new data typescontinuing indefinitely as new applications wereadded. Although the system has been modified andrefined in several areas [RFC 973, RFC 974], thecurrent specifications [RFC 1034, RFC 1035] andusage are quite similar to the original definitions.Drawing an exact line between experimental use andproduction status is difficult, but 1985 saw some hostsuse the DNS as their sole means of accessing naminginformation. While the DNS has not replaced theHOSTS.TXT mechanism in many older hosts, it is thestandard mechanism for hosts, particularly those basedon Berkeley UNIX, that track progress in network andoperating system design.2. DNS DesignThe base design assumptions for the DNS were that itmust:provide at least all of the same information asHOSTS.TXT.Allow the database to be maintained in adistributed manner.Have no obvious size limits for names, namecomponents, data associated with a name, etc.Interoperate across the DARPA Internet and inas many other environments as possible.Provide tolerable performance.Derivative constraints included the following:The cost of implementing the system could onlybe justified if it provided extensible services. Inparticular, the system should be independent ofnetwork topology, and capable of encapsulatingother name spaces.In order to be universally acceptable, the systemshould avoid trying to force a single OS,architecture, or organizational style onto itsusers. This idea applied all the way fromconcerns about case sensitivity to the idea thatthe system should be useful for both largetimeshared hosts and isolated PCs. In general,we wanted to avoid any constraints on the systemdue to outside influences and permit as manydifferent implementation structures as possible.The HOSTS.TXT emulation requirement was notparticularly severe, but it did cause an earlyexamination of schemes for storing data other thanname-to-address mappings. A hierarchical name spaceseemed the obvious and minimal solution for thedistribution and size requirements. The interoperabilityand performance constraints implied that the systemwould have to allow database


View Full Document

UW-Madison CS 740 - Development of the Domain Name System

Documents in this Course
Load more
Download Development of the Domain Name System
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Development of the Domain Name System and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Development of the Domain Name System 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?