There's a little haiku that sysadmins love, and it goes roughly like this: It's not DNS. There's no way it's DNS. It was DNS.

It's funny because it's painfully accurate. The new server is up, the site works on your laptop, your colleague gets an error, the client sees the old site, and tomorrow morning everything is fine and nobody changed anything. That's not haunted infrastructure. That's caching, and once you see how DNS really works, the "mystery" mostly disappears.

The job DNS does

Computers talk to IP addresses. Humans remember names. DNS (the Domain Name System) is the giant, distributed phone book that turns app.example.com into something like 203.0.113.10.

The key word is distributed. There's no single phone book. The answer is spread across many servers, each responsible for one slice of the name, and everyone in the chain is allowed to remember answers for a while. That last part is the source of nearly every DNS headache.

Following one lookup

When your browser needs app.example.com and nothing has it cached, the request goes on a small trip:

1. Your machine asks a recursive resolver. Usually your ISP's, your office router's, or a public one like 1.1.1.1 or 8.8.8.8. This resolver does the legwork for you.
2. The resolver asks a root server: "Who handles .com?" The root doesn't know the answer, but it knows who to ask next.
3. The resolver asks a .com TLD server: "Who handles example.com?" The TLD server replies with the domain's nameservers, the ones set at your registrar.
4. The resolver asks the authoritative nameserver: "What is app.example.com?" This is the server that actually holds your records (Route 53, Cloudflare, your hosting provider). It gives the real answer.
5. The resolver caches the answer and returns it to you.

Think of it like asking for directions in a city you don't know. The first person says "ask at the train station", the station says "the office on the second floor knows", and the office gives you the actual address. The resolver is the friend who does all that walking and then remembers the address for next time.

TTL: how long everyone remembers

Every DNS record comes with a TTL (time to live) in seconds. It tells resolvers how long they may cache the answer before asking again.

$ dig app.example.com A +noall +answer
app.example.com.   3600   IN   A   203.0.113.10

That 3600 means "you can reuse this for an hour". And it's not only the resolver that caches. Your operating system caches, your browser caches, and some applications (and some runtimes) cache their own lookups too.

There's also negative caching: if a resolver asks for a record that doesn't exist yet, it can remember the "doesn't exist" answer for a while too, based on the zone's SOA settings. So checking your new subdomain before you create it can make it look broken for a while after you create it. Classic.

The propagation myth

You've seen the message: "DNS changes can take up to 48 hours to propagate." It makes it sound like your change is slowly spreading across the internet, server by server.

That's not what happens. When you update a record, the authoritative nameserver has the new value almost immediately. Nothing is pushed anywhere. What you're waiting for is every cache that already holds the old answer to expire. A resolver that cached your record with a one-day TTL ten minutes ago will keep serving the old IP for most of a day, and it's entirely within its rights.

That explains every "works for me, not for them" moment: you and your colleague are using different resolvers with different cache ages.

Debugging DNS like you mean it

When something smells like DNS, stop refreshing the browser and ask the servers directly. dig is the tool I reach for (on Windows, nslookup works too):

# What does my usual resolver say?
dig app.example.com

# What does a specific public resolver say?
dig @1.1.1.1 app.example.com

# What does the authoritative server say? (the source of truth)
dig NS example.com +short
dig @ns1.your-dns-provider.com app.example.com

# Walk the whole chain from the root
dig app.example.com +trace

# Windows equivalent of asking a specific resolver
nslookup app.example.com 8.8.8.8

The logic is simple. If the authoritative server gives the new answer and your resolver gives the old one, the record is right and you're waiting on a cache. If the authoritative server gives the wrong answer, you changed the record in the wrong place, which happens more than anyone admits, especially when the registrar points at a different DNS provider than the one you're editing.

Other usual suspects

• Nameservers at the registrar point somewhere else than the dashboard you're editing.
• A CNAME at the root domain, which the DNS standards don't allow next to the other root records. Providers offer workarounds (ALIAS or flattening), but plain CNAME at the apex causes trouble.
• Local overrides in the hosts file that you added months ago for testing and forgot. I use a hosts entry for local development all the time, so I check this one first.
• Email problems that are really missing or wrong MX, SPF or DKIM records.

The short version

• A lookup goes resolver, root, TLD, authoritative, and gets cached at every step.
• TTL decides how long old answers live. Lower it before migrations.
• "Propagation" is really cache expiry.
• Ask the authoritative server directly before you believe anything else.

What's the strangest problem you've chased that turned out to be DNS in the end?