Stage 3 · Build
DNS: The Phone Book of the Internet
DNS at Scale
Anycast DNS, GeoDNS, latency-based routing, and failover.
Anycast DNS
Anycast is a routing technique where the same IP address is announced from multiple locations. When a client queries that IP, BGP routes them to the nearest location. Cloudflare, Google, and all root DNS servers use anycast.
Client in New York queries 1.1.1.1 (Cloudflare)
-> BGP routes to Cloudflare's NYC data center (5ms)
Client in Tokyo queries 1.1.1.1 (Cloudflare)
-> BGP routes to Cloudflare's Tokyo data center (3ms)
Same IP, different physical servers, nearest path.Anycast eliminates the need for GeoDNS in many cases. BGP naturally routes queries to the nearest endpoint. If a data center goes offline, BGP withdraws the route and traffic shifts to the next nearest location automatically.
Anycast is a network-layer technique that happens to be extremely useful for DNS. It works for any UDP-based service. DNS is a perfect fit because queries are small, responses are small, and there is no connection state to maintain.
GeoDNS and Latency-Based Routing
GeoDNS returns different answers based on the geographic location of the querying resolver. Latency-based routing goes further — it returns the IP of the endpoint with the lowest measured latency to the client.
Query from US East Coast:
api.example.com -> 52.10.1.100 (us-east-1)
Query from Europe:
api.example.com -> 52.10.2.100 (eu-west-1)
Query from Asia:
api.example.com -> 52.10.3.100 (ap-southeast-1)GeoDNS reduces latency by directing users to the nearest data center. It also provides resilience — if one region goes down, DNS can return a healthy region's IP instead.
DNS Load Balancing
DNS-based load balancing returns multiple A records and relies on clients to connect to one. It is simple but has limitations: TTL-dependent caching means changes propagate slowly, and clients may not distribute evenly.
# Multiple A records for round-robin
$TTL 300
@ IN A 10.0.1.1
IN A 10.0.1.2
IN A 10.0.1.3
IN A 10.0.1.4
# Weighted records (some providers support this)
$TTL 300
api IN A 10.0.1.1 ; primary (higher weight)
IN A 10.0.1.2 ; secondaryBasic round-robin DNS rotates the order of records. Some DNS providers support weighted responses, giving you more control over traffic distribution. But DNS load balancing is coarse — use a proper load balancer for fine-grained control.
DNS load balancing is not real load balancing. Clients cache the answer and always connect to the same IP. If one server is under heavy load, DNS cannot redirect traffic away from it until the TTL expires. Use a real load balancer for production traffic.
CDN DNS Architecture
CDNs use DNS to direct users to the nearest edge server. When you request a CDN-hosted asset, the DNS query returns the IP of the edge server closest to you. The CDN handles caching, TLS termination, and origin fetches.
1. User requests cdn.example.com/image.jpg
2. Browser resolves cdn.example.com via DNS
3. CDN DNS returns nearest edge IP (e.g., 151.101.1.1)
4. Browser connects to edge server
5. Edge server checks cache
- HIT: return cached response (< 10ms)
- MISS: fetch from origin, cache, return
6. Response served from edge (typically < 50ms RTT)The CDN's DNS is the brain that decides where traffic goes. It considers geographic proximity, server load, health status, and capacity. This happens at DNS resolution time, before any HTTP request is made.
Global Traffic Management
Active-Passive:
primary.us-east.example.com -> 10.0.1.1 (active)
secondary.us-west.example.com -> 10.0.2.1 (passive, on standby)
Active-Active:
us-east.example.com -> 10.0.1.1
eu-west.example.com -> 10.0.2.1
ap-east.example.com -> 10.0.3.1
(all active, receiving traffic)
Failover:
health check detects primary down
DNS TTL expires (30-60 seconds)
DNS returns only secondary IP
Traffic shifts to secondaryGlobal traffic management uses DNS health checks to detect failures and route traffic accordingly. The TTL controls how quickly failover happens — lower TTL means faster failover but more DNS queries.
If you need fast failover, keep DNS TTLs at 30-60 seconds. For cost optimization with no failover requirement, 300-3600 seconds is fine. Always test failover by simulating a DNS switch — do not wait for an incident to find out it does not work.
Mark this lesson complete to store local progress and unlock a cleaner resume path the next time you visit.