The Domain Name System: How DNS Replaced a Single Text File
Before DNS, one file called HOSTS.TXT listed every computer on the network. See how Paul Mockapetris created the system behind every web address in 1983.
Every time you type a website address, a worldwide database translates the name into a number your computer can connect to. That database is the Domain Name System, or DNS. It was designed in 1983, after the early network had nearly outgrown the first system for naming computers: a single text file.
HOSTS.TXT: a phone book in one file
In the early days of ARPANET, every computer had a numeric address, and humans preferred names. The solution was a file called HOSTS.TXT. It was maintained by the Network Information Center at SRI (the Stanford Research Institute), and it listed the name and address of every host. Administrators periodically downloaded the latest copy to their own machines.
For a few hundred hosts, this worked well. As the network grew, the weaknesses became clear:
- Every change had to go through one central place.
- Every site had to download the whole file again, so traffic and load at the central server increased.
- Names had to be unique across the whole network, with no structure to help avoid collisions.
- Copies were always slightly out of date.
Paul Mockapetris designs DNS
The task of designing a replacement went to Paul Mockapetris at the University of Southern California's Information Sciences Institute, working with Jon Postel. In 1983 he published the first specifications, RFC 882 and RFC 883. They were revised and replaced in 1987 by RFC 1034 and RFC 1035, which remain the core documents of DNS today.
The central idea was to delegate. Rather than one master list, the namespace is a tree. At the top is the root, below that are top-level domains such as .com, and below those are the names that organisations register. Each level is managed by whoever is responsible for it, and a name server only needs to know how to find the servers one step below it.
How a lookup works
- Your computer asks a resolver (usually run by your internet provider or a public service) for the address of a name.
- The resolver asks a root server which servers handle the top-level domain.
- It then asks the top-level domain's servers which servers are responsible for the specific domain.
- Finally, it asks those servers for the record and returns the answer to you.
Answers include a time to live (TTL), which tells resolvers how long they may cache the result. Caching is what makes DNS fast, and it is also why DNS changes can take time to spread.
The first top-level domains
In 1984, RFC 920 described the initial set of top-level domains: .com, .edu, .gov, .mil and .org, along with country-code domains based on two-letter country codes. .net was added when the domains went into use in 1985, and .int in 1988. The first .com registration came in 1985, which we cover in a separate article.
BIND and the software that made it real
A specification needs an implementation. The best known early DNS server software was BIND (Berkeley Internet Name Domain), written at the University of California, Berkeley, and shipped with BSD Unix. BIND became the most widely used name server software for many years, and it is still maintained today alongside other servers.
What DNS records you will meet
| Record | Purpose |
|---|---|
| A / AAAA | Points a name to an IPv4 / IPv6 address |
| CNAME | Makes one name an alias of another |
| MX | Says which servers receive email for the domain |
| TXT | Holds free text, used for SPF, DKIM and verification |
| NS | Lists the name servers responsible for the domain |
The tradeoffs of a delegated design
DNS scales beautifully, but it was designed with little thought for security. Early DNS responses were not authenticated, which later made attacks such as cache poisoning possible. DNSSEC, a set of extensions that adds digital signatures, was developed to address this, and it has been deployed gradually over the years. The system has survived for four decades because it was simple, hierarchical and easy to extend.
DNS in the age of CDNs and cloud
DNS has also grown into a tool for steering traffic, not only for naming. Large sites return different answers depending on where a visitor is, which lets them direct people to the nearest server. Services that sit in front of a website, such as a CDN, usually work by taking over the DNS answers for the site's name so that visitors reach the CDN first. Short TTL values let operators change targets quickly during a migration, and that is why experienced administrators lower the TTL a day or two before moving a site.
Because every service depends on DNS, an outage at a major DNS provider can make many unrelated websites appear to go down at once. The records themselves are fine in such cases, but nobody can look them up. It is one reason to know where your domain's authoritative servers are and who controls them.
Why DNS matters when you host a site
Almost every "my website is down" problem after a move turns out to be a DNS question: wrong name servers, a missing record, or a cached old answer. Understanding the basics saves hours. Our knowledgebase explains how to point your domain to your hosting, and if you would rather not do it alone, the team can handle the move through our free migration service.
