The Invention (1983-1987)

Zoe · 2026-08-17 · 8 min read

The Phone Book That Runs the Internet: A History of DNS · Part 2 · 1983–1987

An Open Question, Not a Blueprint

By 1983, the problem with HOSTS.TXT wasn’t a mystery to anyone paying attention. Jon Postel, running the Internet Assigned Numbers Authority (IANA) out of USC’s Information Sciences Institute, had watched it get worse for years. He didn’t write the fix himself, and he didn’t hand a finished design to someone and tell them to build it. He gave the problem to a researcher on his team named Paul Mockapetris, and the assignment was closer to an open question than a blueprint for him to execute: figure out how this should actually work.

What Mockapetris came back with wasn’t a bigger, better version of a master file. It was a different way of thinking about the problem entirely. Every naming system that had come before assumed some version of a single central list, one place that held the truth about every name on the network. Mockapetris’s design broke that assumption on purpose. His core idea was delegation: no single organization needed to hold the whole namespace anymore. The name space could be structured as a tree, and each branch of that tree could be handed off to whoever was actually responsible for it. A university could run its own piece. A company could run its own piece.

1971–1983 · HOSTS.TXTHOSTS.TXT @ SRI-NICMIT-AIBerkeleyUCLAUtah···full-file download, every host4 hosts (1969) → 213 hosts (1981)one team, one file, sole bottleneck1983– · DNS delegationroot ".".com.edu.milberkeley.eduauthoritative for its own records

From Proposal to Running Code

November 1983, two documents are published by Paul Mockapetris, those being RFC 882 and RFC 883, which proposed what he called a “Domain Name System architecture”. Paul had been working at the Information Sciences Institute at the University of Southern California since 1978. In his 5 years up to this point he had already been involved in developing what would become some of the most used pieces of the modern internet by developing the first SMTP email server using the SMTP protocol that was laid out in RFC 788 published by Jon Postel.

Mockapetris didn’t stop at the paperwork. He built the first working name server himself, called Jeeves, running on DEC TOPS-20 machines, and deployed it at two locations: USC’s Information Sciences Institute and SRI International’s Network Information Center. That second detail is worth pausing on. SRI-NIC was the same team that had been hand-maintaining HOSTS.TXT for over a decade. The system built to replace the phone book was, in part, running on the same institution’s machines.

Those two installations became the first operational DNS servers on the internet.

In 1984, the first-year TLDs got formalized. RFC 920, “Domain Requirements,” was published that October by Jon Postel and Joyce K. Reynolds, laying out the initial top-level domains: .com, .edu, .gov, .mil, .org, plus country codes following the ISO two-letter standard. A domain wanting top-level status needed an expectation of over 500 hosts. A second-level domain needed a much softer guideline of around 50.

Also in 1984, a separate and in some ways more important thread started at UC Berkeley. Jeeves ran on DEC’s operating system, which meant it was never going to spread past a couple of research sites on its own. Most of the growing edge of ARPANET, universities and research labs, ran Unix by this point. A group of Berkeley graduate students, Douglas Terry, Mark Painter, David Riggle, and Songnian Zhou, funded by a DARPA grant, built BIND, the Berkeley Internet Name Domain, to fill that gap. BIND, not Jeeves, is the implementation that actually spread DNS through the Unix world. A direct descendant of it, now maintained by the Internet Systems Consortium, is still running today, forty years later, and they even have their own documentation regarding the history of BIND.

Four Years, Then a Rewrite

From 1984 through 1987, ARPANET became the testbed for DNS, and operational experience exposed gaps in the original 1983 documents, message format inefficiencies, ambiguity in how caching and negotiation were supposed to behave, and details that simply hadn’t been stress-tested at scale.

We don’t have to take that on faith. RFC 1034 says so itself, right in its introduction:

“A design using a distributed database and generalized resources was described in RFC-882, RFC-883. Based on experience with several implementations, the system evolved into the scheme described in this memo.”

That’s Mockapetris, in his own document, stating plainly that this wasn’t a from-scratch redesign, it was the original architecture reshaped by four years of actually running it.

Further into the same RFC, in the section covering query types, there’s a smaller, more concrete example of what that reshaping actually looked like. Under the section labeled “Completion queries (Obsolete),” the RFC states:

“The optional completion services described in RFCs 882 and 883 have been deleted.”

That’s a feature that let a resolver ask for a name to be auto-completed from a partial string. Four years of real-world use had decided it wasn’t worth keeping, and Mockapetris just cut it.

In November 1987, Mockapetris published RFC 1034, “Domain Names, Concepts and Facilities,” and RFC 1035, “Domain Names, Implementation and Specification,” incorporating everything that four years of running the system had taught him. Both documents state, right in their headers, that they formally obsolete RFCs 882, 883, and a smaller interim update called RFC 973 published in between.

What’s remarkable isn’t that a rewrite happened. It’s that it only happened once. RFC 1034 and RFC 1035 have been amended a few times since its publication, but neither has ever been obsoleted. They’re still, to this day, the base documents DNS runs on. Everything added since, DNSSEC, SRV records, EDNS, encrypted transport, has been layered on top of a specification written in 1987. Paul Mockapetris took an open-ended assignment, built the first working answer himself, watched it run for four years, and fixed what needed fixing exactly once. Almost nothing in software gets to say that.

obsoletes 882, 883, 9734 yrs on ARPANETamended, never obsoleted — 39 yearsNov 1983RFC 882 / 883publishedNov 1987RFC 1034 / 1035publishedTodaysame base spec

Depending on who you ask, this is why DNS is so complicated. Its foundation was built in a different time, well before they knew what the internet would become. Paul himself even lightly implied this in a 2009 interview done by HistoryHeard.

“Well, I always say that the one thing I was sure, was that I didn’t know exactly how it was going to evolve. You know, the right way to build things is to build it as a flexible set of tools that people can use to do whatever they want. It’s hard to predict what they’re going to want to do. I must admit that if you took a look at the early days, I was designing it so that you would be able to create 50 million names, you know, the engineering would hold up. Much like how you design a bridge so it can hold so many tons. And.. today there’s probably a billion or so, so we’re about a factor of 20 larger than my fondest dreams then.” - Paul Mockapetris

DNS gave the internet a working system for giving IP addresses human-readable names. It didn’t give anyone a reason to actually want a name yet. That part came almost immediately after, and it came from an unlikely source: a struggling Cambridge computer maker who, on March 15, 1985, filed some paperwork with SRI-NIC and became, almost by accident, the first company in history to own a piece of the commercial internet.

Sources