How DNS Works
How DNS resolution works step by step: resolvers, root and TLD servers, record types, TTLs and caching, and DNS-based load balancing.
The Domain Name System (DNS) translates names like api.example.com into IP addresses. It is a globally distributed, heavily cached, hierarchical database, and it is the first step of almost every request on the internet. In system design it also matters as a tool: DNS is how traffic is steered between regions and failed over between data centers.
How a lookup works
Your device asks a recursive resolver (run by your ISP, or public ones like 8.8.8.8 and 1.1.1.1). If the resolver has the answer cached, it replies immediately. Otherwise it walks the hierarchy from the top:
- The root servers (13 named root server identities, served by hundreds of anycast instances) point to the servers for the top-level domain, like
.com. - The TLD servers point to the domain's authoritative name servers, the ones the domain owner configured (for example Route 53 or Cloudflare).
- The authoritative server returns the actual record. The resolver caches every step, so next time it skips straight to the answer.
Browsers and operating systems keep their own caches too. DNS mostly runs over UDP on port 53 because a lookup fits in one small packet; encrypted variants (DNS over HTTPS and over TLS) protect privacy.
Record types you'll use
| Record | Maps | Example use |
|---|---|---|
| A / AAAA | Name → IPv4 / IPv6 address | api.example.com → 203.0.113.10 |
| CNAME | Name → another name | www.example.com → example.cdn-provider.net to point at a CDN |
| ALIAS / ANAME | Root domain → name, flattened to IPs | Point example.com itself at a load balancer (CNAME isn't allowed at the root) |
| MX | Domain → mail servers with priorities | Email delivery |
| TXT | Name → arbitrary text | Domain ownership verification, SPF and DKIM for email |
| NS | Domain → its authoritative servers | Delegating a domain or subdomain |
| SRV | Service → host and port | Service discovery in some systems. See service discovery |
TTL: the knob that matters
Every record has a time to live: how long resolvers may cache it. The trade-off is direct:
- Long TTL (hours): fewer lookups, faster page loads, less load on name servers, but changes and failovers take hours to reach everyone.
- Short TTL (30–60 s): fast failover and traffic shifting, but more lookups. Also, some resolvers and clients ignore TTLs or enforce minimums, so DNS failover is never instant.
Before a planned migration, lower the TTL a day ahead so the old long TTL expires everywhere; switch the record; raise the TTL again afterwards.
DNS as a traffic tool
| Technique | What it does | Example |
|---|---|---|
| Round-robin DNS | Return several IPs; clients spread across them | Simple load spreading, with no health awareness |
| Weighted records | Return IPs in proportion to weights | Send 5% of traffic to a new region |
| Latency / geo routing | Answer based on the resolver's location | Users in Mumbai get the Asia region's address |
| Health-checked failover | Stop returning an endpoint whose health check fails | Fail over from a dead region to a standby |
| Anycast | Many servers share one IP; the network routes to the nearest | Public resolvers, CDNs and DDoS protection |
DNS as a failure point
Because everything starts with DNS, a DNS outage looks like the whole internet is down for your users. Large outages (the 2016 Dyn attack, several cloud DNS incidents) took down many big sites at once. Mitigations: use a provider with a strong track record and anycast, consider two independent DNS providers for critical domains, and keep TTLs reasonable so cached answers keep working through short outages.
Where it’s used
Use DNS-based routing (for example Route 53 latency and failover records) to send users to the nearest healthy region and to evacuate a failing region.
Customers CNAME their hostnames to the CDN, which then answers with the closest edge location's address. See CDN.
Public recursive resolvers served from hundreds of locations via anycast.
CoreDNS gives every service a stable name like orders.default.svc.cluster.local that resolves to its current address.
In an interview
- Mention DNS as the first hop when you walk through a request, and use GeoDNS or latency routing for multi-region designs.
- Know the TTL trade-off and that DNS failover takes at least the TTL (often longer) to take effect.
- Use CNAMEs to point your domain at a CDN or managed load balancer.
- Don't use plain round-robin DNS as your only load balancer: it has no health checks and clients cache answers.