DNS — how a name becomes a server
The phone book of the internet, and the step that happens before a client can connect at all.
What problem does DNS solve?
People type names. Machines need addresses. DNS turns example.com into an IP address, and it all happens before your servers see anything.
It matters in system design for two reasons. It sits on the path of every first request. And it is the roughest tool you have for sending users to different places.
What DNS costs you
Every concept in here states a cost. A technique with no price is a technique you have not understood yet — and naming the cost out loud is most of what separates a senior answer from a junior one.
When to reach for DNS, and when not to
Use it when
- Sending users to the nearest region (geographic routing).
- Rough traffic splitting between environments or providers.
- Very slow, planned migrations, where hours of rollout are fine.
Do not, when
- Fast failover. Minutes of cached answers means minutes of users hitting a dead address.
- Balancing per request. Use a real load balancer for that. DNS has no idea which server is busy or healthy.
How DNS actually works
You only need a few record types. A maps a name to an IPv4 address, and AAAA to IPv6. CNAME points one name at another name, which is how you point at a CDN or a managed service without writing their addresses down. MX is for mail. That is enough for design conversations.
The TTL controls how fast a change spreads. It tells everyone how long they may keep the answer. Long TTLs mean fast lookups and slow changes. Short TTLs mean the opposite, plus more load on your DNS. The usual trick before a planned migration is to drop the TTL to sixty seconds a day in advance, make the change, then put it back up.
Routing policies are where DNS earns its place in a design. Round robin hands out different addresses in turn. That is rough balancing with no idea of health. Geographic sends users to the nearest region, which is how global products cut latency. Latency-based measures and sends users to whichever region is fastest for them. Failover returns the backup address when health checks fail. That is real, but limited by cached answers, so think in minutes, not seconds.
The practical takeaway: DNS gets users to the right *region* or the right *front door*. A load balancer takes over from there and gets them to the right *server*. Do not ask DNS to do the second job.
- Treating DNS as a load balancer. It has no idea which servers are healthy or busy.
- Trusting your TTL. Plenty of resolvers do not.
- Forgetting DNS lookup time in the time budget of a first request.
The DNS follow-up an interviewer will ask
"Your primary region is down. Can you just change DNS?"
You can, but you should not rely on it as your only answer, because it is slow and partly out of your control. Even with a sixty-second TTL, resolvers, browsers and company networks cache more than they promise. So a noticeable share of users keep hitting the dead address for minutes, and some for much longer. DNS failover is a real tool for the long tail, but it is not a fast one. What gives you quick failover is something in front that already receives all the traffic and can redirect internally. That means anycast, where the same IP is announced from several places and the network routes to a live one, or a global load balancer that ends connections itself and picks a healthy backend. My design would use DNS to get users to a nearby front door, and put the fast failover behind that front door where I control it.
Your turn
Why is DNS a bad way to do fast failover, and what would you use instead?
Learn it from the source
This page gets you interview-ready. These take you to where the idea is actually specified or measured — read them when you want the real depth.
- RFC 1034 — Domain Names, Concepts and Facilities ↗The core specification. Section 3 is the part worth reading for a design discussion.