Home / System Design / Concepts / DNS Concepts
CONCEPT SHEET · Concepts
DNS
One-liner: Hierarchical, cached, eventually consistent directory mapping names to records; also the coarsest layer of load balancing and failover.
Article Concepts © Arthur Bernier Jr 531 words 1 code block
Say this#
SAY THIS
Recursive resolver — the client-side resolver (ISP, 8.8.8.8, 1.1.1.1) that does the lookups and caches.
Root → TLD → authoritative — the delegation chain: . → .com → ns1.example.com.
Authoritative nameserver — holds the zone (Route 53, Cloudflare DNS, NS1, bind).
Record types — A (IPv4), AAAA (IPv6), CNAME (alias), NS, MX, TXT, SRV, CAA; ALIAS/ANAME at the apex.
TTL — how long resolvers cache; low TTL = faster failover, more queries.
Negative caching — NXDOMAIN cached per SOA minimum TTL.
GeoDNS / latency-based routing — answer differs by client location (Route 53 latency/geo policies).
Weighted / failover routing — DNS-level traffic split and health-checked failover.
Anycast — one IP, many locations; BGP picks nearest; how root servers and CDNs work.
DNS propagation — misnomer: it's cache expiry, not push.
DoH / DoT — DNS over HTTPS / TLS.
Split-horizon DNS — internal vs external answers.
How it works#
TEXT Copy
browser cache -> OS cache -> recursive resolver (cached?) -> root (.) -> "ask .com" -> .com TLD -> "ask ns1.example.com" -> authoritative -> A 203.0.113.10, TTL 60
Client asks recursive resolver; cache hit returns immediately.
Miss: resolver walks root → TLD → authoritative (roots/TLDs are heavily cached so usually one hop).
Authoritative may answer based on resolver location (GeoDNS) or health (failover).
Result cached for TTL at every layer; some resolvers/OSes clamp or ignore TTLs.
As a load balancer: return multiple A records (round-robin), weighted answers, or geo-nearest. Coarse because of caching: stale IPs survive for TTL after failover, and clients pick records unevenly.
Trade-offs#
Choice Pro Con Low TTL (30-60 s) Fast failover and migrations More resolver queries, higher authoritative load/cost High TTL (hours) Fewer lookups, resilient to DNS outages Slow to change DNS round-robin LB Free, global No health awareness at client; caching skews distribution GeoDNS Route users to nearest region Resolver location ≠ user location (ECS helps) Anycast Fastest, DDoS-absorbing Needs BGP control; TCP sessions can break on route changes CNAME vs ALIAS at apex CNAME simple CNAME not allowed at zone apex; use ALIAS/ANAME
Numbers#
Uncached full resolution: ~20-120 ms; cached: <1 ms.
Typical TTLs: 60-300 s for app endpoints, 3600+ s for stable records.
13 root server identities (A–M), each anycast across hundreds of sites.
UDP DNS message limit 512 bytes classic, ~1232-4096 with EDNS0; falls back to TCP when larger.
In the interview#
SAY THIS
Top-left of every diagram: "Client resolves via DNS (Route 53) with latency-based routing to the nearest region's load balancer."
Say: "TTL of 60 s so a regional failover completes within a minute or two; health checks flip the record."
Follow-up: "Why not do all load balancing in DNS?" → "Caching makes it coarse and slow to react; use DNS for region selection and L4/L7 LBs for instance selection."
Follow-up: "What's anycast?" → "Same IP announced from many PoPs; BGP routes to the nearest; it's how CDNs and 1.1.1.1 work."
Creator
Written by Arthur Bernier Jr (Big Poppa Code). Arthur Bernier Jr — Big Poppa Code — is a software engineer, educator and entrepreneur: a former CTO at VC-backed startups and engineering lead at a billion-dollar company, mentor to 800+ engineers, now Senior Director of AI, Computer Programming and Cloud Computing at Per Scholas, and the host of the Deeper Than Code podcast. Everything on this page is his original teaching material.
bigpoppacode.io
License © Arthur Bernier Jr all rights reserved