DNS: Explanation & Insights

The internet's phone book: it turns names you can remember into addresses machines can route.

What It Is

DNS — the Domain Name System — is the service that turns a name like example.com into an address like 93.184.216.34 (IPv4) or 2606:2800:220:1:248:1893:25c8:1946 (IPv6). Humans remember names; the network only routes IP addresses. DNS is the translation layer between the two, and it runs underneath nearly everything else you do on a server. Before your browser can speak HTTP, before ping can send a packet, before a mail server can deliver to you, something has to ask "what's the address for this name?" — and the thing that answers is DNS.

The phone-book analogy is the right starting point, but it undersells the scale. There is no single book. DNS is a vast, distributed, hierarchical database spread across millions of servers worldwide, with no central master copy, designed in the early 1980s to replace a literal text file (HOSTS.TXT) that one person at Stanford updated by hand and everyone else downloaded. It has scaled from a few hundred hosts to a few billion without ever needing a rewrite, which is one of the quiet engineering marvels of the internet.

If you're new to running servers, here are the two things to internalise right at the top. First: almost every "the site is down" panic that turns out not to be the site is DNS. The connection works, the server is healthy, the code is fine — but a name isn't resolving, or it's resolving to the old address, and so nothing connects. Second — and this is the one that bites everyone exactly once — DNS changes don't take effect when you make them. They take effect when the caches expire. That gap, measured in minutes or hours, is the source of more confusion than any other single thing in networking. We'll nail it cold below.

The rest of this page walks the full resolution chain from your server out to the authoritative source, lays out every record type you'll actually meet, explains TTL and caching properly, shows you where Linux keeps its DNS config, and teaches you to inspect all of it with dig. By the end you'll be able to read a DNS answer, tell truth from a stale cache, and migrate a server without the dreaded hour of "it works for me but not for them."

Why It Matters

DNS is the most load-bearing piece of infrastructure that nobody thinks about until it breaks. When it does break, the failure is rarely loud — it's a slow, sideways kind of broken. A page that takes thirty seconds and then loads is often DNS timing out on the first resolver and falling back to the second. An email that bounces "domain not found" when the domain plainly exists is usually a DNS record that's missing or mistyped. A TLS handshake that connects to the wrong host is a name pointing at a stale address. None of these say "DNS" in the error message — which is precisely why "it's always DNS" became the most-quoted joke in operations.

It matters for what you can do with it, too. Because a name and an address are decoupled, you can move a service to a new server, swap a failed box, or shift to a different cloud — all without anyone changing a bookmark. You can point one name at several addresses for crude load balancing and redundancy. You can run a dozen sites on one IP, the web server picking the right one from the name the browser sends. Every bit of that flexibility flows from one idea: the name your users type and the address your packets go to are two separate things, joined only by a DNS lookup that happens fresh (or from cache) on demand.

And for monitoring: if DNS is slow or wrong, every check downstream of it looks broken even when nothing else is. A site monitor that suddenly can't reach a perfectly healthy server is, more often than you'd guess, watching a DNS problem wearing an HTTP costume.

The Resolution Chain

When your server needs the address for www.example.com, the answer travels through a small relay of specialists, each knowing only a little and passing you toward the one that knows everything. Here's the journey, in order.

1. The stub resolver — a tiny piece of the C library on your own machine (getaddrinfo()). It doesn't do the legwork; it just formats the question and hands it to a recursive resolver, then waits. This is what your application actually calls.

2. The recursive resolver — usually run by your ISP, your cloud provider, or a public service (1.1.1.1, 8.8.8.8). This is the workhorse. It accepts "tell me the address for www.example.com" and takes on the entire job of finding out, asking other servers on your behalf and caching what it learns. Most of the time it already has the answer cached and replies in a millisecond.

3. The root servers — if the resolver has nothing cached, it starts at the top. The 13 named root server clusters (a.root-servers.net through m) don't know example.com, but they know who runs .com. They reply: "I don't have it, but ask the .com servers — here's where they are."

4. The TLD servers — the servers for the top-level domain .com. They don't know the address of www.example.com either, but they know which name servers are authoritative for example.com. They reply with a referral: "ask ns1.example.com."

5. The authoritative server — the name server that actually holds the records for example.com. This is the source of truth, the one place the answer genuinely lives. It replies with the real address, the resolver caches it and hands it back down the chain, and your application finally connects.

Notice the shape: the recursive resolver does all the walking; the root and TLD servers only ever refer you onward; the authoritative server is the only one that gives a real answer. This is why an authoritative query is the one you trust — more on that under How I Inspect It.

Note

The root and TLD servers don't get hammered for every lookup on earth, despite handling a name space of billions. The reason is caching at the recursive layer plus long TTLs on the referrals themselves — your resolver learns "the .com servers are over there" once and reuses it for two days. The whole system survives on the fact that the upper layers change rarely and are cached aggressively.

The Record Types

A DNS zone is a collection of records, each a typed answer to a particular question about a name. You'll meet a handful constantly and the rest occasionally. Here are the ones worth knowing:

A few things to know that the table can't carry. A and AAAA are the bread and butter — the actual name-to-address mappings. A CNAME is an alias: it says "this name is really that name, go look that up instead," and a classic trip-wire is that a name with a CNAME cannot also have other records (no MX, no TXT at the same name) — the alias is exclusive. MX records carry a priority number (lower wins) so mail can fail over to a backup. TXT is the junk drawer that ended up running half of email security — SPF, DKIM, and DMARC all live in TXT records, as does the "prove you own this domain" token every SaaS asks you to add.

PTR is the odd one: it runs the lookup backwards, from address to name, using the special in-addr.arpa (IPv4) and ip6.arpa (IPv6) trees. It's what a receiving mail server checks to see whether your sending IP honestly claims to be who it says — which is why a missing PTR (reverse DNS) is a common reason your perfectly legitimate email lands in spam. And the SOA (Start of Authority) record is the zone's birth certificate: it names the primary server, the responsible contact, and a set of timers including the all-important serial number that secondary servers watch to know when to re-copy the zone.

TTL, Caching, and Why "It's Always DNS"

This is the section to read twice. Every DNS record carries a TTL — Time To Live — a number of seconds that says "you may cache this answer for this long before asking again." A record with a TTL of 3600 may be remembered for an hour; one with 300 for five minutes. And the answer gets cached at every layer it passes through: your application, your stub resolver, the recursive resolver, sometimes the OS, sometimes the browser. Each holds its copy until its own copy of the TTL counts down to zero.

Now the consequence that catches everyone. When you change a DNS record, nothing happens to the caches that already hold the old value. They keep serving the stale answer, confidently and correctly by their own rules, until their TTL expires. You changed the source of truth; you did not reach into a million caches around the world and update them. So for up to one TTL's worth of time, half the internet sees your new value and half still sees the old one — and which half you land in depends entirely on which resolver you happen to ask and what it cached and when.

This is the mechanism behind the meme. "It's always DNS" isn't because DNS is fragile — it's rock solid. It's because DNS changes are invisible until caches expire, and that delay desynchronises your mental model ("I fixed it five minutes ago") from reality ("most of the world won't see the fix for another hour"). You stare at a working change that the world insists is broken, and the culprit is a cache somewhere still answering the old value. Nine times out of ten that's the whole story.

So here's the discipline that separates a smooth migration from a painful one:

• Lower the TTL before a planned change, not during it. If you're moving a server next Tuesday, drop the record's TTL to 300 (or 60) the day before — give the old, long TTL time to age out of every cache. Then when you flip the address on Tuesday, the world catches up in five minutes instead of a day. Raise the TTL back afterward.
• Understand that propagation is not a push — it's expiry. Nobody broadcasts your change. The phrase "DNS is propagating" really means "old cached copies are expiring at their own pace." There's nothing to speed up except the waiting, and the only knob you had was the TTL — which you needed to turn before the change, not after.

Pro Tip

When a change "isn't taking," stop guessing and ask the source directly. Query the authoritative server by name — dig @ns1.example.com www.example.com — to see the actual current truth, then query your normal resolver and compare. If the authoritative server shows the new value and your resolver shows the old one, you've found your culprit in one line: it's a stale cache, and you just need to wait out the TTL.

How I Inspect It

My default tool is dig — "domain information groper" — because it shows you exactly what came back, with the TTLs, in a form that maps one-to-one onto how DNS actually works. The newer host is a friendlier short form for quick checks, and nslookup is the old cross-platform standby (fine, but its output hides detail dig shows). I reach for dig ninety-five times out of a hundred.

The simplest lookup, and the shape of the answer:

dig example.com

;; ANSWER SECTION:
example.com.		3578	IN	A	93.184.216.34

Read that line left to right: the name, the TTL remaining in cache (3578 — counting down from 3600, so this resolver fetched it 22 seconds ago), the class (IN, internet, always), the record type (A), and the value. That ticking TTL is the single most useful number on the line — it tells you the answer is cached and how stale it might be.

The moves I use constantly:

dig example.com              # the default A-record lookup
dig +short example.com       # just the answer, nothing else
dig AAAA example.com         # ask for the IPv6 address
dig MX example.com           # who handles this domain's mail
dig TXT example.com          # SPF/DKIM/verification records
dig NS example.com           # which servers are authoritative
dig -x 93.184.216.34         # reverse lookup (PTR) for an address
dig @1.1.1.1 example.com     # ask a SPECIFIC resolver
dig @ns1.example.com example.com   # ask the AUTHORITATIVE server — the truth
dig +trace example.com       # walk the whole chain root → TLD → authoritative yourself

The two that earn their keep when something's wrong are the last three. dig @<resolver> lets you compare what different resolvers are currently caching — invaluable when "it works for me" and you need to prove it doesn't work everywhere. dig @ns1.example.com asks the authoritative server directly, bypassing every cache, so you see the genuine current record. And dig +trace makes dig do the recursive resolver's whole job in front of you — root, then TLD, then authoritative — printing each referral, which is the best way there is to watch the resolution chain instead of just reading about it.

Where DNS Lives on Linux

Your Linux server resolves names through a small stack of files, and knowing them turns "DNS isn't working" from a mystery into a checklist.

/etc/resolv.conf is the list of recursive resolvers your machine will ask, one nameserver line each, tried in order:

nameserver 1.1.1.1
nameserver 8.8.8.8
search example.com

The search line lets you type a short name (web01) and have the resolver try web01.example.com automatically. One catch worth knowing: on most modern distros /etc/resolv.conf is generated — by systemd-resolved, NetworkManager, or your DHCP client — so editing it by hand often gets silently overwritten on the next reboot or lease renewal. Follow the symlink and find out who owns it before you fight it.

/etc/hosts is the original, pre-DNS lookup table — a plain file mapping names to addresses, the lineal descendant of that 1980s HOSTS.TXT. It's tiny, it's local, and on most systems it's checked before DNS:

127.0.0.1   localhost
10.0.0.5    db-internal

This is your override switch. Add a line here and that name resolves to that address for this machine only, no DNS involved — perfect for testing a migration ("does the site work on the new IP before I change the real record?") or pinning an internal name. It's also a foot-gun: a forgotten /etc/hosts entry pointing a name at the wrong box will quietly override DNS forever, and it's the last place anyone thinks to look.

What decides whether /etc/hosts or DNS wins, and in what order, is /etc/nsswitch.conf:

hosts:	files dns

files dns means "check /etc/hosts first, then fall back to DNS" — the near-universal default. That single line is why the /etc/hosts override works at all, and why it always wins.

Gotchas

• The dangling CNAME. Point a CNAME at a name that later disappears (a cloud bucket you deleted, an old load-balancer hostname) and you've handed an attacker a "subdomain takeover" — they register the now-free target and inherit your name. Audit your CNAMEs; delete the ones whose targets are gone.
• Forgetting the trailing dot. In a zone file, mail.example.com (no dot) means mail.example.com.example.com. — the zone gets appended. The trailing dot makes a name absolute. Leaving it off is a classic and maddening zone-file bug.
• /etc/hosts overrides you forgot. Before blaming DNS, grep the name in /etc/hosts. A stale entry there beats any record you set in the actual zone, on this machine, silently.
• Resolver vs. authoritative confusion. "But dig shows the new value!" — check which server answered. Your resolver's cache and the authoritative record can disagree for a full TTL. Always settle the argument with dig @ns1.example.com.
• TTL set too high before a migration. A record sitting at a one-day TTL means a one-day tail of clients seeing the old address after you change it. Lower it before you need to move, or wear the consequences.

History and Philosophy

In the early ARPANET, every host's name-to-address mapping lived in a single file, HOSTS.TXT, maintained by Elizabeth Feinler's team at Stanford Research Institute and downloaded by every machine on the network. It worked beautifully — for a few hundred hosts. By 1983 the network was growing faster than one file (and one team) could keep up, and the whole thing was visibly about to collapse under its own success. Paul Mockapetris, at USC's Information Sciences Institute, designed DNS as the replacement, laid out in RFC 882 and 883 (later superseded by the famous 1034/1035 pair). The brief was brutal: replace a central file with something distributed, delegated, and cacheable, that could scale without bound and without a single bottleneck.

The design choices that made it work are the ones we still lean on every day. Delegation: no server has to know everything; each layer knows only who to ask next, so authority for example.com can be handed to whoever runs it without the root knowing or caring. Caching with TTLs: the same property that makes the system fast is the one that makes changes lag — you can't have the speed without the staleness, and the TTL is the dial that trades one for the other. A single global namespace with no central owner, which is why DNS has survived every scale jump from hundreds of hosts to billions without a redesign.

DNS rides almost entirely on UDP — a single small question, a single small answer, no connection setup, classically on port 53. It falls back to TCP when an answer is too big for one packet (large record sets, DNSSEC signatures, or a zone transfer). For its first few decades it was also entirely unauthenticated and unencrypted — you trusted whatever answer came back, which is the gap DNSSEC (signed answers) and DNS over HTTPS/DNS over TLS (encrypted queries, riding HTTPS) were built to close. The protocol from 1983 is, remarkably, still the protocol from 1983 — bolted-on security and all, it's the same elegant skeleton, and it has never once needed to be thrown out and started over. For a system designed to replace a text file, that's a hell of an innings.

See Also

• protocol — what a network protocol is, and where DNS sits among them
• OSI model — the layered map DNS rides on top of
• UDP — the lightweight transport DNS uses for almost every query
• TCP — the fallback for big answers and zone transfers
• HTTP — the thing you usually want after a name resolves
• HTTPS — encrypted HTTP, and what DNS over HTTPS rides on
• NAT — how private addresses reach the public internet DNS points at
• NTP — the other quiet timekeeper your server can't live without
• dig — the DNS query tool I reach for first
• host — the friendly short form for quick lookups
• nslookup — the old cross-platform standby
• ping — the first thing you run that quietly depends on DNS
• DNS issue — when resolution fails, times out, or returns the wrong answer
• HTTPS monitor down — when the cause is a name not resolving

Is a stale DNS record quietly sending your users to a server that no longer exists?

CleverUptime watches your endpoints from the outside and flags the moment a name stops resolving or your site stops answering, so you catch a broken DNS change while it's still a dashboard alert and not a flood of support tickets.

Want to see your own server's health right now? One command, no signup, no install.

Check your server →