We use cookies for site analytics. Accept to help us understand how the site is used. See our Privacy Policy for details.
The internet's phone book. A globally distributed, read-dominated, cache-everywhere hierarchy that has to answer in single-digit milliseconds and never go down.
Design the Domain Name System: the service that translates human-readable names (example.com) into IP addresses, and that powers traffic routing, failover, and load distribution for nearly every internet service.
This is a Hard topic because DNS is the canonical "globally distributed read system" - it teaches caching hierarchies, TTL trade-offs, anycast routing, and availability engineering under adversarial load. Interviewers use it to see whether you understand layered caching and eventual consistency at planetary scale.
Asking these before diving into a solution is the difference between a "hire" and a "no signal" rating. Pick the questions whose answers would change your design.
Query volume
Cache effectiveness
Storage (authoritative)
Anycast footprint
Split the problem into two planes. The resolution plane answers queries: clients hit anycast IPs that land on the nearest PoP, where an in-memory cache serves the hot path and a recursive engine walks root → TLD → authoritative on a miss. The control plane ingests zone changes from owners, validates and (optionally DNSSEC-)signs them, and replicates them to every edge nameserver. The two planes are deliberately decoupled: queries never block on the control plane.
Hundreds of PoPs announcing the same IPs via BGP. Terminate UDP/TCP/DoH/DoT, serve from local cache, and hold the full authoritative zone set in memory. The nearest PoP answers; a dead PoP withdraws its route.
Per-PoP cache keyed by (name, type), evicting on TTL. Absorbs >90% of traffic. Negative caching (RFC 2308) caches NXDOMAIN too, so floods of bogus names don't all walk the hierarchy.
On a miss, walks the delegation chain: root servers → TLD servers (.com) → the zone's authoritative servers. Caches every intermediate answer for its TTL. Used only by the recursive product.
Source of truth for zones we host. Validates record writes, applies routing policies, signs zones for DNSSEC, and pushes versioned snapshots/deltas to all edge nameservers.
For GeoDNS/latency/weighted/failover records, computes the answer per query from the client's source (EDNS Client Subnet) and live health-check state instead of returning a static record.
Continuously probe the endpoints behind failover records; when one goes unhealthy, the policy engine stops returning it, giving DNS-level failover bounded by TTL.
The subsystems where the interview is actually decided. Skim if you're running short; own these if you want a strong signal.
DNS is the textbook layered cache. An answer can be served from: the OS stub resolver cache, the recursive resolver's cache, or (on a full miss) the authoritative servers. Every layer respects the record's TTL.
TTL is the central design lever:
The standard pattern: keep TTLs high (3600s+) for stable records, and pre-lower the TTL before a planned change. Want to migrate an IP next week? Drop the TTL to 60s today; by migration time every cached copy has the short TTL, so the cutover propagates in a minute. Then raise it again.
Negative caching matters as much as positive: cache NXDOMAIN responses (per the SOA minimum TTL) so a flood of queries for non-existent names doesn't hammer the authoritative tier - a common DDoS amplification vector.
DNS availability is an anycast + BGP story, not a load-balancer story.
Anycast: every PoP announces the same IP prefixes via BGP. The internet's routing fabric delivers each client's packet to the topologically nearest PoP. This gives three things for free: low latency (nearest PoP), load distribution (traffic splits by geography), and failover (a dead PoP withdraws its BGP announcement and routes shift in seconds).
DDoS is the defining threat. DNS uses UDP, which is spoofable and amplifiable, so authoritative and resolver infrastructure is a perennial target (the 2016 Dyn attack took down half the US internet's name resolution).
Defenses:
Interview signal: candidates who reach for "add a load balancer" haven't internalized that at DNS scale the routing is the load balancer - anycast does the work an L4 LB would do for a normal service.
Beyond static records, managed DNS is a traffic-steering tool. The same name returns different answers depending on the query.
Geo/latency routing: return the IP of the nearest (or lowest-latency) region. The resolver infers client location from EDNS Client Subnet (ECS) - the recursive resolver forwards a truncated client subnet so the authoritative server can answer for the real end-user location, not the resolver's location. Without ECS, GeoDNS routes to where 8.8.8.8 is, which can be a continent away.
Weighted routing: return endpoint A 90% of the time and B 10% - the canary/blue-green primitive at the DNS layer.
Failover routing: tie records to health checks; return only healthy endpoints. Failover latency is bounded below by TTL, which is why failover records use low TTLs (30-60s) and accept the higher authoritative load.
The catch: DNS-level routing is coarse. It steers at name-resolution time, not per request, and is blind to anything downstream of the resolver's cache. For fine-grained, real-time steering you push the decision into anycast + an L7 layer; DNS handles the coarse, global cut.
DNSSEC authenticates answers so a resolver can verify a response wasn't forged (defending against cache poisoning). The zone is signed with a private key; resolvers validate a chain of trust from the root down using DS/DNSKEY/RRSIG records. Costs: larger responses (signatures), CPU for signing/validation, and real operational risk - a botched key rollover makes the whole zone fail validation and vanish from the internet. It's strong security with sharp edges.
Propagating changes is the control-plane's hard problem. When an owner edits a record:
End-to-end propagation to the client is replication lag (seconds) plus the old record's TTL (up to hours). This is why "DNS changes take up to 48 hours" is folklore - it's really "until the longest cached TTL expires." The fix is pre-lowering TTL, not faster replication.
TTL: cache efficiency vs change agility
High TTL means cheap, fast, cacheable reads but slow propagation. Low TTL means quick failover but high authoritative load. The mature answer is high-by-default with deliberate pre-lowering before planned changes.
Recursive vs authoritative
A recursive resolver optimizes for client latency and cache hit rate; an authoritative service optimizes for correctness, propagation speed, and routing policy. They're different products with different SLAs - don't conflate them in the design.
Consistency vs availability
DNS chooses availability and partition tolerance every time. Stale-but-answered beats correct-but-unavailable, because an unanswered DNS query means total outage for that name. Eventual consistency isn't a compromise here - it's the design.
DNSSEC: security vs operational risk
DNSSEC stops forgery but adds response size, CPU, and the very real risk that a key-management mistake nukes the zone. Many large operators run it; many deliberately don't, judging the operational blast radius worse than the threat.
Anycast simplicity vs routing opacity
Anycast gives failover and geo-distribution for free, but you don't control which PoP a client lands on (BGP decides) and debugging "why is this user hitting the wrong PoP" is hard. You trade explicit control for emergent robustness.
Be ready for at least three of these. The first one is almost always asked.
Edge cache hierarchies, cache key design, invalidation, origin shield, and edge compute - the system every other system relies on without thinking about it.
L4 vs L7, consistent hashing, health checks, connection draining, and the difference between a fleet that survives partial failures and one that cascades into outage.
The canonical bounded system design problem. Read-heavy, hot-key prone, and a great vehicle for hashing, caching, and capacity estimation.
Reading is the floor. The interview signal is in walking through this live with someone probing follow-ups. Use the AI mock interview to practice talking through requirements, architecture, and trade-offs out loud.
Start an AI mock interview →