DNS load balancing

Why it matters

A load balancer has one address, and that address lives in one place. To spread traffic across regions, or across several independent balancers, the decision has to be made before the client connects, at the point where it looks up the name. That is DNS load balancing: the only balancing layer that works across the whole planet, and the one with the least control over what clients actually do.

The idea

The authoritative DNS server for your name answers each lookup with an address chosen by a policy, so different clients are steered to different endpoints.

Policy	Answers with	Good for	Limit
Round robin	A rotating order of several addresses	Crude spreading across a few balancers	Clients and resolvers cache; distribution is uneven
Weighted	Addresses in proportion to weights	Canary regions, gradual migrations	Granularity bounded by cached answers
Latency-based	The region with lowest measured latency to the resolver	Multi-region user experience	Measures the resolver, not the user
Geolocation	The region mapped to the resolver's location	Data residency, language, compliance	Resolver location can differ from the user's
Failover	Primary while healthy, secondary otherwise	Active-passive regions	Health check and TTL set the failover time

Health-checked records combine with any policy: the provider probes each endpoint and stops returning addresses that fail. Many providers bundle these policies as global server load balancing or "traffic management".

Why it is coarse

DNS was designed as a cache, and caches resist change. Resolvers hold answers for the TTL, some longer; browsers and operating systems cache addresses themselves; a single corporate resolver may front a hundred thousand users, so one answer steers all of them. The provider also sees the resolver's address, not the user's, which is why latency and geo policies are approximate (the EDNS client-subnet extension narrows this, when resolvers support it). DNS can therefore shift traffic in minutes and in large lumps, which is fine for regions and useless for per-request balancing.

Where it fits

Use DNS to choose a region or an entry point, then a real load balancer to choose a server. Keep TTLs short on these records (30 to 60 seconds) so failover and weight changes take effect quickly, and accept that a slice of traffic will lag. For the hardest cases, anycast (next lesson) moves the region decision from DNS into the network itself.

Trade-offs

DNS balancing is global and cheap and works with any client, but it is approximate, slow to react and blind to server load. Short TTLs improve agility and raise lookup volume. Geo policies help compliance and can mis-route users on VPNs or distant resolvers. The failure mode to name is split traffic during a failover: for up to a TTL (or longer), some clients keep arriving at the region you are trying to drain, so that region must keep serving or redirecting.

In an interview

Introduce it exactly when regions appear: "Each region has its own load balancer; latency-based DNS with a 60-second TTL and health checks sends users to the nearest healthy region. Failover between regions therefore takes about a minute, and the failed region's balancer stays up to redirect stragglers." Saying the limit yourself prevents the interviewer from having to.