What Is DNS and How Does It Actually Work

Every explainer opens the same way, so let's get it out of the way: DNS, the Domain Name System, is the phonebook of the internet. You type example.com, DNS looks up the number, and your browser connects. That analogy is correct, and it is also where most people stop, which is a shame, because the boring phonebook line hides one of the most impressive pieces of engineering the internet runs on.

Here is the part the analogy skips. There is no single phonebook. There is a distributed, hierarchical lookup system spread across millions of servers on every continent, answering trillions of queries a day, resolving a name you've never visited before in tens of milliseconds, with no central database anyone owns. The way I think about it, DNS is the most successful distributed system in history, and it works so well that almost nobody notices it exists until it breaks. Then it takes down half the web.

The phonebook analogy, and where it breaks

Computers don't route packets to names. They route to IP addresses, numbers like 93.184.216.34 for IPv4 or a longer hex string for IPv6. Humans are terrible at remembering numbers and great at remembering names, so DNS sits in the middle and does the translation. That much the phonebook analogy nails.

Where it breaks is the word “book,” singular. A real phonebook is one object you hold. DNS is the opposite: no machine holds the whole thing, and no machine could. There are hundreds of millions of registered domains, and the mapping changes constantly as sites move, scale, and fail over. So instead of one giant table, DNS is built as a tree, and the genius is that responsibility for each branch is delegated down to whoever owns it. ICANN and its IANA function sit at the top coordinating the root and the pool of top-level domains.^[1] Everything below that is delegated outward.

How a lookup actually works

Say you type blog.example.com into a fresh browser with nothing cached. Four kinds of server get involved, and it helps to name them because people mix them up constantly.

First, your device asks a recursive resolver. This is the workhorse, usually run by your ISP or a public service like Cloudflare's 1.1.1.1 or Google's 8.8.8.8. Its job is to do the legwork and come back with a final answer. It queries a root server, which doesn't know the address but knows who handles .com, and points the resolver at the right TLD server for that top-level domain. The TLD server doesn't know the address either, but it knows which authoritative name server is responsible for example.com. The resolver asks that authoritative server, which finally hands back the real IP for blog.example.com.^[2] The resolver returns it to you and caches it on the way out.

Read that back and notice the pattern. Nobody at the top knows the answer. Each layer only knows one thing: who to ask next. That referral chain, root to TLD to authoritative, is the whole design, and it's why DNS scales to the entire internet without a central bottleneck. The root servers don't store your domain's IP. They just keep the map to the next hop.

The records: A, AAAA, CNAME, MX, TXT

When you reach an authoritative server, what you actually get back is a record, and the type tells you what kind of answer it is. You only need to know a handful to understand 95% of what DNS does.^[3]

An A record maps a name to an IPv4 address. An AAAA record (spoken “quad-A”) does the same for IPv6. A CNAME is an alias: it says “this name is really just another name, go look that one up instead,” which is how www.example.com often points at example.com. An MX record tells other mail servers where to deliver email for the domain, which is why your website and your email can live on completely different machines. And a TXT recordholds arbitrary text, which sounds useless until you realize it's where SPF, DKIM, and DMARC live, the records that prove an email actually came from your domain and isn't spoofed.

Caching and TTL: why changes take time

If every lookup walked the full root-to-authoritative chain every time, DNS would be slow and the root servers would melt. It doesn't, because of caching. Every record carries a TTL, time to live, a number of seconds saying how long a resolver may reuse the answer before asking again.^[4] Set a TTL of 3600 and resolvers around the world will happily serve that record from cache for an hour before they bother rechecking.

This is also the source of the single most confusing thing about DNS: propagation delay. You change your site's IP, it works instantly for you, and someone across the country still hits the old server for hours. Nothing is broken. Their resolver is just serving the cached record until the TTL runs out. The pro move is to lower your TTL to something small, say 300 seconds, a day or two before a planned migration, so the old records age out fast when you flip the switch. This caching behavior is the same instinct behind a content delivery network: keep the answer close to the user so you don't pay the full round trip every time.

Why a DNS outage takes down half the internet

Here's the uncomfortable truth about DNS being step one of every connection: if step one fails, nothing after it matters. Your servers can be perfectly healthy, your app flawless, your HTTPScertificates valid, and users still see nothing but errors, because their browser can't even find where to connect. The lookup fails and the whole chain stops before it starts.

The textbook example is October 2016, when a massive DDoS attack hit Dyn, a major managed DNS provider, and knocked Twitter, Reddit, Spotify, GitHub, and a long list of others offline across much of the US.^[5]None of those sites had failed. Their DNS provider had. That's the systemic risk: the industry consolidated onto a few big managed DNS operators for good reasons, reliability and DDoS scrubbing, but concentration means one provider's bad day becomes everyone's bad day. The way I read it, DNS is the internet's most load-bearing single point of failure, and we mostly manage it with redundancy and hope.

DNS as an attack surface

DNS was designed in the early 1980s, when the internet was a few thousand trusted machines and security was an afterthought. That original trust shows. For decades DNS queries traveled in plain text over UDP, unauthenticated and unencrypted, which opened two classic problems.

The first is cache poisoning, where an attacker tricks a resolver into caching a forged record, so users asking for your bank get quietly sent to the attacker's server instead. The defense is DNSSEC, which cryptographically signs DNS records so a resolver can verify the answer actually came from the real owner and wasn't tampered with.^[6] The second is plain snooping: even without altering anything, whoever sees your DNS queries sees every site you visit. The answer there is encrypted DNS, DoH (DNS over HTTPS) and DoT (DNS over TLS), which wrap the lookup so it can't be read on the wire.^[3] Adoption of both is uneven, which tells you something about how hard it is to retrofit security onto a protocol the entire internet already depends on.

What I'd actually pay attention to

If you run anything online, three DNS habits are worth having. Lower your TTLs before you migrate, so changes propagate in minutes instead of days. Run secondary DNS with a second independent provider, because a single provider is a single point of failure and outages are not hypothetical. And turn on DNSSEC and encrypted DNS where your provider supports them, because the protocol's default posture is still “trust everything,” and that default was set when the internet was a friendlier place.

The bigger takeaway is a mindset one. DNS is a near-perfect example of a system that is invisible when it works and catastrophic when it doesn't, and those systems are exactly the ones worth understanding. The phonebook line makes DNS sound simple. It's not simple. It's a delegated, cached, globally distributed tree that answers your every click before you finish blinking, and the fact that you never think about it is the highest compliment an engineering system can earn.