History & the people

Before the Domain Name System, the ARPANET had a phone book, and there was exactly one of it. The Network Information Center at SRI International, in Menlo Park, California, kept a text file called HOSTS.TXT that listed every host on the network: its name, its address, the kind of machine and the services it offered. If you wanted your computer to reach another one by name, your computer needed a recent copy of that file.

The format was written down in RFC 810, the "DoD Internet Host Table Specification," in March 1982, and revised in RFC 952 in October 1985. Each line was a record: NET, GATEWAY or HOST, then fields separated by colons. Changes went to the NIC by mail or telephone; the NIC edited the master copy; and every host on the network fetched the whole file again by FTP. A companion document, RFC 953, defined a small "hostname server" that let a machine ask the NIC for the table over the network.

That design is easy to love. There is one source of truth, lookups never touch the network, and anyone can read the whole thing. Your computer still has its descendant: /etc/hosts on Linux and macOS, C:\Windows\System32\drivers\etc\hosts on Windows, checked before the DNS on most systems. It is the reason a single line in that file can still override the whole internet for one machine.

RFC 1034 opens with the reasons the file could not last, and they are worth reading in the original. The first is arithmetic:

The second was organizational. The ARPANET's big time-shared machines were being replaced by local networks full of workstations, and the organizations that owned them were already managing their own names and addresses. They had to wait for the NIC before a change was visible to anyone else, and they wanted structure of their own, not one flat list. The third was that applications, mail above all, needed a general-purpose way to look things up, not just "name to address."

The square law deserves a moment, because it is the whole story in one line. If there are n hosts and each entry is about b bytes, the file is n·b bytes. Every one of the n hosts needs a copy of every new version. So one round of updates moves n × n·b bytes: double the network and the traffic quadruples. Meanwhile the number of changes per day also grows with n, and every one of them passes across the same desk. Instrument 1 lets you put numbers on it.

In November 1983 Paul Mockapetris of USC's Information Sciences Institute published two documents: RFC 882, "Domain Names: Concepts and Facilities," and RFC 883, "Domain Names: Implementation and Specification." They described the system you use today in outline: names arranged in a tree, the tree cut into zones, each zone served by the organization that owns it, and resolvers that walk from the top of the tree down, caching what they learn. No one keeps the whole list. A server only knows its own names, and where to send you for the rest. The details of that walk are in Chapter 1 and Chapter 3.

A design needs a server. According to the BIND project's own history, the first working name server, called Jeeves, was written in 1983 and 1984 by Mockapetris himself, for DEC TOPS-20 machines at ISI and at SRI-NIC. A server for Unix followed soon after: the Berkeley Internet Name Domain, BIND, written by a group of graduate students at the University of California, Berkeley under a DARPA grant. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the first team, and the Computer Systems Research Group at Berkeley maintained it through version 4.8.3.

A tree also needs a top. In October 1984 Jon Postel and Joyce Reynolds published RFC 920, "Domain Requirements," an official policy statement that named the first top-level domains. The BIND history treats this as the moment the DNS "officially" began. From 1984 to 1987 the ARPANET was the testbed, and in November 1987 Mockapetris published RFC 1034 and RFC 1035, rewritten from that experience. They made RFC 882 and 883 obsolete and they are still the core of the standard, amended by many later documents but never replaced.

Two details in that table have aged well. .arpa never went away: it survives as the home of infrastructure such as reverse lookups (Chapter 7). And .net is not on the list; by RFC 1591 in 1994 the generic list had become EDU, COM, NET, ORG, GOV, MIL and INT.

A tree with one top needs someone to decide what hangs from it. For most of the DNS's first fifteen years that was, to a remarkable degree, one person. Jon Postel edited the RFC series from its early days and kept track of the protocol numbers, addresses and names the network depended on. Vint Cerf's memorial, RFC 2468, describes how "Jon volunteered to be the Numbers Czar and later the IANA once the Internet was in place." The Internet Assigned Numbers Authority, IANA, was that job given a name: the registry of the root zone, address blocks and protocol parameters.

Postel also wrote the rules for the top. RFC 1591, "Domain Name System Structure and Delegation," in March 1994, set out how top-level and country-code domains were delegated to managers who serve their community as trustees. It also contained a sentence that has become famous for the wrong reason:

The 1990s changed the scale of everything. In 1994, the year of RFC 1591, the Internet Software Consortium (now Internet Systems Consortium, ISC) was founded by Paul Vixie, Carl Malamud and Rick Adams to keep BIND maintained; Vixie had become BIND's caretaker while at DEC. BIND 8 shipped in May 1997 and BIND 9, a near-total rewrite, in September 2000.

In 1998 the coordination role moved to a new non-profit, the Internet Corporation for Assigned Names and Numbers, ICANN, which performed the IANA functions under a contract with the US government's National Telecommunications and Information Administration. Postel died in October 1998, the year ICANN was founded; Vint Cerf's RFC 2468 is his memorial. The contract lasted until 1 October 2016, when NTIA let it expire and the IANA stewardship transition handed oversight to the global multistakeholder community.

And the "extremely unlikely" new top-level domains arrived in bulk. ICANN's New gTLD Program opened its application window on 12 January 2012 and received 1,930 applications. By ICANN's statistics for that round, 1,241 became live top-level domains. IANA's list of top-level domains, as of the version published on 22 October 2026, holds 1,437 entries.

The original DNS trusted the network more than it should have. A resolver sends a question over UDP and accepts the first reply that matches it: the right question, from the right address, carrying the same 16-bit query ID. Sixteen bits is 65,536 possibilities. Anyone who could make a resolver ask a question, and then quickly send it a crowd of fake replies with guessed IDs, had a real chance of getting a forged answer into its cache, where every user of that resolver would then receive it. This is cache poisoning, and it was a known weakness for years.

On 8 July 2008 the CERT Coordination Center published Vulnerability Note VU#800113, "Multiple DNS implementations vulnerable to cache poisoning" (CVE-2008-1447). It thanked Dan Kaminsky of IOActive "for identifying the effectiveness and practicality of DNS cache poisoning," and Paul Vixie of ISC "for raising the urgency of these issues." What had been a theoretical weakness was shown to be practical, and resolvers everywhere needed patching at once.

The patch was simple and old. Resolvers had often sent their questions from one fixed UDP port, so the ID was the only secret. The fix was to choose a random source port for every question as well, which multiplies the number of guesses a forger needs by the number of ports in use. CERT credits Daniel J. Bernstein with the original idea and implementation. In January 2009 the IETF wrote the lessons down as RFC 5452, "Measures for Making DNS More Resilient against Forged Answers." Instrument 3 does the arithmetic. The defenses in detail, and how to check your own resolver, are in Chapter 13.

The DNS Security Extensions took a long time. The first specification, RFC 2065, appeared in January 1997. It was revised more than once; the version deployed today was published in March 2005 as three documents, RFC 4033, 4034 and 4035. Each zone signs its records, and each parent publishes a fingerprint of its child's key, so a resolver can follow a chain of trust from a key it already holds all the way down. Chapter 11 walks that chain record by record.

A chain needs a first link, and for five years after the 2005 specifications the root zone was not signed. That changed in 2010. IANA's published trust-anchor file lists the first root key-signing key, key tag 19036, as valid from 15 July 2010. From that day a validating resolver needed exactly one built-in key, the root's trust anchor, to check any signed answer on the internet.

Signatures made answers larger, which collided with a 1987 limit: DNS over UDP was capped at 512 bytes. The fix was EDNS0, the extension mechanism Paul Vixie specified in RFC 2671 in August 1999 and the IETF revised as RFC 6891 in April 2013, which lets a resolver advertise that it can take bigger replies. Without it, DNSSEC would have pushed far more traffic onto TCP. The byte-level details are in Chapter 2.

Keys are replaced on a schedule, and the root's has been replaced twice. ICANN performed the first root KSK rollover on 11 October 2018, replacing KSK-2010 with KSK-2017. The second took place on 11 October 2026, when KSK-2024 began signing the root zone; ICANN reported on 15 October 2026 that it was completed as planned, while still assessing reports of issues on a limited number of systems, with the old key's revocation to follow. Here is the public record of those keys, from IANA's trust-anchor file:

DNSSEC proves an answer is genuine. It does nothing to hide the question. For most of its life every DNS query crossed the network in plain text, so anyone on the path, from the café's Wi-Fi to the ISP, could read the list of names you looked up. The last decade has been about closing that gap.

The first step was to send less. QNAME minimisation, published as experimental RFC 7816 in March 2016 and updated as RFC 9156 in November 2021, has a resolver tell each server only as much of the name as that server needs: the root learns you want something under .com, not the full name.

Then came encryption between you and your resolver. DNS over TLS (DoT), RFC 7858, May 2016, wraps queries in TLS on a dedicated port. DNS over HTTPS (DoH), RFC 8484, October 2018, sends them as ordinary HTTPS requests, indistinguishable on the wire from web traffic. DNS over QUIC (DoQ), RFC 9250, May 2022, uses the QUIC transport for lower setup cost. All three protect the hop from your device to the resolver; the resolver itself still sees everything. Chapter 12 compares them and asks who each one hides you from.