DNS Explained: The Internet’s Directory — and How It Breaks

The domain name system is the part of the internet that nearly everything depends on and almost nobody thinks about. It is a distributed database, a cache hierarchy and a security boundary at once, and its failure mode is cruel: when DNS stops working, everything downstream reports a different and more confusing error. Hence the oldest joke in operations.

Two kinds of server, one of which you talk to

DNS, specified by Paul Mockapetris in RFC 1034 and RFC 1035 in November 1987, splits the work between two roles that get confused constantly.

An authoritative server holds the actual records for a zone. If you run example.ca, your authoritative nameservers are the machines that know definitively which IP address belongs to www.example.ca. They answer only for their own zones and chase nothing.

A recursive resolver does the chasing. This is the server your device is configured to use — your ISP’s, 8.8.8.8, 1.1.1.1, or one on your own router. It takes a question, walks the tree until it finds an authoritative answer, caches it and hands it back. Your laptop almost never talks to an authoritative server directly.

The walk down from the root

Resolution starts at the root zone, which knows only where the top-level domains live. A resolver asks a root server for www.example.ca and is referred to the .ca servers, which refer it to example.ca’s nameservers, which give the address. Three referrals, one answer, cached on the way back.

The root is smaller and larger than people expect. There are exactly 13 root server identities, lettered A to M, run by twelve organisations — but each letter is an anycast service, and the operators collectively run over two thousand instances worldwide. The “13” is a limit inherited from what fits in a single UDP response, not a count of machines.

Caching is the entire performance story

Every DNS record carries a time-to-live: the seconds a resolver may reuse the answer before asking again. TTLs are why DNS is fast despite the tree walk — the walk almost never happens, because someone has already done it and the answer sits in a cache near you.

TTLs are also why DNS changes appear to “propagate”. Nothing is pushed anywhere; old answers simply expire, at different times in different caches. A 24-hour TTL means some resolvers keep serving the old value for the better part of a day, and there is nothing you can do about it from your end.

Hence a permanent trade-off. Short TTLs buy fast failover and cost resilience: if your authoritative servers go dark, a 60-second TTL means your domain vanishes in a minute, where an hour-long TTL buys an hour of grace. Negative answers are cached too, so a zone-file typo can outlive the fix.

DNSSEC: signed at the top, unsigned where it matters

Plain DNS cannot tell a genuine answer from a forged one. DNSSEC, specified in RFC 4033 through RFC 4035 in 2005, signs records with public-key cryptography and builds a chain of trust from the root down, signed since 2010.

Adoption is lopsided in a specific way. Measurements published by APNIC’s Geoff Huston in 2023 found that about 30% of internet users sit behind resolvers that validate DNSSEC signatures — roughly half of that from Google’s and Cloudflare’s public resolvers alone. On the signing side, some 92% of top-level domain delegations in the root are signed, but only around 4.3% of second-level domains in .com and 5.3% in .net — though several European country-code domains, including .nl, .cz, .no and .se, are past 50%.

The consequence is stark: Huston put the share of actual query traffic involving a validated signed name at around 1%, because the handful of domains that dominate query volume — the large cloud and content providers — are largely unsigned. DNSSEC is deployed at the top of the tree and at the resolvers, and mostly absent in the middle where the traffic is.

Why it stalled is not mysterious: signing adds key rollover to the list of things that can silently break a domain, and a botched rollover fails closed, with validating resolvers refusing to answer at all.

Encrypting the question

DNSSEC authenticates answers. It does not hide questions — anyone on the path still sees every name you look up. Two IETF standards address that separately.

DNS over TLS (RFC 7858, May 2016) wraps DNS in TLS on port 853. The distinctive port means operators can see you are using encrypted DNS and block it. DNS over HTTPS (RFC 8484, October 2018) maps each query into an HTTP transaction on port 443, indistinguishable from ordinary web traffic; Mozilla turned it on by default for United States Firefox users on 25 February 2020, with Cloudflare as the default resolver.

Note what changes. Encrypted DNS hides your lookups from your ISP and the local network, and moves that visibility to whoever runs the resolver you picked. It does not hide which sites you visit from a determined observer, since the connection itself reveals the destination. It redistributes trust rather than eliminating it.

Four outages worth knowing

Dyn, 21 October 2016. Three waves of denial-of-service traffic — roughly 11:10 to 13:20, 15:50 to 17:00 and 20:00 to 22:10 UTC — took a managed DNS provider’s authoritative servers offline, and with them a long list of well-known services. Dyn attributed much of the traffic to devices infected with Mirai; a study at USENIX Security 2017 tracked that IoT malware to a peak of roughly 600,000 concurrent infections. Nothing about the targets was broken. Their names could not be resolved.

Facebook, 4 October 2021. The most instructive DNS outage that was not caused by DNS. Meta’s own post-incident write-up describes a command issued during backbone maintenance that took down every backbone connection, and an audit tool whose bug failed to stop it. Meta’s authoritative DNS servers withdraw their BGP route advertisements if they cannot reach the data centres behind them — a sensible health check — so they did, and Cloudflare saw the DNS prefixes gone from the routing table by 15:58 UTC. The nameservers were running fine and unreachable, so every resolver on earth returned SERVFAIL for facebook.com, whatsapp.com and instagram.com; Cloudflare recorded roughly thirty times normal query volume as clients retried.

Cloudflare’s own resolver, 14 July 2025. A configuration error made on 6 June had quietly tied the 1.1.1.1 prefixes to a pre-production service. Updating that service withdrew the resolver’s anycast routes globally at 21:52 UTC; they returned at 22:54. Sixty-two minutes, no name resolution for a large share of the world’s DoH users.

AWS us-east-1, 20 October 2025. Amazon’s post-event summary traces the disruption to a latent race condition in DynamoDB’s DNS automation, between a Planner that generates record plans and Enactors that apply them. A delayed Enactor overwrote a newer plan with an older one, cleanup deleted that plan, and the regional endpoint dynamodb.us-east-1.amazonaws.com was left with an empty record. Resolution failures ran from 11:48 pm PDT on 19 October to 2:40 am PDT on 20 October; the fallout lasted far longer.

Why “it’s always DNS” is a real joke

The haiku that circulates in every operations team — It’s not DNS / There’s no way it’s DNS / It was DNS — is funny because of a debugging asymmetry. DNS sits underneath everything and reports its failures in someone else’s vocabulary: a stale cache looks like an application bug, a withdrawn route looks like a DNS bug. And because caching means different observers see different states of the world at once, the classic symptom is that it works for you and not for your colleague — the exact shape of a problem people spend two hours blaming on something else.

What to do about it

• Configure a second resolver from a different operator. The 1.1.1.1 outage was survivable for anyone who had one.
• Use two authoritative DNS providers for anything that matters commercially. Dyn’s customers with a second provider stayed up.
• Do not set 60-second TTLs by default. Lower them deliberately a day before a migration, then put them back.
• Turn on encrypted DNS if your threat model includes your ISP or the café’s network — and pick the operator on purpose, because you are handing them your lookup history.
• Treat a health check that withdraws routes as a design decision. Meta’s outage is the case study in a safety mechanism that removes your own remote access.