Development of the Domain Name System* Paul V. Mockapetris USC Information Sciences Institute, Marina del Rey, California Kevin J. Dunlap Digital 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.) Abstract Simple growth was one cause of these problems; an- The Domain Name System (DNS) provides name other was the evolution of the community using service for the DARPA Internet. It is one of the largest HOSTS.TXT from the NCP-based original ARPANET name services in operation today, serves a highly to the IP/TCP-based Internet. The research diverse community of hosts, users, and networks, and ARPANET’s role had changed from being a single uses a unique combination of hierarchies, caching, and network connecting large timesharing systems to being datagram access. one of the several long-haul backbone networks linking local networks which were in turn populated with This paper examines the ideas behind the initial design workstations. The number of hosts changed from the of the DNS in 1983, discusses the evolution of these number of timesharing systems (roughly organizations) ideas into the current implementations and usages, to the number of workstations (roughly users). This notes conspicuous surprises, successes and increase was directly reflected in the size of shortcomings, and attempts to predict its future evo- HOSTS.TXT, the rate of change in HOSTS.TXT, and lution. the number of transfers of the file, leading to a much larger than linear increase in total resource use for 1. Introduction distributing the file. Since organizations were being forced into management of local network addresses, The genesis of the DNS was the observation, circa gateways, etc., by the technology anyway, it was quite 1982, that the HOSTS.TXT system for publishing the logical to want to partition the database and allow local mapping between host names and addresses was control of local name and address spaces. A distributed encountering or headed for problems. HOSTS.TXT is naming system seemed in order. the name of a simple text file, which is centrally maintained on a host at the SRI Network Information Existing distributed naming systems included the Center (SRI-NIC) and distributed to all hosts in the DARPA Internet’s IEN116 [IEN 116] and the XEROX Internet via direct and indirect file transfers. Grapevine [Birrell 82] and Clearinghouse systems [Oppen 83]. The IEN116 services seemed excessively The problems were that the file, and hence the costs of limited and host specific, and IEN116 did not provide its distribution, were becoming too large, and that the much benefit to justify the costs of renovation. The centralized control of updating did not fit the trend XEROX system was then, and may still be, the most toward more distributed management of the Internet. sophisticated name service in existence, but it was not *This research was supported by the Defense Advanced Research Projects Agency under contract MDA903-87-C-0719. Views and conclusions contained in this report are the authors’ and should not be interpreted as representing the official opinion or policy of DARPA, 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, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. ACM SIGCOMM -1- Computer Communication Review clear that its heavy use of replication, light use of architecture, or organizational style onto its caching, and fixed number of hierarchy levels were users. This idea applied all the way from appropriate for the heterogeneous and often chaotic concerns about case sensitivity to the idea that style of the DARPA Internet. Importing the XEROX the system should be useful for both large design would also have meant importing supporting timeshared hosts and isolated PCs. In general, elements of its protocol architecture. For these reasons, we wanted to avoid any constraints on the system a new design was begun. due to outside influences and permit as many different implementation structures as possible. The initial design of the DNS was specified in [RFC 882, RFC 883]. The outward appearance is a The HOSTS.TXT emulation requirement was not hierarchical name space with typed data at the nodes. particularly severe, but it did cause an early Control of the database is also delegated in a examination of schemes for storing data other than hierarchical fashion. The intent was that the data types name-to-address mappings. A hierarchical name space be extensible, with the addition of new data types seemed the obvious and minimal solution for the continuing indefinitely as new applications were distribution and size requirements. The interoperability added. Although the system has been modified and and performance constraints implied that the system refined in several areas [RFC 973, RFC 974], the would have to allow database information to be current specifications [RFC 1034, RFC 1035] and buffered between the client and the source of the data, usage are quite similar to the original definitions. since access to the source might not be possible or timely. Drawing an exact line between experimental use and production status is difficult, but 1985 saw some hosts The initial DNS design assumed the necessity of use the DNS as their sole means of accessing naming striking a balance between a very lean service and a information. While the DNS has not replaced the completely general distributed database. A lean service HOSTS.TXT mechanism in many older hosts, it is the was desirable because it would result in more standard mechanism for hosts, particularly those based implementation efforts and early availability. A general on Berkeley UNIX, that track progress in network and design would amortize the cost of introduction across operating system design. more applications, provide greater functionality, and increase the number of environments in which the DNS would eventually be used. The “leanness” 2. DNS Design criterion led to a conscious decision to omit many of The base design assumptions for the DNS were that it the functions one might expect in a state-of-the-art must: database. In particular, dynamic update of the database P with the related atomicity, voting, and backup provide at least all of the same information as considerations was omitted. The intent was to add HOSTS.TXT. these eventually, but it was believed that a system that P Allow the database to be maintained in a included these features would be viewed as too distributed manner. complex to be accepted by the community. P Have no obvious size limits for names, name components, data associated with a name, etc. 2.1 The architecture P Interoperate across the DARPA Internet and in The active components of the DNS are of two major as many other environments as possible. types: name servers and resolvers. Name servers are P Provide tolerable performance. repositories of information, and answer queries using whatever information they possess. Resolvers interface Derivative constraints included the following: to client programs, and embody the algorithms P The cost of implementing the system could only necessary to find a name server that has the be justified if it provided extensible services. In information sought by the client. particular, the system should be independent of network topology, and capable of encapsulating These functions may be combined or separated to suit other name spaces. the needs of the environment. In many cases, it is useful to centralize the resolver function in one or more P In order to be universally acceptable, the system special name servers for an organization. This should avoid trying to force a single OS, structure shares the use of cached information, and also ACM SIGCOMM -2- Computer Communication Review allows less capable hosts, such as PCs, to rely on the the domain space), but the default assumption is that resolving services of special servers without needing a the only way to tell definitely what a name represents resolver in the PC. is to look at the data associated with the name. The recommended name space structure for hosts, 2.2 The name space users, and other typical applications is one that mirrors the structure of the organization controlling the local The DNS internal name space is a variable-depth tree domain. This is convenient since the DNS features for where each node in the tree has an associated label. distributing control of the database is most efficient The domain name of a node is the concatenation of all when it parallels the tree structure. An administrative labels on the path from the node to the root of the tree. decision [RFC 920] was made to make the top levels Labels are variable-length strings of octets, and each correspond to country codes or broad organization octet in a label can be any 8-bit value. The zero length types (for example EDU for educational, MIL for label is reserved for the root. Name space searching military, UK for Great Britain). operations (for operations defined at present) are done in a case-insensitive manner (assuming ASCII). Thus the labels “Paul”, “paul”, and “PAUL”, would match 2.3 Data attached to names each other. This matching rule effectively prohibits the Since the DNS should not constrain the data that creation of brother nodes with labels having equivalent applications can attach to a name, it can’t fix the data’s spelling but different case.