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 → comexampleshopapi.
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…