What DNS does
DNS maps human names (api.example.com) to records machines can use — most often IPv4/IPv6 addresses. It's a distributed database: no single server holds the whole internet.
Resolution pipeline (know this cold)
- App asks the OS resolver.
- Resolver checks local cache (OS + browser).
- On miss, recursive resolver queries root → TLD (
.com) → authoritative name server for the zone. - Answer is cached according to TTL (time to live).
Iterative — resolver is told "ask this next server." Recursive — resolver does the walking for the client.
Record types interviewers expect
| Type | Purpose |
|---|---|
| A / AAAA | IPv4 / IPv6 address |
| CNAME | Alias to another hostname (no CNAME at apex on many providers) |
| MX | Mail routing |
| TXT | Verification strings, SPF, DKIM hints |
Caching & TTL
Low TTL (60s) speeds failover but increases query load. High TTL (3600s+) reduces load but stale answers linger after IP changes — classic post-migration bug. Senior signal: mention negative caching and why dig vs browser can disagree (different caches).
Common failure modes
- Wrong CNAME chain or apex misconfiguration
- Stale cache after cutover (wait TTL or flush)
- Resolver timeout → entire dependency appears down
- Split-horizon / private zones in VPC (internal DNS vs public)
Further Reading
Hands-On Tasks (Optional)
Low-setup exercises you can run locally or on a free-tier cloud account. No autograding — the goal is to build intuition, not pass a test.
- Trace resolution with dig15m
Run `dig example.com`, then `dig +trace example.com` and note each hop (root → TLD → authoritative). Query A vs CNAME for a CDN hostname you use.