Understanding DNS in 20 minutes
This book is short on purpose.
The blame for that lies with Karl Seguin. The Little Go Book kicked off my whole habit of learning something and writing the cheat sheet as I went. The fastest way to find out whether you understand a thing is to try explaining it in as few words as possible.
That habit pays off when you join a new company. A whole platform of new products means learning the core concepts fast, and DNS sits underneath nearly all of them.
I’m a domain hoarder. I’ve been comfortably getting myself around DNS for two decades (pointing records, moving nameservers, waiting out TTLs), but I’d never actually sat down and documented what I know, or checked whether what I “know” is even true. I didn’t know DNSSEC existed until I joined bunny.net. And it took me until last month to learn that the AAAA record is called that because an IPv6 address is four times the length of an IPv4 one, despite twenty years of adding them.
This book is the cheat sheet I wrote while finally checking.
You can read it in about twenty minutes. By the end, you’ll understand how a domain name turns into an IP address, why changes “take time to propagate” (they don’t, really), and how to debug the whole thing with one command.
You don’t need to be a DNS expert. But if you’ve ever added a record at a registrar and waited for it to show up, you know enough to start.
Computers talk to each other using IP addresses, like 79.127.237.104. Humans are terrible at remembering those.
So we invented names. bunny.net is easier to remember than any string of numbers, and the name can stay the same even when the numbers behind it change.
DNS (the Domain Name System) is the thing that translates one into the other.
Everything else in this book is detail about how it manages that at internet scale without falling over.
DNS starts to make sense once you read domain names right to left.
Take www.bunny.net. (yes, there’s a real trailing dot, more on that in a second):
. → the root
net → a top-level domain (TLD)
bunny → a domain registered under net
www → a subdomain of bunny.netDNS is a tree. The root sits at the top, TLDs like com, net and dev hang off it, registered domains hang off those, and you can nest subdomains as deep as you like.
The trailing dot represents the root of the tree. You almost never type it, but it’s implicitly there. www.bunny.net really means www.bunny.net., a full path from leaf to root.
Each level of the tree can be run by a completely different organisation. The root zone is overseen by ICANN, net is run by Verisign, bunny.net is run by whoever registered it. Nobody owns the whole tree. This is why DNS scales: responsibility is delegated downwards.
TLDs themselves come in a few flavours. com, org and net are generic, open to anyone. Two-letter ones like de and us are country codes, assigned one per country, though plenty escape their geography (io belongs to the British Indian Ocean Territory and mostly hosts startups). And companies can now run their own: .google and .microsoft are real TLDs, operated by exactly who you’d expect.
Nothing stops an ordinary domain from posing as a TLD, either. de.com looks like one, but it’s a regular com domain whose owner sells subdomains under it (uk.com, eu.com and friends are the same trick). A TLD is only a position in the tree, and anyone who registers a domain gets a subtree of their own to hand out.
When you type bunny.net into a browser, here’s what actually happens.
Your computer asks a resolver (sometimes called a resolving name server), usually one run by your ISP, or a public one like 8.8.8.8 or 9.9.9.9. The resolver’s job is to find the answer, no matter how many questions it takes.
If the resolver doesn’t already know the answer, it walks the tree from the top:
Ask a root server: “Where’s bunny.net?”
Root says: “No idea, but here are the servers for net.”
Ask a net server: “Where’s bunny.net?”
It says: “No idea, but here are the nameservers for bunny.net.”
Ask bunny.net’s nameserver: “Where’s bunny.net?”
It says: “79.127.237.104. Final answer.”
The root and TLD servers never know the final answer, they just know who to ask next. Only the last server, the one that’s authoritative for the domain, gives you the actual record.
There are thirteen root servers, named a.root-servers.net through m.root-servers.net. The limit comes from the early days, when all thirteen had to fit inside a single UDP packet. Each name is really a fleet, though: anything from a handful of machines to a few hundred, scattered around the world and sharing one IP address through a routing trick called anycast, which hands your query to whichever machine is nearest. The thirteen names add up to more than two thousand servers between them.
There are names for these two kinds of questions, and you’ll see them in docs everywhere. Your question to the resolver is a recursive query: “get me the complete answer, however many steps it takes.” The resolver’s questions up the tree are iterative queries: each server answers as best it can, or points to someone closer. You ask once and the resolver does the legwork.
Then the resolver hands the answer to your computer, your browser connects to the IP and you’ve already forgotten DNS was involved.
The full walk typically takes tens of milliseconds. And usually it’s even faster than that, because of the subject of the next chapter.
If every lookup walked the whole tree, the root servers would melt. So DNS caches everywhere: in your browser, your operating system, your router, and especially in resolvers.
Every DNS record carries a TTL (time to live), measured in seconds. It means: “you may remember this answer for this long.”
bunny.net. 300 IN A 79.127.237.104
└── cache me for 5 minutesA resolver that just answered this question for someone else will answer it for you instantly, straight from cache, without asking anyone.
TTLs are a trade-off you control:
A common trick: run a long TTL normally, then drop it to 60 seconds before a planned migration. Once caches have picked up the short TTL, your actual change will be noticed everywhere within a minute.
This is also what “DNS propagation” really is. Your change is live on your nameserver the instant you save it, and nothing gets pushed anywhere afterwards. The “delay” is old answers sitting in caches around the world, waiting for their TTLs to expire.
First, a word you’ll see on every DNS dashboard: zone.
A zone is the slice of the tree that one party actually manages. Its records live together in one place, under one authority. Chapter 2 said nobody owns the whole tree. Zones are how it’s carved up. The root is a zone. net is a zone. When you register bunny.net, you get a zone of your own.
A domain is a name, a zone is a unit of management, and the two don’t have to line up. docs.bunny.net is part of the bunny.net domain, but you could delegate it, with NS records, into a separate zone run by someone else entirely. That’s the same delegation trick from Chapter 3, just happening inside your own domain. Most of the time, though, one domain = one zone, and “add a zone” in a DNS dashboard means “start managing records for this domain”.
And a zone is basically a small database of records. Each record has a name, a type, a TTL and a value. You only need to know a handful of types.
A: maps a name to an IPv4 address.
bunny.net. IN A 79.127.237.104AAAA: same thing, but IPv6. (Four A’s because IPv6 addresses are four times longer.)
bunny.net. IN AAAA 2400:52e0:1e03::1205:1CNAME: an alias. “This name is really that other name.”
dash.bunny.net. IN CNAME panel-production.b-cdn.net.One famous rule: a name with a CNAME can’t have any other records. That’s why you traditionally can’t put a CNAME on the apex (bunny.net itself, which needs SOA and NS records), and why DNS providers invented workarounds with names like ANAME, ALIAS or CNAME flattening.
MX: where email for this domain should be delivered. The number is a priority, lower wins.
bunny.net. IN MX 1 aspmx.l.google.com.
bunny.net. IN MX 5 alt1.aspmx.l.google.com.TXT: arbitrary text. In practice, that means proving domain ownership and email authentication (SPF, DKIM, DMARC live here).
bunny.net. IN TXT "v=spf1 mx ~all"NS: names the servers that are authoritative for a zone. These records are the delegation mechanism from Chapter 3.
bunny.net. IN NS coco.bunny.net.
bunny.net. IN NS kiki.bunny.net.SOA: start of authority. Zone metadata: a serial number, refresh timers, the admin contact. Every zone has exactly one. You’ll rarely touch it, but it’s how secondary servers know when a zone has changed.
Two more you’ll bump into eventually: PTR does the reverse trick, mapping an IP address back to a name (mail servers check these a lot), and SRV is like MX but for other services, telling clients which host and port to find them on.
That’s nine types. There are over forty more, and you can ignore nearly all of them. If CAA crosses your path, it lists which certificate authorities are allowed to issue certificates for your domain; HTTPS is a newer type that carries connection hints and finally gives the apex CNAME problem a proper fix. The DNSSEC ones turn up in Chapter 9. Beyond that, these nine cover 95% of real life.
Four roles keep getting confused:
The registry runs a TLD. Verisign runs com. They maintain the master list of who owns what under that TLD.
The registrar sells you the domain. Namecheap, IWantMyName, GoDaddy. They talk to the registry on your behalf.
The DNS host runs the authoritative nameservers that answer queries for your zone. Often bundled with your registrar, but it doesn’t have to be. You point NS records wherever you like.
The resolver does lookups on behalf of users. Your ISP runs one, and so do Google (8.8.8.8) and Quad9 (9.9.9.9).
The most common real-world confusion is people editing records at their registrar while their NS records point at a different DNS host entirely. The records they’re editing are never consulted. If a change seems to have no effect at all, not even after TTLs expire, check where the NS records actually point first.
One tool debugs nearly everything: dig.
Look up a record:
$ dig bunny.net A +short
79.127.237.104Ask a specific server, bypassing all caches. This is how you check what your authoritative nameserver really says, right now:
$ dig @kiki.bunny.net bunny.net ASee a domain’s nameservers:
$ dig bunny.net NS +shortWatch the entire resolution walk from the root, step by step, exactly like Chapter 3:
$ dig bunny.net +traceA debugging recipe that solves most “my DNS change isn’t working” problems:
dig @your-nameserver name type: is the record correct at the source?dig name type: what does your resolver’s cache say?A few things that bite everyone eventually.
Negative caching. Resolvers cache “that record doesn’t exist” answers too. If you query a name before creating the record, the NXDOMAIN gets cached, and your freshly created record appears broken. Create first, query second.
The apex CNAME trap. Covered in Chapter 5, causes real outages. If your provider offers CNAME flattening or ALIAS records, use them at the apex.
Trailing dots in zone files. In raw zone files, mail.bunny.net. (with dot) is absolute. mail (without) gets the zone name appended. Forget the dot on an absolute name and you’ve created mail.bunny.net.bunny.net. Every network engineer or web developer has done this once.
UDP, mostly. DNS runs primarily over UDP port 53 for speed, falling back to TCP for large answers and zone transfers. Firewalls that allow UDP/53 but block TCP/53 cause weird, intermittent failures.
Registry holds. If a domain stops resolving everywhere, with the records themselves untouched, check its status with whois. A clientHold (set by the registrar) or serverHold (set by the registry) means the domain has been pulled from the TLD zone, usually over unpaid renewals, unverified contact details or abuse reports. No record edit will fix it. Sort it out with your registrar.
DNS is public. Anyone can query your records. Never put secrets in TXT records, and assume your subdomains can be enumerated.
Classic DNS trusts everyone. Answers arrive unauthenticated and unencrypted. DoH (DNS over HTTPS) and DoT (DNS over TLS) encrypt the path between you and your resolver so it can’t be snooped, and DNSSEC signs the answers themselves so they can’t be forged. That one gets its own chapter, next.
Everything in this book so far rests on an uncomfortable assumption. DNS was designed in the 1980s, when the internet was small and everyone mostly trusted each other. There’s no built-in way to verify that a DNS answer actually came from the right server. Your resolver asks a question, something answers, and it believes whatever comes back.
An attacker who can slip a fake answer into that conversation can send you to their server instead of the real one, and thanks to caching, one poisoned answer can sit in a resolver’s cache misdirecting everyone who asks. The attack is called cache poisoning.
DNSSEC fixes this with digital signatures: every answer from a signed zone comes with one, and your resolver checks it before believing anything.
You don’t need the cryptographic details. Three new record types make it work:
com holds a fingerprint of example.com’s key (a DS record), the root holds a fingerprint of com’s key, and so on up the tree.This is called the chain of trust, and it ends at the root zone, which is signed at the Root Signing Ceremony, a public, audited event where trusted people from around the world gather to sign the root keys. The whole internet’s DNS trust bottoms out in a room with witnesses.
DNSSEC validation walks the same root → TLD → domain path as the lookup in Chapter 3, checking a signature at every step.
Two things worth knowing:
DNSSEC doesn’t encrypt anything. Queries and answers are still visible to anyone watching the wire. If you want privacy, that’s DoH and DoT’s job (Chapter 8).
It’s opt-in, per zone. If a domain hasn’t enabled it, there’s nothing to verify. In practice, turning it on usually means one switch at your DNS host and pasting a DS record at your registrar. The signing, key management and re-signing happen behind the scenes.
dig answers every question. +short for answers, @server to skip caches, +trace to watch the walk.That’s DNS. It’s a phone book with really good caching.
The DNS in this book so far has been a lookup. A server stores records, a query arrives, the server finds the matching record and sends it back.
bunny.net? → look up the record → 79.127.237.104That’s how DNS has worked for decades. The records might change over time, but by the time the question arrives, the answer is already sitting there waiting. Most of the internet still works exactly this way.
You’ll sometimes hear the term Dynamic DNS (DDNS), but that’s something older and smaller, records that update themselves. Your ISP changes your home IP address overnight, a little client notices and rewrites your A record. The lookup itself hasn’t changed at all: DNS still returns a record from a database, the database just keeps itself up to date.
Some DNS providers have dropped that assumption: the answer doesn’t have to exist until someone asks for it.
bunny.net? → run your code → whatever it decidesInstead of reading a record from a database, the authoritative nameserver runs code you wrote. bunny.net calls this Scriptable DNS. Full disclosure, I work there, but other providers have their own take on the same idea. Nothing about the protocol changes. Resolvers ask the same questions, clients receive ordinary DNS responses. The only difference is how the answer was made.
The point of computing an answer rather than storing one is that the right answer can depend on who’s asking. This script sends Australian visitors to a nearby server and everyone else to Europe:
export default function handleQuery(query) {
if (query.request.geoLocation.country == "AU") {
return new ARecord("203.0.113.7", 300);
}
return new ARecord("79.127.237.104", 300);
}The same trick covers a lot of ground. A script can send a customer on a beta programme to the new deployment, or swap a failed origin for a healthy one. It can even serve thousands of customer subdomains without storing a record for each.
Caching still works too. That 300 in the script is an ordinary TTL, so resolvers cache the answer exactly as they always have: return five minutes if the answer is stable, thirty seconds if it isn’t. The intelligence lives entirely inside the authoritative nameserver, and to everyone asking, it looks like ordinary DNS.
DNS has spent most of its history as a distributed phone book with really good caching, and Scriptable DNS doesn’t change that. The phone book still answers your questions; it just thinks for a moment before it replies.
DNS is one piece of a much larger system.
This book answered one question: how does a name become an IP address? The questions next door are just as interesting. How does someone come to own a domain in the first place? How does your browser know it’s talking to the real server? How does a request actually find its way across the internet?
I’ve already been living with those questions, in a DNS CLI I’ve been building that handles certificates, and in years of wrestling with Let’s Encrypt. I just haven’t put pen to paper yet. If I do, those books will follow the same rule as this one and try to explain one idea in as few words as possible, without assuming you already know the jargon.
Thanks for reading.
If twenty minutes wasn’t enough, these go deeper:
root-servers.org, a live map of every root server instance on the planet, letter by letter. Worth a minute just to see how many are near you.
The ghost domain problem, from the monitoring service Oh Dear. A deleted domain can keep resolving for days because caches hold on to stale delegations, which means your uptime checks won’t notice a thing. A good introduction to why DNS monitoring exists.
Why was my domain suspended?, Namecheap’s guide to serverHold, clientHold and the other registry statuses from Chapter 8.