How DNS Began: From HOSTS.TXT to Lessons in the 1988 Paper

Typing a name and getting an address back feels like a property of the internet itself. It is actually a service somebody had to design, and the people who did wrote unusually candid notes on what worked and what did not. This article follows the system from the shared file that came before it to the 1988 paper in which its designers reviewed their own work, and it picks out the lessons that still apply to anyone who runs DNS.

One file for every host

Before DNS, the mapping from host names to addresses lived in a single text file called HOSTS.TXT. It was maintained centrally at the SRI Network Information Center (SRI-NIC) and distributed to hosts by file transfer. RFC 952, published in 1985, is the official specification of that file's format, and says it could be fetched by FTP from SRI-NIC.

The scheme strained as the network grew. By September 1981, David Mills was noting in RFC 799 that the combined ARPANET and DCNET tables already held over four hundred names and nicknames, and he proposed partitioning names into name domains, with a hierarchy as the stated aim. The 1988 paper by Mockapetris and Dunlap gives the deeper reasons. The file grew with the number of hosts, which were now counted in workstations rather than timesharing systems, and the total cost of distributing it grew much faster than linearly; RFC 1034 puts it in proportion to the square of the number of hosts. And a single point of control no longer matched how organizations managed their own networks.

From host names to domains

RFC 819 (1982), by Zaw-Sing Su and Jon Postel, described the shift in naming: the simple host part of a mail address would become a composite domain, so that Fred@ISIF became Fred@F.ISI.ARPA. The names were to form a tree that follows administrative structure rather than network topology. In November 1983 Paul Mockapetris published the first DNS specification as RFC 882 (concepts) and RFC 883 (implementation). RFC 920 (1984) set the first top-level categories, GOV, EDU, COM, MIL and ORG, and provided for two-letter country codes. The specification was revised and consolidated as RFC 1034 and RFC 1035 in November 1987, which remain the base documents of the protocol today.

Design decisions you can still see today

The authors state their starting assumptions plainly: DNS had to carry at least the information HOSTS.TXT did, allow the database to be maintained in a distributed way, impose no obvious size limits, work across many environments, and perform tolerably. Several choices follow from those, and the paper records why each was made.

What surprised the authors

The paper's section on surprises is the most useful for operators. Network performance was far below expectations. The TOPS-20 root servers could process most queries in under 100 milliseconds, but clients saw 500 milliseconds to 5 seconds even from the closest root server, and queries from the ARPANET to delegated domains took 3 to 10 seconds in prime time, with 30 to 60 seconds as occasional worst cases.

Negative answers were the third of the paper's surprises, and caching them is the first item of advice in its conclusions. The designers expected negative responses, both “no such name” and “no such data”, to be rare. Early monitoring of root servers found 20 to 60 percent of responses were negative, many of them from programs using old-style host names, and from mail systems testing whether an address was valid. Even after fixes, negative responses stayed between 10 and 50 percent, typically around 25 percent, because programs that tried several names from a search list produced a steady stream of bad ones. Their conclusion was that any naming system that relies on caching for performance may need to cache negative results too. RFC 2308 (1998) replaced the optional scheme in RFC 1034 and made negative caching a required part of caching resolvers; it is why a mistyped name keeps failing quickly from a resolver's cache. See NXDOMAIN explained.

The authors were equally frank about human factors. The documentation's sample TTL values mapped to one hour and were copied everywhere, while the text recommending a few days was ignored; their recommended TTL for host names was two days. Administrators liked short TTLs so that changes would take effect quickly, even when changes were rare. One administrator reversed the TTL and data values and distributed bad data with a TTL of several years. And the early policy of delegating a domain to any organization that filled in a form listing redundant servers was a mistake: they wrote that they should have required organizations to demonstrate redundant servers with real data before delegating, and probably should have insisted that the servers be on different networks.

How big it was in 1988

• By March 1988 more than 650 domains had been delegated: about 400 ordinary organizational name spaces and about 250 network address spaces under IN-ADDR.ARPA.
• A recent measurement counted about 5,500 host names in HOSTS.TXT against more than 20,000 reachable through DNS.
• The name space had roughly 30 top-level domains, most hosts sitting under six organizational ones.
• Seven redundant root servers supported the top of the tree, three on TOPS-20 systems and four on UNIX, each typically seeing about one query per second.

Why it still matters

Three of the paper's points are live operational advice. A TTL is a trade-off between how fast changes spread and how much load and resilience caching provides; see DNS TTL explained. Negative answers are cached too, so a record you just created can stay invisible for a while after a failed lookup. And the datagram size limit shaped the protocol for decades, until EDNS(0) and the requirement for TCP support changed it; Inside a DNS message covers that story. The authors' own verdict was that the need to distribute functionality was, they believed, inexorable, and that this need together with the new functionality and opportunities for future services justified the DNS, though they conceded it had probably not yet reduced the community-wide administrative, communication or support load.

Sources and further reading

• Paul V. Mockapetris and Kevin J. Dunlap, Development of the Domain Name System, Proceedings of SIGCOMM '88, Computer Communication Review 18(4), 1988, pp. 123-133
• RFC 799: Internet Name Domains (Mills, 1981)
• RFC 819: The Domain Naming Convention for Internet User Applications (Su and Postel, 1982)
• RFC 882: Domain Names - Concepts and Facilities (Mockapetris, 1983)
• RFC 883: Domain Names - Implementation and Specification (Mockapetris, 1983)
• RFC 920: Domain Requirements (Postel and Reynolds, 1984)
• RFC 952: DoD Internet Host Table Specification (Harrenstien, Stahl and Feinler, 1985)
• RFC 1034: Domain Names - Concepts and Facilities (Mockapetris, 1987)
• RFC 1035: Domain Names - Implementation and Specification (Mockapetris, 1987)
• RFC 2308: Negative Caching of DNS Queries (DNS NCACHE) (Andrews, 1998)
• Paul Albitz and Cricket Liu, DNS and BIND, 5th edition (O'Reilly, 2006)