DNS

7 min read

In a Nutshell

DNS (Domain Name System) is the phone book of the internet: it translates human-friendly names like api.example.com into the IP addresses machines actually use to connect. It's a globally distributed, hierarchical, heavily-cached lookup system — and it quietly does far more than name resolution. DNS is also a powerful traffic-steering tool: through record types and routing policies, it directs users to the nearest data center, load-balances across servers, and enables failover between regions. Because every connection starts with a DNS lookup, it's both foundational infrastructure and a surprisingly common source of outages.

2D minimalistic diagram showing a browser asking "where is example.com?" and a chain of DNS servers answering: a resolver querying a root server, then a .com TLD server, then the authoritative name server, which returns the IP address 93.184.216.34 back to the browser, which then connects to that IP

How It Actually Works

The Resolution Chain

A DNS lookup walks down a hierarchy, usually via a recursive resolver that does the legwork on the client's behalf:

1. Browser asks the recursive resolver: "IP for www.example.com?"
2. Resolver → Root server:  "Who handles .com?"        → TLD server address
3. Resolver → .com TLD server: "Who handles example.com?" → authoritative NS
4. Resolver → Authoritative NS: "IP for www.example.com?" → 93.184.216.34
5. Resolver caches the answer (per its TTL) and returns it to the browser
6. Browser connects to 93.184.216.34

Caching at every level (browser, OS, resolver) means most lookups never walk the whole chain — which is why DNS scales to the entire internet.

Common Record Types

Record	Maps	Example / Use
A	Name → IPv4	`example.com → 93.184.216.34`
AAAA	Name → IPv6	`example.com → 2606:2800:220:1::`
CNAME	Name → another name (alias)	`www → example.com`
MX	Domain → mail servers	Email routing
TXT	Arbitrary text	SPF/DKIM, domain verification
NS	Domain → authoritative name servers	Delegation
SOA	Zone metadata	Serial, refresh, TTLs

TTL: The Double-Edged Sword

Every record has a Time To Live — how long resolvers may cache it. This is one of the most consequential knobs in system design:

Short TTL (e.g., 60s)	Long TTL (e.g., 24h)
Fast propagation of changes	Slow propagation
Quick failover to new IPs	Failover blocked by stale caches
More DNS query load	Less query load, more resilient to resolver outages

Trap: during an incident you may change a DNS record to fail over, but clients keep hitting the old IP until the old TTL expires. Lower TTLs before a planned migration.

DNS as a Load Balancer and Traffic Steerer

DNS can return different answers to different users, which turns it into a global traffic director:

Routing Policy	Behavior	Use
Round-robin	Rotate through multiple A records	Simple load spreading
Geo / latency-based	Return the nearest/fastest region's IP	Multi-region latency
Weighted	Send X% of traffic to each endpoint	Canary/blue-green rollouts
Failover	Health-check endpoints; return only healthy ones	Regional failover

This is GSLB (Global Server Load Balancing) — the reason a user in Tokyo and one in London hit different data centers for the same hostname.

Anycast: One IP, Many Locations

Big DNS providers announce the same IP from many locations via Anycast routing, so a query is automatically delivered to the nearest server. This gives low latency and built-in DDoS resilience, and it's how root/TLD servers and CDNs stay fast globally.

2D minimalistic diagram showing geo-based DNS routing: a user in Asia and a user in Europe both request the same hostname, and the DNS layer returns different regional IPs — the Asian user gets the Tokyo data center IP and the European user gets the Frankfurt data center IP, each connecting to their nearest region

Seeing It in Action

Scenario: Using DNS for a zero-downtime regional failover.

Setup: app runs in us-east and eu-west. DNS provider health-checks both.

Normal state:
  api.example.com  →  latency-based routing
    US users  → us-east IP  (34.x.x.x)
    EU users  → eu-west IP  (18.x.x.x)
  TTL kept at 60s so changes propagate fast.

us-east has an outage:
  1. DNS health check fails for us-east (3 consecutive failures)
  2. DNS provider stops returning the us-east IP
  3. Within ~1 TTL (60s), US users' resolvers refresh and get eu-west IP
  4. US traffic now served from eu-west (higher latency, but UP)

Once us-east recovers:
  Health checks pass → us-east re-enters rotation → US users routed back.

Why the 60s TTL is the hero here: if the TTL were 24 hours, failover would be nearly useless — most users would keep resolving to the dead region for hours. The cost is more DNS queries, but for a hostname that needs fast failover, that's a worthwhile trade. This is why DNS TTL is a reliability decision, not just a performance one.

Interview Questions

Q: Walk through what happens, DNS-wise, when you type a URL and hit enter. Hint: The browser/OS checks its cache, then asks a recursive resolver. If uncached, the resolver queries a root server (→ TLD server for .com), then the TLD server (→ authoritative name server), then the authoritative server (→ the IP). The resolver caches the answer per its TTL and returns it; the browser connects to the IP. Caching at each level means most lookups short-circuit.
Q: What is TTL in DNS and what's the trade-off in setting it? Hint: TTL is how long resolvers may cache a record. Short TTL = fast propagation and quick failover, but more query load. Long TTL = fewer queries and resilience to resolver outages, but slow propagation and failover blocked by stale caches. Lower TTLs before a planned migration so changes take effect quickly.
Q: How can DNS be used for load balancing and failover? Hint: By returning different/multiple answers: round-robin across A records, geo/latency-based routing to the nearest region, weighted routing for canaries, and health-checked failover that removes unhealthy endpoints. This is GSLB — steering users to the best or nearest data center at resolution time. Limitation: client caching/TTL bounds how fast it reacts.
Q: What is Anycast and why is it useful for DNS (and CDNs)? Hint: Anycast announces the same IP address from many geographic locations; BGP routing delivers each request to the nearest instance. Benefits: low latency (nearest server answers), high availability, and DDoS resilience (attack traffic is spread across many sites). It's how root/TLD servers and CDN edges stay fast and robust globally.
Q: Why is DNS a common cause of outages despite being "just name resolution"? Hint: It's a critical dependency for every connection, changes propagate slowly due to caching/TTL, misconfigurations (wrong records, expired domains, bad TTLs) are easy to make and slow to undo, and it's a DDoS target. A DNS provider outage or a propagation delay can make healthy services unreachable. "It's always DNS" reflects how central and unforgiving it is.

References

Cloudflare: What is DNS? — clear primer on resolution and records
How DNS Works (comic) — friendly visual walkthrough
AWS Route 53 routing policies — geo, latency, weighted, failover routing

Dive Deeper

DNS and BIND by Cricket Liu — the definitive DNS book
Cloudflare: A deep dive into DNS — DNSSEC and advanced topics
The Facebook 2021 outage postmortem — how a BGP/DNS interaction took down a giant