Design a DNS System
How to design DNS for interviews: hierarchy, recursive vs authoritative resolvers, caching TTLs, anycast, zone updates, DNSSEC basics, and failure modes.
DNS turns names into addresses. Every web request, CDN edge pick, and mail hop depends on it. Interview prompts split into two flavours: build a recursive resolver (what your laptop talks to) or run authoritative name servers for a huge zone (what Cloudflare / Route 53 sell). Clarify which one in the first minute.
Use the framework. Capacity is wild: global QPS, tiny payloads, insane fan-out of names, and a hard availability bar. Link trade-offs to caching and load balancing.
Functional requirements
- Resolve a name (A/AAAA/CNAME/MX/TXT…) within a timeout.
- Authoritative path: answer for owned zones; return referrals otherwise.
- Recursive path: chase referrals from root → TLD → authoritative.
- Cache positive and negative answers with TTLs.
- Admin API to publish zone updates (add/change/delete records).
Non-functional requirements
- p99 latency in low tens of milliseconds for warm cache hits.
- Extremely high availability - DNS failure looks like the internet is down.
- Correctness under update (eventual propagation is OK if you state TTLs).
- Resilience to spoofing and amplification (source validation, rate limits, DNSSEC optional).
UDP first, TCP when needed
Most queries fit in a UDP datagram. Truncation, zone transfers (AXFR/IXFR), and DNSSEC answers may need TCP. Mention both; do not design only HTTP-looking APIs.
Hierarchy refresher
- Root hints → ask a root for .com.
- TLD (.com) returns NS for example.com.
- Authoritative NS for example.com returns the A/AAAA record.
- Resolver caches each step according to TTL.
Interviewers expect you to draw this ladder out loud. Mistaking recursive for authoritative is a common fail. Recursive servers do the walking; authoritative servers only answer what they own (plus NS glue).
Recursive resolver architecture
- Anycast VIP in front of many resolver pods per PoP.
- In-memory cache (LRU + TTL expiry) holding RRsets keyed by (name, type).
- Outbound workers that query upstream with retries and parallel A/AAAA.
- Optional: shared Redis tier for multi-host cache warm (distributed cache).
- Negative caching for NXDOMAIN / NODATA with conservative TTLs.
Cache hit ratio dominates latency and upstream cost. Honour TTLs; shorter TTLs mean fresher data and more origin load - same tension as CDN edge caching. Prefetch popular names before TTL expiry if traffic is predictable.
Authoritative name servers
- Control plane stores zones in a replicated DB; operators publish via API or DNS UPDATE.
- Data plane loads a frozen snapshot of records into memory on each NS node.
- Anycast announces the same NS IPs worldwide; BGP steers clients to nearby PoPs.
- Health checks withdraw unhealthy PoPs from anycast.
| Component | Role |
|---|---|
| Zone DB | Source of truth for records and SOA serial |
| Publisher | Pushes snapshots to NS fleets |
| NS nodes | Answer queries from RAM |
| Anycast / LB | Global entrance and failover |
Updates and propagation
Bump SOA serial; push incremental or full zone sync to secondaries. Clients keep old answers until TTL expires - that is intentional. For low-TTL cutovers (blue/green of a VIP), warn about resolver caches you do not control. Secondary AXFR/IXFR still matters in textbook designs even if many providers use proprietary sync.
Security notes worth saying
- Rate-limit clients and open resolvers to cut amplification.
- Validate response source / use TCP or cookies where supported.
- DNSSEC: signed RRsets and chain of trust - heavy, mention as optional hardening.
- Split-horizon DNS for internal vs public answers behind API gateway style corp networks.
Worked example
- Browser asks 1.1.1.1 for www.shop.example A.
- Cache miss → resolver walks root → .example TLD → shop.example NS.
- Authoritative returns 203.0.113.10 with TTL 300.
- Resolver caches; next 5 minutes of nearby clients get a PoP hit.
Interview summary
Name recursive vs authoritative first. Draw the hierarchy. Put TTL caching and anycast at the centre. Close with update propagation and one security control. That set covers most DNS system design rounds.