What DNS is, fast

DNS is the system that turns names humans can read into addresses machines can route. When a client types acme.com into a browser, DNS is what gets them to the right server. When their mail flows in or out, DNS is what tells the world where to deliver it.

The resolution path matters more than most techs think, because it explains every confusing thing DNS will do to you. Here’s the chain.

The four roles in a DNS lookup

1. Stub resolver — the small piece of code on the client laptop (or on the firewall, or in the application) that asks the question. It does no resolution work itself; it just hands the question to a recursive resolver and waits.

2. Recursive resolver — the workhorse. Usually run by an ISP, a public service (Cloudflare’s 1.1.1.1, Google’s 8.8.8.8), or the client’s own infrastructure. It does the actual work of walking the hierarchy until it has an answer. It caches aggressively.

3. Authoritative nameservers — the servers that hold the definitive records for a zone. For acme.com, the authoritative nameservers are whatever the registrar has listed in the parent zone (usually two or four name servers run by the DNS host).

4. Root and TLD nameservers — the top of the hierarchy. The recursive resolver starts here when it doesn’t have a cached answer. Root nameservers point to TLD nameservers (.com, .org, etc.), which in turn point to the authoritative nameservers for the specific domain.

What this looks like in practice

A laptop asks “what’s the IP for acme.com?” The chain runs roughly like this:

1. Stub resolver asks the recursive resolver.
2. Recursive resolver checks its cache — if it has a fresh answer, returns it immediately. (This is most lookups.)
3. If no cache: asks a root nameserver, gets pointed to .com‘s nameservers.
4. Asks a .com nameserver, gets pointed to acme.com‘s authoritative nameservers.
5. Asks one of those authoritative nameservers, gets the actual A record.
6. Returns the answer to the stub resolver and caches it for the duration of the record’s TTL.

Most lookups in production never go past step 2. That’s why DNS feels fast — the recursive resolver’s cache absorbs the work.

Why “DNS hasn’t propagated” is really a caching story

Clients say this constantly after a DNS change. The truth: DNS itself propagates almost instantly — the authoritative nameservers updated the moment the change was saved. What hasn’t expired is the cached answer at every recursive resolver between the client and the authoritative servers.

If the TTL on the old record was 3,600 seconds (one hour) and the record was cached 50 minutes ago at the resolver the client is using, the change won’t be visible to that client for another 10 minutes — no matter how many times you’ve checked it from your own machine.

This is also why we lower TTLs before planned cutovers. If the MX TTL is 60 seconds for the 24 hours before a mail migration, the world re-fetches the record at most once a minute. After the cutover, the old record disappears from every cache within a minute.

What you should remember

• DNS is hierarchical. The chain is: stub → recursive → root → TLD → authoritative.
• Recursive resolvers cache. Most “DNS problems” are cache problems.
• TTL controls cache duration. Lower it before a change you want to roll out fast.
• The authoritative server is the source of truth. When you debug, query the authoritative directly with dig +trace.

Next lesson covers the records themselves — what each record type signals and which ones matter for our work.

---

Cathedra alignment: foundational — context for every check in Examen