The internet's naming system began as a text file, and the constraint that killed the file is the most human one in this entire catalogue.

Before: a phone call and a text file

and her team at SRI's Network Information Center maintained , a central file mapping names to addresses (RFC 608; RFC 952). To get on the network you contacted the NIC, they added you, and staff updated the file a couple of times a week; every host then fetched the new copy by File Transfer Protocol () (RFC 1034, section 2.1).

The system worked and had a limit nobody could engineer around: Feinler and her colleagues worked business hours and took holidays. A network that needs to be always available cannot have a naming system that closes at five o'clock. That is a fine work-life balance and an impossible operational model, and it is the clearest example in this catalogue of a technical architecture being forced by a human constraint rather than a computational one.

The other limit was arithmetic. Every new host meant a manual edit and a full redistribution, and the network bandwidth consumed in distributing each new version "is proportional to the square of the number of hosts in the network" (RFC 1034, section 2.1).

1983: the graduate student and the assignment

Paul Mockapetris joined ISI in 1978 as a graduate student, on a team of about twenty supervised by . One day, in his own account, Postel walked into his office and asked whether he would like to work on the domain naming problem. Another account gives the brief more narrowly: to reconcile the five existing proposals for improving the naming system.

He read them and wrote his own instead. RFCs 882 and 883, published November 1983, single-authored (RFC 882; RFC 883), describing the Domain Name System and its query protocol. When the ACM gave him the Software System Award in 2019, it called the design bold and disarmingly simple.

He also wrote the first implementation, a server called Jeeves, running on DEC Tops-20 machines at ISI and at SRI's Network Information Center, which provided the first stable operational service. followed shortly after, written by graduate students at Berkeley under a DARPA grant.

The specification was revised as RFCs 1034 and 1035 in November 1987 (RFC 1034; RFC 1035), and those remain the definitive documents. The original hundred pages have since been joined by more than two hundred further RFCs.

What the design actually did

The move was from one authority to delegated authority. Rather than a central file, each organisation runs its own piece of the namespace on its own servers, and anyone in the world can query it.

Three properties follow, and all three are still the reason this works:

Delegation. The root does not need to know your hostnames; it needs to know who does. Authority stops at each boundary and the load distributes with the structure.

Caching. Answers carry a lifetime, so a popular name is resolved once and reused many times. Without caching the system would have failed at a fraction of its current scale, and the time-to-live value is the most consequential number most engineers set without thinking about it.

Names for anything. Mockapetris's own description is that it was created to let people use names for anything. The record types added since, carrying mail routing, text, service locations, keys and certificate constraints, are all consequences of that generality.

The part that was left out

DNS was designed for a network where the participants were known and largely trusted, and it has no authentication in the original design. A resolver believes the answer it receives.

Everything difficult since descends from that. Cache poisoning works because an answer that looks right is accepted. exists to sign records and has taken decades to reach partial deployment, because it requires a chain of cooperation from the root down to each zone and gives operational pain to the party that deploys it while the benefit accrues to everyone else. That is the standard economics of internet security upgrades and the standard reason they stall.

DNS over TLS and answered a different problem (not whether the answer is true, but who else can see the question), and their adoption was faster precisely because a browser or an operating system can turn them on unilaterally. The fix that one party can deploy alone wins; the fix requiring everyone to cooperate waits. That is worth stating as a general rule, because it predicts which security improvements succeed better than any assessment of their technical merit.

From naming to control

A resolver sees every name a device asks for, before any connection is made. That has made it three things it was never designed to be.

A security control. Refuse to resolve, and the connection never happens. That is the entire premise of the resolver market, and the reason OpenDNS, NextDNS, Infoblox and EfficientIP all sell from that position.

A surveillance point. The query log is a record of intent, which is why encrypted transport became a privacy argument rather than a technical one.

A censorship instrument. Blocking at the naming layer is the cheapest form of national-scale filtering available, requires no cooperation from the site being blocked, and is deployed by governments across the political spectrum.

A naming system built on trust between researchers became the internet's most convenient point of control, and none of those three uses required changing the protocol at all. They required only being in the path of the question.

Jobs and practices

DNS produces few dedicated roles and appears in every serious outage postmortem. The professional reflex it created is diagnostic: check resolution first, because a name that resolves to the wrong place produces symptoms indistinguishable from a dozen other faults.

Its practices are recognisable. discipline before a migration, lowering values in advance so a change can propagate when it matters. Zone changes under review, because a bad record is an outage with no error message. Split-horizon and its confusion, where internal and external answers differ and somebody eventually debugs the wrong one. And registrar and registry hygiene: domain expiry and registrar account compromise are outages that no amount of infrastructure quality prevents.

The companies

The work came from SRI, ISI and Berkeley, none of which commercialised it. The Internet Systems Consortium carries BIND; the operators of the root and the top-level domains are a mix of institutions, companies and governments; and the commercial market is registrars, managed authoritative providers, the DDI vendors and the public resolvers.

Where it goes

Resolution is centralising. A small number of public resolvers now answer an enormous share of the world's queries, which improves performance and privacy against the local provider while creating exactly the concentration that the distributed design was built to avoid.

Encryption moved the question, not the answer. Encrypted transport hides the query from the network and delivers it to a resolver operator, so the trust does not disappear; it relocates, and choosing a resolver became a meaningful decision rather than a default.

The record is becoming a general-purpose . Service binding, certificate constraints, encrypted client hello parameters and text records for verification: increasingly, the way one system tells another how to reach it securely is a DNS record.

And the founding property still holds. More than forty years on, the system does what a graduate student specified in a hundred pages: delegate authority, cache the answer, let people use names for anything. Almost nothing else on the internet from 1983 is still running unmodified, and the reason this is has less to do with the protocol than with the decision to give away authority rather than hold it.

This series, in order

This article opens the series DNS as infrastructure. It tells how DNS came to be; the parts turn to the system as it stands: the flaw that let a whole domain be taken in seconds, what would happen if the root went dark or lied, what you choose when you choose a public resolver, and the resolver used as a security control.

  1. The Kaminsky flaw: the summer eighty vendors patched the same bug on the same day. 2008: the known weakness that turned out to take whole domains, and the day eighty vendors patched it at once.
  2. What happens if the DNS root goes dark, or starts lying. About two days of cached delegations if the root goes silent, and the far worse case of a root that lies.
  3. Public DNS resolvers: what you are actually choosing. Cloudflare, Google, Quad9 and OpenDNS differ less in speed than in policy: what each does with your queries.
  4. DNS blocklists: RPZ, ratings, and what a refused answer costs. feeds, ratings and the cost of a refused answer: the cheapest security control there is.

Sources