Networking · DNS

DNS — the Internet’s Phonebook

How example.com becomes 93.184.216.34 — resolution, record types, caching, and what TTL really controls.

Networking Basics → Interview
01

The Problem DNS Solves

Machines route by IP address; humans remember names. DNS (Domain Name System) is a distributed, hierarchical database mapping names to records. No single server holds it all — authority is delegated down the name: root knows who owns .com, .com knows who owns example.com, and example.com’s authoritative servers hold the actual records.

Read a domain right-to-left to see the hierarchy: api.shop.example.com → root → com → example → shop → api.
02

Resolution — Recursive vs Iterative

Your device asks a recursive resolver (your ISP’s, or 1.1.1.1 / 8.8.8.8) and waits. The resolver does the legwork iteratively: ask root, follow the referral to the TLD, follow again to the authoritative server, cache everything, return the answer.

Your device Recursiveresolver + cache Root ( . ) TLD (.com) Authoritativeexample.com 1 2 → “ask .com” 3 → “ask ns1” 4 → A record 5 answer

Next time anyone asks the same resolver, steps 2-4 are skipped — the answer comes from cache until its TTL expires.

03

Record Types You Must Know

RecordMapsExample use
Aname → IPv4example.com → 93.184.216.34
AAAAname → IPv6example.com → 2606:2800::c
CNAMEname → another namewww → example.com (alias)
MXdomain → mail serverwhere email for @example.com goes
NSzone → authoritative serversdelegation glue of the hierarchy
TXTname → arbitrary textSPF, domain verification
TTL is a promise, not a suggestion: resolvers may serve a cached record until TTL runs out. Lower TTL before a migration (hours ahead), or old IPs keep receiving traffic long after you flip the record.
04

Interrogate DNS Yourself

bash — dig
# full answer with TTLs
dig example.com A

# trace the whole delegation chain root → TLD → authoritative
dig +trace example.com

# ask a specific resolver; check propagation
dig @1.1.1.1 example.com

# reverse lookup: IP → name
dig -x 93.184.216.34

dig +trace is the single best way to see the hierarchy: it starts at the root servers and follows each referral exactly like a resolver does.

05

Interview Questions

Walk me through what happens on a DNS lookup.

Stub resolver checks local cache → asks the configured recursive resolver → resolver (on cache miss) iteratively queries root, TLD, then authoritative servers → answer returns with a TTL and is cached at every hop, including the OS and browser.

Recursive vs iterative query?

Recursive: “get me the final answer” — the client delegates all work. Iterative: “tell me who to ask next” — the resolver follows referrals itself. Stubs speak recursive; resolvers speak iterative upstream.

CNAME vs A record?

A maps a name directly to an IPv4 address; CNAME aliases one name to another name, and resolution restarts on the target. A CNAME cannot coexist with other records on the same name — which is why zone apexes use A/ALIAS.

Why can DNS changes take “48 hours to propagate”?

It’s not propagation — it’s caching. Resolvers worldwide serve the old record until its TTL expires. The fix is lowering TTL well before the change.

✓

Quick Quiz

1. Which server actually holds example.com’s records?
2. Your laptop’s query to 8.8.8.8 is a ___ query.
3. Record type for name → IPv6:
4. TTL controls…
5. dig +trace shows…