The History of DNS: From HOSTS.TXT to the Root Zone

By Victor Hoang · Updated Oct 22, 2026

In December 1973, a researcher named L. Peter Deutsch at Xerox's Palo Alto Research Center wrote a Request for Comments note. Every site on the network kept a slightly different, usually out-of-date list of host names and addresses. He called this absurd. He proposed that the Network Information Center (NIC) publish one official file instead.

The Domain Name System (DNS) was designed by Paul Mockapetris at the University of Southern California's Information Sciences Institute (ISI). The first specifications, RFC 882 and RFC 883, appeared in November 1983. DNS replaced a single host table that one office at SRI International kept for the whole ARPANET. The throughline is delegation: DNS scaled because nobody had to keep the whole list. Its later fights, from governance to security, are all about who is trusted to answer for a name.

That note is where the story of the Domain Name System really begins. A name was a convenience that needed an owner. The first owner was a single office.

Timeline at a Glance

The Directory Idea (1878-1974)

A list of names becomes a way to connect

Picture a one-page sheet pinned near a switchboard in New Haven, Connecticut. On 28 January 1878, George Coy opened what UConn Library calls the world's first public telephone exchange. Three weeks later he published the first telephone directory, a one-page list of 50 subscribers. Nobody called it a name system, and it only listed people who already shared one exchange, so treat it as a precursor and not as an ancestor. But the problem is the same one DNS would solve a century later: a person needs a short, memorable name, and a machine needs a route.

The ARPANET reached that problem in months, not decades. By 21 December 1971, RFC 289 by Richard W. Watson of SRI recorded how hard it had been to settle on one list of host names. Peggy Karp had made the first formal proposal in RFC 226, counter-proposals followed, and the compromise was to allow both formal names and nicknames chosen by each host's people. The NIC agreed to collect and publish them.

Publishing a list on paper was only half a fix. In RFC 606, Deutsch pointed out that four TENEX sites he used each carried a different mapping from names to addresses. He asked the NIC to keep an ASCII text file online. On 10 January 1974, RFC 608 by M.D. Kudlick answered that the NIC agreed. It credited Elizabeth "Jake" Feinler with designing the source file and proposed generating the ASCII file weekly, or as the situation warranted. Host names in that file were limited to letters, digits and the minus sign, up to 48 characters.

What this means for teams today: If three teams keep three versions of the same list, the argument isn't about the list, it's about who owns it. Naming a single owner was the first real step in 1974, and it's still the first step in cleaning up customer or product data.

The HOSTS.TXT Years (1974-1982)

One office, one file, every host

Think of a machine at SRI in Menlo Park, California, serving a text file to the entire network. The Internet Hall of Fame says Feinler's group at the NIC managed the Host Naming Registry from 1972 until 1989. The file became known as HOSTS.TXT. By March 1982, RFC 810 (Feinler, Harrenstien, Su and White) formalized it as the DoD Internet Host Table, obtainable by FTP from the SRI-NIC host as NETINFO:HOSTS.TXT, and it added network and gateway names to the older host-only table.

It worked until the network stopped looking like the one it was built for. In September 1981, David Mills of COMSAT Laboratories noted in RFC 799 that the combined ARPANET and DCNET tables held over four hundred names and nicknames, and that keeping every host's table complete had become awkward. He proposed hierarchical partitioning of the name space. A year later, RFC 819 by Zaw-Sing Su and Jon Postel showed what the new names would look like: Fred@ISIF would become Fred@F.ISI.ARPA, running from the most specific part to the most general, with the root of the tree on the right.

The flat file solved the inconsistency problem and created a scaling one. Every change had to go through the NIC, and every host had to fetch the whole file again.

What this means for teams today: Centralization is a good first design and a poor last one. It's worth asking what happens to your process when the volume is ten times higher, and who has to wait for whom.

The Mockapetris Design (1983-1987)

A distributed database replaces the single table

In November 1983, Paul Mockapetris, working at ISI, published two companion RFCs. RFC 882 gave the concepts and RFC 883 the implementation. The first RFC states the problem plainly: the size of HOSTS.TXT and the frequency of its updates were near the limit of manageability, and "What is needed is a distributed database" that does the same job. It also named a second driver, mail. Mailbox addresses had grown into an irregular mix of routes and forwarding hosts that users had to learn.

The Internet Hall of Fame notes that Mockapetris had worked on the design and first implementation of SMTP for email in 1983 before taking on DNS, and that he went on to operate the original root servers. In October 1984, RFC 920 by Postel and J. Reynolds described domains as administrative entities whose purpose is to divide name management among sub-administrations, and listed the first top-level domains: GOV, EDU, COM, MIL and ORG, plus two-letter country codes, with ARPA as a temporary one. The Hall of Fame biography credits Feinler's group with developing the top-level scheme, while RFC 920 itself carries Postel's and Reynolds's names, so credit it to the community that worked on it together.

The design settled in November 1987. RFC 1034 and RFC 1035, which obsolete RFC 882 and 883, remain the core of DNS. RFC 1034 explains why the change was needed: distributing HOSTS.TXT consumed bandwidth proportional to the square of the number of hosts, local organizations had to wait for the NIC to publish their changes, and "Explosive growth in the number of hosts didn't bode well for the future." Its answer was a hierarchical name space, a distributed database, and local caching.

What this means for teams today: The design goals in RFC 1034 read like an operating principle: let the source of the data control the trade-off between freshness and speed. Any team that pushes decisions to where the data lives is repeating it.

The Delegation Years (1985-1998)

Software, mail and rules turn the design into the system

This era overlaps the last one, because the design needed software and rules before it could replace HOSTS.TXT. In October 1985, RFC 952 re-issued the host table specification, and RFC 953 re-issued the NIC hostname server specification. The old file wasn't killed, it was kept alive during the transition. Even in October 1989, RFC 1123 says a host may use a local host table as a backup or supplement to DNS.

The software came from universities and then from a consortium. According to the Internet Systems Consortium, the Berkeley Internet Name Domain (BIND) package was written in the early 1980s at UC Berkeley as a graduate-student project under a DARPA grant. Douglas Terry, Mark Painter, David Riggle and Songnian Zhou made up the first team, and Kevin Dunlap of DEC worked on it from 1985 to 1987. ISC was founded in 1994 by Rick Adams, Paul Vixie and Carl Malamud to host BIND development, and Bob Halley and Vixie released the first production-ready BIND 8 in May 1997.

Mail gave DNS its first big application. RFC 974 (January 1986), by Craig Partridge of CSNET at BBN, described how mail systems on the internet route messages using information from the domain system. And in March 1994, RFC 1591 from Postel set out the structure of the top-level domains and the administration of domains under the Internet Assigned Numbers Authority (IANA). It also made a prediction that would not survive: "It is extremely unlikely that any other TLDs will be created."

What this means for teams today: Migrations succeed when the old system stays available while the new one earns trust. The host table lasted years after DNS was published, and a cutover plan with a fallback follows the same logic.

The ICANN Years (1998-2007)

Names move from a research circle to a public institution

By the late 1990s, domain names were commercial assets and a political question. ICANN's history page traces the lineage back to 1972, when Jon Postel started recording socket numbers for the ARPANET in a notebook, a registry that became IANA. It says ICANN was founded in 1998 and grew out of a US Government commitment to transfer management of DNS to a non-profit corporation based in the US with global participation. The same page says IANA now coordinates the DNS.

Two technical threads ran in parallel. Names were still limited to ASCII letters, digits and hyphens, so in March 2003 RFC 3490 defined Internationalizing Domain Names in Applications (IDNA). Under that scheme, non-ASCII characters are represented using only the ASCII characters already allowed in DNS, so the protocol itself didn't change. IANA's root zone database now lets visitors filter delegated top-level domains by writing system, including Arabic, Cyrillic, Han and Thai.

The other thread was security. DNS had no way to prove an answer was genuine. The first DNSSEC specification, RFC 2065, came in January 1997, and RFC 2535 replaced it in March 1999. In March 2005, RFC 4033, with RFC 4034 and a third companion, obsoleted RFC 2535 and restated the extensions that provide origin authentication and integrity protection, though not confidentiality.

What this means for teams today: Whoever runs the registry sets the rules for everyone else. When you depend on a shared system, know who governs it and how decisions about it are made. The same goes for the domain your company sends email from, as the guides on cold email infrastructure and deliverability show in practice.

The Trust Turn (2008-present)

Attacks, signatures and encryption harden the tree

On 8 July 2008, CERT published VU#800113, warning that deficiencies in the DNS protocol and common implementations made cache poisoning feasible. It cited a 16-bit transaction ID that an attacker could on average guess in 32,768 attempts, and implementations that reused a fixed source port. The recommended mitigation, source port randomization, adds about 16 more bits of randomness. CERT also said such mitigations cannot completely prevent poisoning without changes such as DNSSEC. Vendors including Apple shipped patches in the following weeks and months.

DNSSEC became meaningful at the top of the tree on 15 July 2010, when the DNS group at the University of Cambridge reported that the root zone became properly signed. IANA now runs Root Key Signing Key ceremonies, usually four times a year, in which the key is used to sign operational keys valid for three months.

Governance changed too. NTIA's final transition report says its IANA functions contract with ICANN expired as of 1 October 2016, ending the US Government's stewardship role.

The newest change is privacy. RFC 7858 (May 2016) defines DNS over TLS to stop eavesdropping and on-path tampering with queries, and RFC 8484 (October 2018) defines DNS over HTTPS. Underneath, the structure is the one Mockapetris sketched. Root Servers reports 13 root name servers run by 12 independent organizations, with more than 2,000 operational instances worldwide.

What this means for teams today: The original design assumed good faith, and every fix since has been added on top. Treat anything that resolves a name, from email authentication to a login page, as part of your security surface, and fold it into your cybersecurity awareness basics.

Key People

Key Facts

Key Facts: DNS History

• The first known telephone directory listed 50 subscribers on one page, according to UConn Library.
• RFC 1034 says distributing HOSTS.TXT used bandwidth proportional to the square of the number of hosts.
• The first top-level domains named in RFC 920 were GOV, EDU, COM, MIL, ORG and country codes, with ARPA as a temporary one.
• A DNS transaction ID is 16 bits, so an attacker needs on average 32,768 guesses to predict one, per CERT.
• The DNS root is served by 13 root name servers run by 12 independent organizations, with more than 2,000 operational instances.

The Pattern Behind the History

Reading across 150 years of lists and registries, DNS history follows four repeating moves. We call it the Delegation Ladder. It's our own synthesis of the sources above, not a published study.

1. Centralize to agree. A single owner (the NIC, with one file) ends the argument about which list is right.
2. Strain at scale. Updates, bandwidth and waiting time grow faster than the list does.
3. Delegate with rules. A hierarchy lets each zone's operator answer for its own names under shared rules, as in RFC 920 and RFC 1591.
4. Add trust last. Authentication, signatures and encryption arrive after the design is already running, and each costs years of coordination.

What It Teaches Teams Today

• Name an owner first. The 1974 fix wasn't technology. It was agreeing that the NIC keeps the list.
• Delegate before the queue gets long. If every change waits on one person or team, you're running HOSTS.TXT.
• Run old and new side by side. The host table outlived DNS's publication by years.
• Plan security as a layer, not a launch feature. DNSSEC took from 1997 to 2010 to reach the root.
• Read the history of your own naming. The same questions apply to customer IDs and product names that applied to host names. See the broader arc in the history of the Internet and the Internet timeline.

Keep reading

• Who invented the Internet?: how credit is split between the people who built each layer.
• Internet vs World Wide Web: why the network and the web have two separate origins.
• The History of Computers: the hardware story behind the network.
• The History of Cloud Computing: how computing moved onto the network.

DNS is a story about a list that outgrew its owner. Its lasting lesson is that the best systems let many people answer for their own part of a shared name space.