In 1983, Paul Mockapetris was a researcher at USC’s Information Sciences Institute (ISI) with a problem to solve. ARPANET was drowning in its own success, and the HOSTS.TXT file that mapped names to addresses was buckling under the load. What Mockapetris designed in response would become one of the most successful distributed systems ever built.
The Man Behind DNS
Paul Mockapetris wasn’t the only person thinking about naming systems in 1983. Multiple proposals were floating around — some more complex, some more radical. But Mockapetris had something going for him: he was working closely with Jon Postel, the legendary figure who managed much of ARPANET’s protocol development.
Postel, based at ISI, had been watching the HOSTS.TXT problem grow for years. When DARPA asked for solutions, he and Mockapetris were ready.
The Context
By early 1983, the situation was critical:
- 562+ hosts on ARPANET (and growing fast)
- TCP/IP transition completed on January 1, 1983, connecting even more networks
- SRI-NIC overwhelmed with update requests and download traffic
- Name collisions becoming more frequent as organizations competed for simple names
- Propagation delays of days or weeks between updates
The research community knew something had to change. The question was what.
Competing Proposals
Before Mockapetris’s design won out, several other approaches were considered:
Distributed HOSTS.TXT
One proposal suggested simply distributing the HOSTS.TXT maintenance across multiple sites. Each organization would maintain their own portion, and files would be merged periodically.
Problem: This didn’t solve the fundamental issues of name collision, consistency, or flat namespace limitations.
IEN 116 (1979): Name/Finger Protocol
This early proposal by Jon Postel suggested a more dynamic lookup system with finger-like queries.
Problem: Too radical a departure from existing systems, and the protocol was complex.
RFC 799 (1981): Internet Name Domains
David Mills proposed hierarchical naming with domains, influencing later thinking.
Problem: The proposal was conceptual and lacked implementation details.
RFC 819 (1982): Domain Naming Convention
Zaw-Sing Su and Jon Postel formally proposed hierarchical naming with dot-separated domains. This was the direct predecessor to DNS.
Status: This set the stage, but didn’t specify the protocol or implementation.
Mockapetris’s Insight
What set Mockapetris’s approach apart was pragmatism. Rather than designing the theoretically perfect system, he focused on what would actually work — and work soon.
His key insights:
1. Distributed Database, Not Distributed File
Instead of copying entire files around, DNS would allow queries to specific authoritative servers. You’d ask for what you needed, when you needed it.
2. Hierarchical Delegation
Organizations could manage their own namespaces. MIT would control everything under mit.edu, Berkeley everything under berkeley.edu. No more waiting for SRI-NIC to process every request.
3. Caching
DNS responses could be cached temporarily. If you looked up mit.edu once, your local resolver could remember the answer for hours or days (depending on the TTL), reducing query traffic dramatically.
4. Separation of Names and Addresses
Names would be independent of network addresses. You could move a server to a new address just by updating the DNS record — clients using the name would automatically get the new address.
5. Backward Compatibility
The system needed to work alongside HOSTS.TXT during the transition. Mockapetris designed DNS to coexist, not replace overnight.
The Design Philosophy
Mockapetris later explained his design philosophy in interviews:
“The goal was to come up with something that could be deployed incrementally. You couldn’t ask everyone to switch on the same day. So we designed it so that early adopters got immediate benefits, and the system got better as more people joined.”
This “graceful deployment” principle was crucial. Unlike some grand redesigns that require everyone to switch at once, DNS provided value from day one for any site that adopted it.
The Technical Challenge
Designing a distributed naming system isn’t trivial. Mockapetris had to solve several hard problems:
Consistency vs. Availability
In distributed systems, you often have to choose: either all queries see consistent data, or the system stays available even when parts fail. DNS chose availability — you might get slightly stale data, but you’d get something.
Trust and Delegation
How do you know the server answering your query is legitimate? DNS solved this through a chain of trust from the root servers down. The root servers tell you who’s authoritative for .com, those servers tell you who’s authoritative for example.com, and so on.
Efficiency
Every query burns network resources. DNS needed to minimize traffic through:
- Caching (don’t ask twice for the same thing)
- Referrals (tell me where to ask, don’t proxy the whole conversation)
- Compression (reduce packet sizes)
Extensibility
Mockapetris knew the system would need to evolve. He designed DNS records with a type system — different record types for different purposes. This allowed new record types (like MX for mail routing) to be added without changing the protocol.
The Timeline
The development moved fast by standards of the era:
| Date | Milestone |
|---|---|
| 1982 | RFC 819 proposes hierarchical domains |
| Early 1983 | Mockapetris begins DNS design |
| November 1983 | RFC 882 and RFC 883 published |
| 1984 | First DNS implementations deployed |
| 1985 | Root servers operational |
| 1987 | RFC 1034/1035 supersede original specs |
From concept to deployment took roughly two years — remarkably fast for such a fundamental change.
The RFC Process
Mockapetris’s design was published as two RFCs in November 1983:
- RFC 882: Domain Names — Concepts and Facilities
- RFC 883: Domain Names — Implementation and Specification
Together, these documents defined everything needed to implement DNS: the data model, query protocol, record formats, and operational guidelines.
We’ll explore these RFCs in detail in the next section.
Working with Jon Postel
No discussion of DNS creation is complete without acknowledging Jon Postel’s role. Postel was the RFC Editor, managed the protocol parameter registry (later IANA), and was the central figure in early internet protocol development.
Mockapetris and Postel worked closely throughout the design process. Postel provided:
- Political cover within the ARPANET community
- Historical context on what had been tried before
- Editorial guidance on the RFC specifications
- Coordination with SRI-NIC and DARPA
When people credit “Mockapetris” for DNS, they’re using shorthand. The system emerged from a collaborative environment at ISI, with Postel as a key contributor.
Key Takeaways
- Paul Mockapetris designed DNS while at USC’s Information Sciences Institute in 1983
- Multiple proposals existed; Mockapetris’s succeeded through pragmatism and focus on incremental deployment
- Key innovations: distributed database (not distributed file), hierarchical delegation, caching, and separation of names from addresses
- Jon Postel was a crucial collaborator and political champion
- DNS went from concept to deployed system in about two years
Next
Mockapetris captured his design in RFC 882 and RFC 883, published in November 1983. These documents laid the foundation for everything that followed. Let’s examine what they actually said.