The DNS story, from a single HOSTS.TXT file to billions of lookups per second
The DNS story, from a single HOSTS.TXT file to billions of lookups per second
Field note. DNS started as a single HOSTS.TXT file someone in California maintained by hand. It now resolves billions of names per second with no one in charge. Genuinely remarkable engineering.
In 1983, the internet had a few hundred hosts. Each one needed to know the IP address of every other host it might contact. How did they know? A text file called HOSTS.TXT.
This is the story of how that text file became DNS, why it had to change, and how the system has scaled to today's billions of queries per second.
DNS through the decades
HOSTS.TXT
In the early ARPANET, every host had a copy of a master text file mapping names to IPs:
192.5.13.2 UCLA-CCN
10.0.0.51 MIT-MULTICS
26.0.0.103 SRI-NIC
...
This file was maintained at SRI-NIC (Stanford Research Institute's Network Information Center). When a new host joined the network, you'd notify SRI-NIC, and your name would be added. Once a week (or whenever it was convenient), every host would FTP the latest copy.
This worked when the network had 100 hosts. It strained when it had 500. By the early 1980s, with thousands of hosts, it was breaking:
- The master file at SRI-NIC was being updated dozens of times a day.
- Hosts downloading the file were straining SRI-NIC's bandwidth.
- The file was growing large.
- Updates propagated slowly. Hosts often used stale data.
- Naming collisions were common (multiple admins picking the same name).
A scalable, distributed naming system was needed.
Mockapetris and the design
In 1983, Paul Mockapetris at USC/ISI was asked to design the replacement. He published two RFCs:
- RFC 882 (November 1983): "Domain Names: Concepts and Facilities."
- RFC 883 (November 1983): "Domain Names: Implementation and Specification."
These were the original DNS design. Later refined as RFC 1034 and 1035 in 1987, which remain the foundational DNS specs today.
The design was elegant: a hierarchical name system with delegation, distributed query resolution, caching, and a small protocol.
The key insights:
- No single master file. Names are organized in a tree, with each subtree's records held by a different server.
- Delegation. Each level of the tree delegates to the next level. Updates only need to happen at the relevant level.
- Caching. Resolvers cache answers, reducing load on authoritative servers.
- Replication. Each zone is served by multiple authoritative servers for redundancy.
These ideas are still the foundation of DNS in 2026.
Why hierarchy
The hierarchy let DNS scale. Instead of one giant file with every name, each zone is small. The root zone has only ~1500 entries (one per TLD). The .com zone has tens of millions, but no other zone needs to know about them in full.
This made delegation possible: ICANN could delegate .com to Verisign without anyone else's involvement. Verisign could delegate myserver.com to the registrant without anyone else's involvement.
The trade-off: lookups take multiple round-trips (root → TLD → authoritative). This was acceptable because caching made repeat lookups instant.
The transition
DNS rolled out gradually starting in 1985. By 1987, it was the standard for ARPANET. By 1990, HOSTS.TXT was deprecated (though Unix systems still ship with a small local /etc/hosts file for fallback).
The transition was bumpy:
- Some sites resisted, preferring the simpler text file.
- DNS software had bugs in early implementations.
- Authoritative servers were sometimes flaky.
- Caching behavior caused confusing intermittent failures.
But by the early 1990s, DNS was indispensable. As the internet exploded in the mid-1990s, only DNS could have handled the scale. HOSTS.TXT could never have.
ICANN and governance
Originally, ARPA / DARPA controlled the root zone via Jon Postel at USC/ISI. Postel was a one-man bureaucracy who reviewed and approved every name change. He's now widely revered as the internet's first librarian.
As the internet commercialized, this informal arrangement became untenable. In 1998, ICANN (Internet Corporation for Assigned Names and Numbers) was formed to formally manage:
- The root zone.
- TLD delegations.
- IP address allocation policy (via IANA).
- The DNS protocol's standards (via coordination with IETF).
ICANN is a nonprofit corporation, U.S.-based, with international participation. Its governance has been controversial (especially during the 2000s when the U.S. government had formal oversight), but it has managed the system through enormous growth without breaking it.
In 2016, the U.S. government's formal oversight of ICANN ended. ICANN is now formally a multistakeholder organization.
The root server expansion
The original DNS spec called for redundant root servers. Initially there were 9, then 13. The number 13 was chosen because of a constraint in early DNS over UDP: a single 512-byte UDP packet could fit information for 13 root servers, but not 14.
Today, those 13 "logical" root servers are each backed by hundreds of physical servers using anycast. There are over 1500 root server instances worldwide.
The root server system is one of the most over-engineered things on the internet. It is also remarkably robust. There has never been a complete root server outage.
DNSSEC and security
DNS was designed in an era of mutual trust. By the 2000s, that trust was no longer warranted. Cache poisoning attacks (Dan Kaminsky's famous 2008 work) showed that DNS responses could be forged in many cases.
DNSSEC (DNS Security Extensions) was developed to add cryptographic signatures to DNS records. If your resolver supports DNSSEC, it can verify that records haven't been tampered with.
DNSSEC adoption has been slow. The original RFCs (DNSSEC-BIS, RFC 4033-4035) were published in 2005. Significant deployment didn't happen until the mid-2010s. As of 2026, DNSSEC is widely supported but unevenly deployed: most TLDs sign, but only a minority of individual domains opt in.
The reasons: DNSSEC is operationally complex. Key rotation is hard. Tooling is uneven. Most domain owners don't need the security badly enough to do the work.
DNSSEC remains a slow, important, and frustrating part of DNS's evolution.
The .com gold rush
DNS made the commercial internet possible. The defining moment: Network Solutions' control of .com registrations and the resulting domain-name speculation of the late 1990s.
Network Solutions (a contractor) ran .com, .net, and .org from 1992 to 1999. They charged ~$70 for two-year registrations. Some people realized that good .com names had value and started registering speculatively.
business.com: sold for $7.5 million in 1999.loans.com: $3 million.sex.com: lengthy lawsuit, eventually $14 million in 2010.- Less famous but lucrative: pizza.com, beer.com, voice.com, etc.
The mid-2000s saw a secondary market for domain names that still exists. Major domains can fetch six- and seven-figure prices.
The early concentration of registrar power has since been distributed. ICANN approved many additional registrars starting in 1999. Pricing dropped (most .com registrations are now $8 to $15/year). The system became more competitive.
New TLDs
In 2014, ICANN began approving hundreds of new TLDs. .app, .dev, .tech, .online, .xyz, brand TLDs like .google, all of these came out of this expansion.
The motivation: relieving pressure on .com, providing thematic alternatives, opening new business opportunities for registries.
Results have been mixed. Some new TLDs are popular and useful (.app, .dev have strong tech adoption). Many are commercially weak. The expansion has more than doubled the number of TLDs without dramatically diversifying actual usage.
DNS in the 2020s
Several trends shape modern DNS:
Encrypted DNS (DoH, DoT). DNS queries can now be encrypted, hiding them from local network observers. Adoption is increasing, especially in mobile and consumer browsers.
Public resolvers (1.1.1.1, 8.8.8.8, 9.9.9.9). Centralized resolvers serving billions of users. Concerns about privacy and reliance, but the centralization is real.
DNSSEC still inching forward.
ECH (Encrypted Client Hello) for hiding hostnames during TLS handshakes. Slowly rolling out.
Censorship and DNS is a recurring theme. Some governments require ISPs to block specific domains by manipulating DNS responses. Encrypted DNS workarounds this.
Reliability concerns. DNS failures cause some of the most visible internet outages. The Slack outage of 2021, the Cloudflare outage of 2022, both involved DNS issues. DNS reliability is critical.
Scale today
The numbers:
- ~400 million registered domain names.
- ~1500 TLDs.
- Trillions of DNS queries per day globally.
- Top resolvers handle millions of queries per second each.
DNS scales linearly because of caching. Each name is queried infrequently by any specific resolver; most lookups are cache hits. The authoritative-server load grows much slower than the user count.
The lesson
DNS is a 1983 design that has scaled to handle the internet's growth from thousands of hosts to billions of devices. Few system designs have stood up to four decades of explosive growth.
The reason: the original design got the fundamentals right. Hierarchy, delegation, caching, redundancy. These ideas turned out to be timeless. The protocol's specific format has been extended and refined, but the architecture is recognizable.
Mockapetris designed DNS for a network 10,000 times smaller than today's. The design held. That's a remarkable accomplishment of architectural foresight.
Conclusion
DNS is the silent infrastructure that makes the human-friendly internet possible. Without it, you'd be typing IP addresses. Worse, you'd be downloading text files of address-to-name mappings.
The system has weaknesses (centralization, security retrofits, censorship vulnerability) but has scaled with the internet's growth for four decades. Most users have never heard of DNS. They use it billions of times a year.
The next time DNS is in the news for an outage, you'll have context. The system is robust, but specific failure modes do happen. Reliability is hard at scale.
Coming up
Next: Tim Berners-Lee and the Web. The 1989-1993 period when one researcher's idea at CERN turned the internet from a tool into a global phenomenon.
Hosting your game server with AndroHost means we handle most of what's in this post for you automatically: tier sizing, SRV records, off-site backups, DDoS protection.
Keep reading
Why your server's IP being public is fine, and when it isn't
A game server has an IP address. Players connect to it. The IP is, by definition, reachable from the internet. Many server owners feel uneasy about their IP being known, often because they don't know what risk it actually represents.
What a DDoS actually looks like to a Minecraft server, and what protection means
"DDoS protection" is on every hosting marketing page. Most people who pay for it don't know what it does, how attacks actually work, or what level of protection is enough. This article explains, in honest terms, what to expect.
Why "ping to server" can lie, and how to measure properly
The number next to a server in your game's server list (the "ping" or latency display) is convenient. It's also frequently misleading. This article explains what it actually measures, when it's wrong, and how to get a real number.