Understanding DNS: How the Internet's Phonebook Actually Works

Every web request, every email, every API call you make starts with a DNS lookup. DNS is one of the few internet protocols that has stayed roughly the same since 1983 — and the parts that frustrate people today are usually the same parts that have always been quirky.

What DNS actually does

DNS turns a name like example.com into an IP address like 93.184.216.34. Computers route on numbers; humans remember names. DNS is the translation layer in between, and it's distributed by design — no single server holds the whole map of the internet.

Anatomy of a lookup

When your laptop asks for example.com, four kinds of servers are usually involved:

Stub resolver — the bit of code in your operating system that hands the query off to a configured resolver.
Recursive resolver — the resolver your ISP, network, or a public service like 1.1.1.1 runs. It does the legwork.
Root and TLD servers — the recursive resolver asks the root for "where do I find .com?", then asks the .com servers for "where do I find example.com?"
Authoritative server — the server you (or your DNS provider) configured holds the actual answer. It returns the record.

Each layer caches the answer for a duration controlled by the record's TTL. Once a layer has the answer cached, future queries for the same name skip the upstream lookups until the TTL expires.

The record types you'll meet

A — maps a name to an IPv4 address.
AAAA — maps a name to an IPv6 address.
CNAME — an alias from one name to another. Cannot coexist with other records at the same name and is forbidden at the zone apex (the bare example.com).
MX — tells the world which servers receive email for the domain, with a priority value.
NS — the authoritative nameservers for the domain. The values at your registrar must match the values inside your zone — mismatches cause "lame delegation" issues.
TXT — arbitrary text. Used for SPF, DMARC, domain-ownership tokens, and DKIM (under selector subdomains).
SOA — metadata about the zone itself: serial number, refresh interval, and minimum TTL.

TTL, propagation, and why your change "isn't working yet"

Every record carries a TTL (time to live) in seconds. When a recursive resolver caches an answer, it serves that cached copy until the TTL counts down. So when you change a record at your registrar, every cached copy at every resolver continues to serve the old value until its TTL expires. There is no central event that pushes your update to the world — it spreads as caches refresh.

Practical consequences:

Lower the TTL before a planned change, not at the same time. Lowering TTL takes one full TTL cycle to take effect.
"Propagation" is the wrong mental model. There's no propagation, only cache expiry. Use a tool like DNS Checker to see what each region is currently caching.
Browsers and operating systems also cache DNS independently, so a "stale" answer on your laptop doesn't mean the rest of the internet is stale.

Common pitfalls

CNAME at the apex. You cannot put a CNAME on example.com — only on subdomains. Some providers offer "ALIAS" or "ANAME" records that flatten this for you, but plain CNAME there is invalid.
Multiple SPF records. Per RFC 7208, a domain may publish only one v=spf1 TXT record. A second one breaks the policy entirely. Combine them into one record using include: mechanisms.
NS mismatch. The NS records at your registrar (the parent zone) and inside your zone must agree. Mismatches cause intermittent resolution failures that are notoriously hard to diagnose.
Forgetting AAAA. Many providers default to IPv4-only. If you publish only an A record, IPv6-preferring clients still work, but you miss out on shorter paths and modern transport features.

Tools to keep handy

DNS Checker shows you what different regions are caching. DNS Lookup dumps every common record type for a domain at once. MX Record Lookup drills into mail records and pulls SPF + DMARC alongside. When something looks off, start there before assuming a deeper bug.