DNS Deep Dive: A System Design Guide

If you remember five things

The whole page in one glance. Everything below defends these five.

It is a read-optimized cache, not a database. DNS is a hierarchical key-value store read billions of times a second and written rarely, so caching is its entire personality.
TTL is one dial with two edges. The same number sets your query cost and your failover blast radius. Short means fast changes and more load; long means cheap and slow to react.
Lower TTL before a planned change. Drop it a full old-TTL-period ahead, let the long copies drain, then cut over with a tight tail.
DNS is a weak load balancer. No health awareness, no millisecond reaction. Good for coarse routing (which region), bad for fine routing (which box). A real load balancer lives behind the name.
GeoDNS routes by resolver, not user. A Berlin user on a Virginia resolver lands in your US region. Know the caveat and the two-provider redundancy move.

1The core idea#

Hold the right mental model before anything else, because every other DNS decision falls out of it.

DNS is the phone book of the internet, but that undersells it. It is a globally distributed, cached, hierarchical key-value store that is read far more than it is written.
Keys are names, like shop.example.com.
Values are records: an IP address, another name, a mail server, a text blob.

The one idea the whole page defends

DNS is a lookup system tuned for reads at planetary scale, and caching is its entire personality. Writes (changing a record) are rare and slow to propagate. Reads happen billions of times a second and get answered from caches almost all the way down. TTLs, the tiny UDP packets, the hierarchy: all of it exists to make reads cheap and keep load off the authoritative source.

The hierarchy is what lets it scale.

The name shop.example.com reads right to left in authority.
The root (.) delegates to the TLD (.com), which delegates to your domain (example.com), which answers for its own subdomains.
No single machine knows everything. Each level knows only who to ask next.
That delegation is why DNS scales to hundreds of millions of domains with no central database.
There are 13 root server identities (A through M), each fronted by anycast, so a single letter is really hundreds of machines worldwide.

2How it works#

When your laptop needs shop.example.com, it does not magically know the IP. It hands the job to a resolver and waits.

The recursive resolver does the legwork. Usually run by your ISP, your company, or a public one like 8.8.8.8.
Your laptop asks once. One question out, one answer back.
The resolver walks the hierarchy. Root ("who handles .com?"), TLD ("who handles example.com?"), authoritative ("what is the A record for shop.example.com?").
The answer carries a TTL, say 300 seconds, and the resolver caches it.
The next thousand users who hit that resolver get an instant reply with no walking at all.

sequenceDiagram participant Client participant Resolver participant Root participant TLD participant Auth Client->>Resolver: resolve shop example com Resolver->>Root: who serves com Root-->>Resolver: ask the com TLD Resolver->>TLD: who serves example com TLD-->>Resolver: ask these nameservers Resolver->>Auth: A record for shop example com Auth-->>Resolver: 203 0 113 10 TTL 300 Resolver-->>Client: 203 0 113 10

The resolution walk. Notice the client speaks only to the resolver. The resolver does the three-hop climb once, then caches the result so the next thousand lookups skip the whole walk.

A few mechanics worth knowing cold:

Record types. A maps a name to an IPv4 address, AAAA to IPv6. CNAME is an alias that points one name at another name (handy for pointing www at a load balancer's DNS name). NS lists the authoritative nameservers. MX is for mail. TXT is arbitrary text, which is how SPF, DKIM, and domain-ownership checks ride on DNS.
UDP first, then TCP. Queries ride UDP port 53 because they are tiny and a dropped packet just gets retried. If a response is too big for one UDP datagram, the client retries over TCP. Zone transfers between nameservers also use TCP.
Caching happens in layers. The recursive resolver caches. So does your operating system, and often your browser. A record can sit in three or four caches between the authoritative server and your code, each with its own countdown.

The gotcha hiding in that last point

When you "update DNS," you change the authoritative record and nothing else. Every cache that already holds the old value keeps serving it until its own TTL expires. There is no push, no invalidation signal, no way to force a flush. You wait. Candidates who think a record change is instant get caught the moment the interviewer says "a region just failed."

A worked example: the cost of caching, with real numbers#

Make the caching argument concrete, because this is exactly the estimate a strong candidate does out loud at the whiteboard. Setup: shop.example.com gets 100,000 user lookups per minute worldwide, and most users sit behind a handful of big public resolvers. Compare two TTL choices.

Case A, TTL 300 seconds (5 minutes).

In any 5-minute window, each resolver does the full root to TLD to authoritative walk once, then serves the cached answer to everyone else.
50 distinct resolvers means roughly 50 cold walks every 5 minutes, about 10 queries per minute actually reaching your authoritative nameservers.
The other 99,990 lookups per minute are answered from cache in single-digit milliseconds.
Load on your infrastructure is almost nothing.

Case B, TTL 30 seconds.

Each of those 50 resolvers re-walks every 30 seconds, so authoritative traffic jumps to roughly 50 walks every 30 seconds, about 100 queries per minute.
That is a 10x increase in authoritative load for the exact same user traffic.
Still tiny in absolute terms, but the ratio is the point: 10x more queries to cut your worst-case failover delay from 5 minutes to 30 seconds.

Now flip it to the failure case: a region dies.

With TTL 300, the slowest-draining resolver keeps handing out the dead IP for up to 300 seconds, so your worst-case user-visible outage tail is 5 minutes even after you fix the record.
With TTL 30, that tail is 30 seconds.
The TTL is simultaneously your query-cost dial and your blast-radius dial.

~10x

The cost of halving your failover tailDropping TTL from 300s to 30s multiplies authoritative queries by roughly (old TTL / new TTL), here about 10x, to buy a worst-case outage tail of 30s instead of 5 minutes. This is the answer to "why not just set a really short TTL?" The real fix for fast failover is a managed provider running health checks, not an aggressively short TTL alone.

3Trade-offs#

The central lever in DNS design is TTL, and it is a genuine trade-off with no free answer.

Agile but expensive

Low TTL (30 to 60s)

Changes propagate: Fast: failover or IP swap picked up within a minute.
Authoritative load: Heavy: resolvers re-walk constantly.
First-request latency: Users eat the resolution cost far more often.
Best when: You need quick failover and your nameservers can take the load.

Cheap but slow

High TTL (hours to a day)

Changes propagate: Slow: a dead IP lingers in caches for hours.
Authoritative load: Light: almost everything served from cache.
First-request latency: Lookups are cheap and rare.
Best when: Records are stable and you plan changes in advance.

Why a low TTL costs you.

When you fail over to a backup region or swap a load balancer IP, clients pick up the new value within a minute.
The cost: far more queries hit your authoritative nameservers, and every cache miss adds latency to the first request.
If your nameservers are slow or your resolver is far away, a 60-second TTL means users eat that resolution cost many times more often than with a 20-minute TTL.
Drop from 1200 seconds to 60 and, per the math above, you are looking at a 20x jump in authoritative queries.

Why a high TTL costs you.

Cheap, fast lookups and light load on your nameservers, but you lose agility.
Decommission a server and some users keep hammering the dead IP for hours.
The fix is a discipline, not a setting: drop TTLs before a planned migration, wait for the old high TTL to drain, then do the switch.
Concretely: record sits at TTL 86400 (one day) and you want to migrate Tuesday. Lower it to 60 on Monday morning, wait a full day for the old 86400 copies to expire everywhere, then cut over Tuesday with a tight 60-second tail.

Pause before you read on: your record has been at TTL 86400 for months, and you need to cut over to a new region this afternoon. Why can you not just change the record now?

Reveal the answer

Because resolvers that cached the old value this morning will keep serving it for up to a full day, no matter what you do to the authoritative record. There is no invalidation signal. You had to lower the TTL a full day in advance so those long-lived copies drained first. Skip that step and your "quick" cutover has a 24-hour tail of stragglers hitting the old region. The discipline (lower early, drain, then switch) is the whole point.

Here is how I think about the routing approaches you can build on top of DNS:

Approach	How it works	Strength	What you give up
Single A record	One name, one IP	Dead simple	No failover, no spread
Multiple A records	One name, several IPs	Client-side spread, basic resilience	Clients pick randomly, no health awareness
Round-robin DNS	Rotate the order of returned IPs	Crude load spread, no extra infra	Caching skews distribution, dead IPs still served
GeoDNS	Answer based on resolver location	Route users to the nearest region	Resolver location is not user location
Latency or health-based	Managed DNS checks targets, answers with healthy nearest	Real failover, real proximity	Vendor lock-in, cost, still TTL-bound

DNS is a weak load balancer, and interviewers want you to notice.

It has no idea whether a backend is healthy unless you pay a managed provider to run health checks and edit records for you.
It cannot react in milliseconds because of caching.
Round-robin DNS will happily keep handing out the IP of a server that caught fire thirty seconds ago.
It is great for coarse routing (which region, which load balancer) and bad for fine routing (which exact box). The fine work belongs to a real load balancer behind the name.

From the interviewer's chair

When a candidate draws "DNS, then a load balancer" and keeps moving, I want to know if they understand why those are two different layers. The clean answer: DNS picks the region in seconds-to-minutes with no health awareness, the load balancer picks the healthy box per request in milliseconds. Name that split unprompted and I know you have operated this, not just read about it.

GeoDNS routes by the resolver's IP, not the user's.

If someone in Berlin uses a resolver in Virginia, GeoDNS sends them to your US region.
EDNS Client Subnet partially fixes this by passing a chunk of the user's IP to the authoritative server.
Not every resolver sends it, and not every user wants their subnet leaked.
Know this limitation. It is a favorite follow-up.

4Where it is used#

DNS shows up in more of your architecture than you probably draw.

Global traffic routing. Big services point one name at an anycast IP or use latency-based DNS to send each user to the nearest data center. When you say "we run in three regions," DNS is usually the first hop that decides which region a user lands in.
Service discovery inside a cluster. Kubernetes gives every service an internal DNS name like payments.default.svc.cluster.local. Your code connects to a stable name, and the cluster's DNS resolves it to whatever pod IPs are currently healthy. Same core idea as the public internet, just a private zone. Worth mentioning because it shows you know DNS is not only a public-internet thing.
Failover and blue-green deploys. Flip a weighted DNS record from 100% old to 100% new, or shift gradually (90/10, then 50/50, then 0/100). Paired with health checks, a managed DNS provider becomes a crude but effective disaster-recovery switch between regions.
Email and verification. Every SPF, DKIM, or domain-ownership check for a TLS certificate is a TXT record. Quietly load-bearing infrastructure.
CDNs. Point assets.yourapp.com at a CDN via CNAME and the CDN's own DNS does the heavy routing, sending each user to a nearby edge node. You hand off the hard geo problem to someone who already solved it.

The rule for when to reach for it:

DNS-based routing when you need global decisions and can tolerate seconds-to-minutes reaction time.
Anycast plus a real load balancer when you need sub-second reaction or per-request decisions.

5Common pitfalls and gotchas#

The failure modes here are all about caching and all about trust. Name a couple before the interviewer asks.

TTL amnesia. The number one production surprise. You change a record, see it update on dig against the authoritative server, and assume you are done. Meanwhile half your users sit behind resolvers still serving the old value. Check the TTL before you need to change something, and lower it ahead of planned changes.
Trusting round-robin as a load balancer. It spreads nothing reliably. Caches at every layer mean one busy resolver can pin thousands of users to a single IP. Zero health awareness.
CNAME at the apex. You cannot legally put a CNAME on the root domain (example.com with no subdomain), because the apex must also hold SOA and NS records, and a CNAME is supposed to be the only record on a name. Providers fake it with "ALIAS" or "ANAME" records that flatten to A records server-side. Not knowing this is how a "just CNAME the root to the load balancer" plan quietly fails.
Negative caching. If a name does not exist, resolvers cache that absence too, governed by the SOA minimum TTL. Create a record and it can still look missing for a while. People burn an hour debugging a record they already created.
Resolution counts as latency. A cold lookup can add 20 to 120 milliseconds before a single byte of your actual request moves. For a page opening connections to a dozen domains, that is potentially 240 to 1440 milliseconds of pure name resolution before anything useful loads. This is part of why fewer domains and DNS prefetching matter for front-end performance.
Depending on one DNS provider. DNS outages take down companies that are otherwise perfectly healthy. The October 2016 Dyn attack knocked Twitter, Reddit, and Spotify offline not because those services broke, but because the name resolution in front of them did. If your single managed DNS provider has a bad day, your name resolves to nothing and your flawless backend is unreachable. Serious setups run nameservers across two independent providers.

Your backend can be perfect and still unreachable if the name in front of it will not resolve.

6How it shows up in interviews#

Interviewers rarely ask "explain DNS" outright. It surfaces inside bigger questions (design a URL shortener, a CDN, a globally available API), and your competence shows in how you handle the first hop and failover.

What they probe:

Can you explain the resolution path (resolver, root, TLD, authoritative) without hand-waving?
Do you understand TTL as a trade-off, and can you name the pre-migration TTL-lowering trick?
Do you know DNS alone is a poor load balancer, and why?
Can you reason about global routing: GeoDNS vs anycast, and the resolver-location caveat?

A weak answer:

Says "DNS turns the domain into an IP, so I'll put a load balancer behind it," and moves on.
Proposes round-robin DNS as the system's load balancing strategy with no mention of health or caching.
Treats a record change as instant, so "a region just failed, what happens to users?" gets the wrong answer ("they get routed to the healthy region immediately") with no number for how long the bad answers linger.

A strong answer sounds like this:

"Clients resolve through a recursive resolver that walks the hierarchy and caches the result with a TTL. For global routing I'd use latency-based DNS from a managed provider with health checks, so a region failure pulls that region's record within the TTL window. I'd keep that TTL around 60 seconds to balance failover speed against query load: at 100k lookups a minute behind maybe 50 resolvers, a 60-second TTL means only a handful of walks per minute actually reach my authoritative nameservers, and my worst-case outage tail after a failover is about 60 seconds instead of the 5 minutes a 300-second TTL would give me. Before any planned cutover I'd lower the TTL a full old-TTL-period in advance so the long copies drain first. DNS handles the coarse region choice; inside the region a real load balancer does per-request health-aware balancing. One caveat: GeoDNS routes by resolver location, not user location, so for true proximity I'd lean on anycast at the edge, and I'd split my nameservers across two providers so a single DNS outage doesn't take the whole product down."

Why the strong answer wins:

The difference is not vocabulary. The strong answer attaches a number to every claim and names a failure mode before being asked.
Mention the resolver-location gap, or that you would run DNS across two providers for redundancy.
It signals you have actually operated this stuff, not just read about it.

Follow-ups the interviewer will ask (and your answers)

"A region just failed. What do your users see, and for how long?"

Health checks pull the dead region's record, but every resolver that cached the old IP keeps serving it until its TTL expires. There is no invalidation. So the worst-case user-visible tail is the TTL: about 60 seconds at TTL 60, up to 5 minutes at TTL 300. Short TTL plus managed health checks is what keeps that tail small.

"Why not just set a 5-second TTL everywhere for instant failover?"

Because authoritative query load scales roughly as (old TTL / new TTL). Going from 300 to 5 is a ~60x jump in queries for the same user traffic, plus every cache miss adds resolution latency to a real request. The right lever for fast failover is a managed provider doing health checks, not an aggressively short TTL alone.

"You need to migrate to a new region this afternoon. Walk me through it."

If the record is at a high TTL, I can't cut over cleanly today. I lower the TTL a full old-TTL-period in advance (drop 86400 to 60 a day early), wait for the long copies to drain, then flip the record with a tight 60-second tail. Lower early, drain, then switch.

"GeoDNS sends a user to the wrong region. Why, and how do you fix it?"

GeoDNS routes by the resolver's IP, not the user's, so a Berlin user on a Virginia resolver lands in the US. EDNS Client Subnet passes a chunk of the user's IP to the authoritative server and partially fixes it, but not every resolver sends it. For true proximity I lean on anycast at the edge instead.

"Can you CNAME your root domain at the load balancer?"

No. The apex must hold SOA and NS records, and a CNAME is supposed to be the only record on a name, so the two conflict. Providers fake it with ALIAS or ANAME records that flatten to A records server-side. That is the clean way to point a root domain at a load balancer's DNS name.

What you can now explain in the room

Why DNS is a read-optimized, cached, hierarchical lookup system, not a database.
The full resolution walk (resolver, root, TLD, authoritative) and where each cache sits.
How TTL is one dial that sets both query cost and failover blast radius, with the numbers.
The pre-migration TTL-lowering trick and why a record change is never instant.
Why DNS is a weak load balancer and where a real load balancer takes over.
Why GeoDNS routes by resolver, and why serious setups run two DNS providers.

Ready to put this to work? Try the System Design Question walkthrough on designing a globally available API, where the DNS layer is the first real decision you make.

← Previous

Webhooks

How the Internet Works

Get a prep plan built around your DNS Deep Dive interview

Tell us the role and your interview date. We will send back a dated, day by day plan. Free.

Thanks. Check your inbox, your DNS Deep Dive prep plan is on the way.