The History of DNS, From HOSTS.TXT to DoH

The history of DNS in one paragraph

The history of DNS (the Domain Name System) starts with one text file. Until the mid-1980s, every host on the ARPANET got the name and address of every other host from a single file, HOSTS.TXT, kept by one office in California. DNS replaced that file with a tree of names, delegated authority and cached answers. Most of the design choices made between 1983 and 1987 still decide how your VPS resolves names today. The later additions (signatures in 2010, encrypted transports from 2016) were added on top of that same design.

This deep dive follows those decisions in order. Each section ends with what that decision still means on a server you run. If you want to see how a lookup works first, read how DNS resolution works, step by step and come back.

Before DNS: one file called HOSTS.TXT

In the 1970s the ARPANET was small. Each host had a name and a numeric address, and the list of all of them lived in one file. The Network Information Center at SRI (Stanford Research Institute, later SRI International), called the NIC, maintained it. RFC 608, published in January 1974, asked sites to take that list from the NIC instead of keeping private copies. An RFC (Request for Comments) is a document in the series that defines internet protocols. RFCs are the primary source for most dates in this post.

The process was manual. An administrator who added a machine sent the change to the NIC. Staff at the NIC edited the master file. Every other site then downloaded the new HOSTS.TXT on its own schedule, usually by FTP (File Transfer Protocol). So FTP was the delivery channel for the whole naming system of the time. The history of file transfer protocols from FTP to SFTP covers that side of the story. The file format itself was written down later, in RFC 952, in October 1985.

The idea survives on every Linux server. /etc/hosts is a direct descendant of HOSTS.TXT. On most systems it is checked before DNS, because the hosts: line in /etc/nsswitch.conf lists files before any DNS source. That is why one line in /etc/hosts can override the global DNS for one machine. It is also why a forgotten entry there can make a server ignore a record you changed hours ago.

Why HOSTS.TXT stopped scaling

The file grew as the network grew, and the number of changes grew with it. Every host downloaded the whole file, so the load on the NIC grew with both numbers at once. A copy was also out of date from the moment it was fetched, because a host only saw changes at its next download. In November 1983 Paul Mockapetris wrote in RFC 882 that "the size of this table, and especially the frequency of updates to the table are near the limit of manageability."

The second problem was the shape of the names. HOSTS.TXT was a flat namespace: every name had to be unique across the whole network. That meant one central office had to approve every name, and two universities could not both call a machine vax. A flat list also has no place to record authority. No site could say "these names belong to me, so ask me about them."

The network was changing fast at the same time. The ARPANET switched to TCP/IP on 1 January 1983, and other networks were joining. A list edited by hand at one office could not keep up with that growth.

How Mockapetris designed DNS in RFC 882 and RFC 883

The design built on earlier work. In August 1982, RFC 819 by Zaw-Sing Su and Jon Postel proposed arranging names as a tree of domains. Paul Mockapetris, at the Information Sciences Institute (ISI) of the University of Southern California, turned that idea into a working system. He published it in November 1983 as two documents: RFC 882, "Domain Names: Concepts and Facilities", and RFC 883, "Domain Names: Implementation and Specification".

Four ideas from those documents still run every lookup:

• A tree of names. A name such as www.example.com. is read from right to left. The empty label after the last dot is the root. Each label to the left is a child of the one to its right.
• Delegation. Any node in the tree can hand the subtree below it to another set of name servers. That subtree is called a zone. Authority follows the tree, so the central office only manages the top.
• Caching with a time to live. Every answer carries a TTL (time to live): the number of seconds a resolver may keep it. Caching is what keeps traffic to the top of the tree small.
• Typed resource records. A name holds records of different types, such as an address record or a name server record. New types can be added without changing the protocol.

Mockapetris also wrote the first server, called JEEVES, for the DEC TOPS-20 operating system. BIND, written soon after at Berkeley, became far more widely used.

The 1987 revision: RFC 1034 and RFC 1035

In November 1987 Mockapetris published RFC 1034 and RFC 1035. They replaced RFC 882 and RFC 883, and they are still the core DNS standard today. Every later DNS RFC updates these two documents. None has replaced them.

Some changes came from four years of running the 1983 design. Mail routing is the clearest case. RFC 883 had two record types for mail, MD and MF. RFC 974, in January 1986, replaced them with a single MX (mail exchange) record that carries a preference number. The MX record your mail server depends on today dates from that change.

RFC 1035 also fixed the wire format, and three of its limits still matter. Queries go over UDP (User Datagram Protocol) on port 53. A UDP message was limited to 512 bytes, and a larger answer set a truncation flag so the client would retry over TCP. Each query carries a 16-bit message ID, so a resolver can match a reply to its question. That ID has only 65,536 possible values, which becomes important in the 2008 section below.

The 512-byte limit was lifted by EDNS (Extension Mechanisms for DNS), first in RFC 2671 in August 1999 and then in RFC 6891 in April 2013. EDNS lets a client say that it accepts bigger UDP answers. DNSSEC would not be practical without it, because signatures make answers much larger.

The first top-level domains, and why .arpa still exists

RFC 920, from October 1984, by Jon Postel and Joyce Reynolds, set out the first top-level domains. It named generic domains including .com, .edu, .gov, .mil and .org. It also allowed two-letter country codes taken from the ISO 3166 standard. The first .com name, symbolics.com, was registered on 15 March 1985.

RFC 920 also defined .arpa as a temporary domain for hosts during the move away from HOSTS.TXT. It was never removed. Today .arpa holds infrastructure names, most visibly in-addr.arpa, the tree that maps IPv4 addresses back to names. When your VPS provider sets a reverse DNS PTR record for your server's IP, that record lives under a domain created as a temporary measure in 1984. Mail servers check it, so a missing PTR record is still a common reason mail from a new VPS is rejected.

BIND: the Berkeley name server that became the default

The server that carried DNS into the wider world came from the University of California, Berkeley. In the early 1980s four graduate students at the Computer Systems Research Group (CSRG), Douglas Terry, Mark Painter, David Riggle and Songnian Zhou, wrote BIND (Berkeley Internet Name Domain) with funding from a DARPA grant. BIND shipped with BSD Unix. It spread wherever BSD spread, which in the 1980s meant many university and research networks. The history of Unix and its path to Linux explains why BSD carried so much early network software.

The CSRG maintained BIND through version 4.8.3. In 1988 Paul Vixie, then at Digital Equipment Corporation, took over development. Vixie later co-founded the Internet Software Consortium, today the Internet Systems Consortium (ISC), which has been responsible for BIND since version 4.9.3. BIND 8 followed in May 1997. BIND 9, a rewrite from scratch, was first released on 9 October 2000. One reason for the rewrite was to support DNSSEC properly.

Two habits from the BIND years are still with us. The zone file format defined in RFC 1035 and made popular by BIND is still the format most DNS hosts import and export. Also, because BIND ran almost everywhere for so long, a bug in BIND was close to a bug in the whole internet. Today there are many independent implementations (Unbound, Knot, NSD and PowerDNS among them), so a single bug does much less damage.

The root servers: 13 names and over 2,000 machines

At the top of the tree sits the root zone. A resolver that knows nothing starts there. It reads a small built-in list of root server addresses, called the root hints, and asks one of them where to find .com or .org.

There are 13 root server names, a.root-servers.net through m.root-servers.net. The number 13 comes from the 512-byte UDP limit in RFC 1035. A resolver first asks a root server for the current list of root servers. That answer, with one IPv4 address per name, had to fit in a single 512-byte packet. Thirteen names was what fit.

The 13 names are run by 12 independent organisations. Verisign runs both A and J. The others are the Information Sciences Institute at USC (B), Cogent Communications (C), the University of Maryland (D), NASA (E), ISC (F), the US Defense Information Systems Agency (G), the US Army Research Lab (H), Netnod (I), RIPE NCC (K), ICANN (L) and the WIDE Project (M).

Thirteen names does not mean thirteen machines. Since the early 2000s the operators have used anycast: the same IP address is announced from many locations, and the network routes each query to the nearest one. As of 6 October 2026, root-servers.org lists 2,048 root server instances. The root servers also answer far fewer queries than people expect. They only send referrals to top-level domain servers, and a resolver caches those referrals. The .com delegation, for example, carries a TTL of two days.

Who controls the root zone?

The root servers publish the root zone, but other parties decide what goes in it. Accounts of DNS history often get this part wrong, so this section keeps to the facts.

Jon Postel at ISI ran the IANA (Internet Assigned Numbers Authority) function, which included the root zone, until his death in October 1998. ICANN (Internet Corporation for Assigned Names and Numbers) was created in 1998 to take over that work under an agreement with the US Department of Commerce, through its NTIA (National Telecommunications and Information Administration). Under that arrangement, IANA processed changes, NTIA authorised them, and Verisign, as root zone maintainer, built and distributed the zone file.

On 1 October 2016 the NTIA contract expired, and the US government role in authorising root zone changes ended. The IANA functions are now performed by PTI (Public Technical Identifiers), an affiliate of ICANN. Verisign still compiles and distributes the root zone. For a VPS owner, none of this changed how lookups work.

Cache poisoning and the 2008 Kaminsky disclosure

Cache poisoning is the oldest serious attack on DNS, and it follows directly from the 1987 wire format. A recursive resolver sends a question over UDP and accepts the first reply that matches the question, the port and the 16-bit message ID. UDP has no handshake, so anyone on the internet can send a reply that claims to come from the real name server. If a forged reply arrives first and carries the right ID, the resolver stores the false answer. It then gives that answer to every client until the TTL runs out.

The attack was known long before 2008. In July 1997 Eugene Kashpureff poisoned resolver caches so that visitors to the InterNIC website were sent to his competing AlterNIC site. Many resolvers at the time sent every query from the same source port, so the message ID was the only value an attacker had to guess.

For years the TTL acted as a defence. Once a resolver had cached www.example.com, an attacker could not race for that name again until the cached record expired. With a long TTL, that meant one attempt per day.

Dan Kaminsky found a way around that limit in early 2008. The attacker makes the resolver look up names that do not exist, such as 83.example.com, then 84.example.com. Each name is new, so it is never in the cache, and each one starts a fresh race. The forged reply does not need to answer the question correctly. It includes extra records that claim a new name server for all of example.com. Resolvers of the time accepted those records and replaced the delegation they had cached. One won race captured the whole domain, and the attacker could retry within seconds instead of waiting a day.

Kaminsky worked with vendors in secret, and on 8 July 2008 they released patches together across many DNS implementations. He presented the full details at the Black Hat conference in August 2008. The fix was source port randomisation. A patched resolver picks a random UDP source port for each query, so a forged reply must match the port as well as the ID. That adds roughly 16 bits of guessing. RFC 5452, published in January 2009, made this standard practice.

Port randomisation makes the race much harder to win. A forged answer is still undetectable when it does win, because nothing in a plain DNS reply proves where it came from. Only a signature can do that.

DNSSEC: from RFC 2065 to a signed root

DNSSEC (DNS Security Extensions) adds signatures to DNS answers. Each zone signs its record sets, and the signatures are published as RRSIG records next to the data. The zone's public keys are published as DNSKEY records. The parent zone vouches for the child's key with a DS (delegation signer) record. A resolver can then follow a chain of trust from the root down to the name it asked about.

The first specification was RFC 2065, in January 1997, followed by RFC 2535 in March 1999. That design made the parent zone take part in every key change of every child zone, which was unworkable for a zone the size of .com. The DS record, added in 2003, solved that. The protocol was then rewritten as RFC 4033, RFC 4034 and RFC 4035 in March 2005. Sweden's .se became the first top-level domain to sign its zone in 2005.

A chain of trust needs a trusted starting point, and for years the root was not signed. That changed on 15 July 2010, when ICANN and Verisign published the first validatable signed root zone. The root key-signing key (KSK) from that date, called KSK-2010, became the trust anchor built into validating resolvers. The first root KSK rollover was planned for 11 October 2017. It was postponed because data showed some resolvers still had only the old key. It took place on 11 October 2018, when KSK-2017 replaced KSK-2010.

DNSSEC proves that an answer is authentic. It leaves the question readable, so every query and answer still travels in clear text. It also turns some mistakes into outages. A validating resolver that sees a broken signature returns SERVFAIL instead of an answer. From the client side, that looks exactly like a dead name server.

Encrypted transports: DNS over TLS and DNS over HTTPS

By the 2010s the open problem was privacy. Anyone on the path between a client and its resolver could read every name the client looked up. RFC 7626, in August 2015, described the problem formally, and two encrypted transports followed.

DNS over TLS (DoT), RFC 7858, was published in May 2016. It wraps ordinary DNS messages in TLS (Transport Layer Security) on a dedicated port, 853. A dedicated port is easy for a network to identify and block. It is also easy for an administrator to manage. Android 9, released in 2018, added a setting called Private DNS that uses DoT. The guide to what Private DNS is and how it encrypts lookups covers how that setting works.

DNS over HTTPS (DoH), RFC 8484, was published in October 2018. It sends DNS messages inside HTTPS on port 443, mixed with ordinary web traffic, so a network cannot easily separate it out. Firefox began enabling DoH by default for users in the United States in February 2020. That decision moved the choice of resolver from the operating system to the application, and people still disagree about it. DNS over QUIC (DoQ), RFC 9250, followed in May 2022.

These transports protect one hop: the path between a client and its recursive resolver. The resolver still sees every query. Its own queries to authoritative servers are mostly unencrypted. QNAME minimisation (RFC 7816 in 2016, revised as RFC 9156 in 2021) reduces that leak, because a resolver sends each server only the part of the name that server needs.

What DNS history means for a VPS owner today

TTLs decide how fast a change is seen. Resolvers may keep an answer for its full TTL, as RFC 882 designed in 1983. If your A record has a TTL of 86400 seconds, some clients will reach the old address for up to a day after you change it. Lower the TTL at least one full old-TTL period before a move. The guide to migrating a server to a new VPS with minimal downtime plans the cutover around exactly that.

Missing names are cached too. RFC 2308, from March 1998, standardised negative caching. If a resolver asks for a name before you create it, it stores the "no such name" answer (NXDOMAIN) for a period set in your zone's SOA (start of authority) record. That is why a record you just added can work from one network and fail from another. The same delay affects the TXT records used to prove domain ownership in a Certbot DNS-01 challenge for a wildcard certificate.

Your resolver choice has side effects. On Ubuntu, programs on the server send queries to the systemd-resolved stub at 127.0.0.53, which forwards them to the resolver your provider configured. This matters most for a mail server, because DNS-based blocklists such as Spamhaus refuse queries that arrive through large public resolvers. A mail host such as a self-hosted mailcow server on a VPS usually runs its own local recursive resolver for that reason.

DNSSEC failures look like outages. The most common case is a move between DNS hosts. If the DS record at your registrar still points to the old provider's key, every validating resolver returns SERVFAIL for your domain. Remove or update the DS record as part of the move, never after it.

Encryption depends on where the query starts. A phone with Private DNS on encrypts its queries, but a laptop on a VPN may still send DNS outside the tunnel. The guide on fixing DNS over a WireGuard tunnel covers that leak. Whether you want the phone setting at all is a separate question, answered in whether Private DNS mode should be on or off.

DNS is a 1980s protocol that still works the way it was designed. The remote login tools from the same period took a similar path from clear text to encryption, as the history of SSH from Telnet to OpenSSH shows.

FAQ

Who invented DNS, and when?

Paul Mockapetris, at the Information Sciences Institute of the University of Southern California, designed DNS. He published it in November 1983 as RFC 882 and RFC 883. His design built on a 1982 proposal for a tree of domain names by Zaw-Sing Su and Jon Postel (RFC 819). He revised the design in November 1987 as RFC 1034 and RFC 1035, which are still the core DNS standard today.

Why are there only 13 DNS root servers?

There are 13 root server names, a.root-servers.net through m.root-servers.net. The number is 13 because the list of names and addresses had to fit in a single 512-byte UDP packet, the limit set by RFC 1035. Those 13 names are run by 12 organisations, and each name is served by many machines using anycast. As of October 2026, root-servers.org lists more than 2,000 root server instances.

What did Dan Kaminsky discover about DNS in 2008?

Kaminsky showed that an attacker could poison a resolver's cache for a whole domain without waiting for cached records to expire. The attacker asks for random names that do not exist, so every query starts a new race. The forged replies claim a new name server for the domain. Vendors released coordinated patches on 8 July 2008 that randomise the UDP source port of each query, and RFC 5452 made that standard practice in January 2009.

Is DNS over HTTPS the same as DNSSEC?

No. DNSSEC, whose signed root went live on 15 July 2010, adds signatures that prove an answer came from the real owner of the zone, but it leaves queries readable. DNS over HTTPS (RFC 8484, 2018) and DNS over TLS (RFC 7858, 2016) encrypt the path between a client and its resolver, but they do not prove the answer is authentic. They solve different problems, and a resolver can use both.