How DNS actually works (and why it breaks your deploys)

DNS is the internet's contact list. Understanding the lookup chain (and the one word, TTL) explains a shocking number of production incidents.

When you type a website name, your computer has a problem: it can't talk to names, only to numbers (IP addresses). DNS is the system that turns one into the other. Think of it as the internet's contact list — you know “Mom,” your phone knows the number.

It's a chain, not a server

The big misconception is that DNS is “a server you ask.” It's actually a cached chain of lookups, and the caching is the whole point:

• Your browser cache — heard this name recently? Done.
• Your OS cache — same question, slightly wider.
• A recursive resolver (your ISP, or 8.8.8.8 / 1.1.1.1) — the one that does the real legwork.
• If nobody knows, the resolver walks the hierarchy: root servers → the .com servers → the domain's own authoritative name server, which finally returns the IP.

Why you should care: TTL

Every DNS answer is cached for a duration called its TTL (time to live). This is the source of a classic incident: you point your domain at a new server, it works for you, but some users still hit the old one for hours. They're not broken — their resolver cached the old record and the TTL hasn't expired. Lower your TTL before a migration, raise it after.

“It works on my machine but not for that user” is, more often than people admit, a stale DNS cache somewhere in the chain.

You can get far as a developer without this. But the day a deploy “half-works,” DNS is one of the first three things to check — and now you'll know where to look.