DNS Load Balancing and High Availability

Every technique on this page does one fundamental thing: it controls which IP address a client ends up talking to — either by handing out a different answer at resolution time (round-robin, geo-DNS/GSLB) or by making a single IP physically resolve to different machines depending on where the packet enters the network (anycast). So load balancing and failover in DNS come down to two questions: who controls the answer, and how long does that answer live? The second question — the TTL — is the ceiling on how fast DNS-based failover can possibly be, and it is where most real outages come from.

Round-robin DNS: rotate the answer

Attach several A records to one name; the authoritative server rotates their order on each response, so successive resolvers get a different address first and most clients simply use the first one. A zone looks like this:

example.com.   300  IN  A  192.0.2.10
example.com.   300  IN  A  192.0.2.11
example.com.   300  IN  A  192.0.2.12

Tracing the rotation on cache-miss queries to the authoritative server:

The catch that makes distribution uneven: rotation happens per cache-miss, not per client. A recursive resolver caches the whole record set for the full TTL (300s here) and may serve one frozen ordering to all its downstream users until it expires — or rotate the cached set per response, depending on resolver configuration (BIND's default cyclic rrset-order, Unbound's rrset-roundrobin); either way the set is frozen for the TTL, including any dead member. One large ISP or corporate NAT resolver can therefore pin tens of thousands of users onto a single IP for five minutes. Round-robin sees neither server load nor client geography nor server health — it just cycles.

The TTL problem: why DNS failover is slow

This is the key high-availability limitation the naive catalog skips. Watch one server die with a 300-second TTL, health-checked and removed the instant it's detected:

Effective failover window ≈ detection time + remaining TTL + client-side caches (browsers pin DNS ~60s and hold open keep-alive TCP connections to the dead IP even longer). Worst case for a freshly-cached resolver is close to the full TTL after removal. Lowering the TTL shrinks this window but multiplies query volume against your authoritative servers — and, as the pitfalls note, many resolvers clamp or ignore very low TTLs anyway.

Geo-DNS and GSLB: make the answer smart

A Global Server Load Balancer is an authoritative DNS server wired to health checks and policy. It inspects the query's source IP (or the EDNS Client Subnet option carrying the real client's network) and returns a tailored answer: the nearest region, a weighted split for a canary, or an active-passive DR failover — and it omits any IP whose health probe is failing. This adds the health and geography awareness round-robin lacks. But it is still DNS: every answer carries a TTL, so failover is still bounded by that same TTL + detection + client caches. Route 53 latency/weighted routing, NS1, Akamai GTM and F5 GTM are GSLBs.

Anycast: fail over below the TTL

Anycast announces the same IP address into BGP from many points of presence (PoPs) at once. The internet's routing fabric delivers each packet to the topologically nearest PoP announcing that prefix — no DNS answer changes, no TTL is consulted. When a PoP dies, it stops announcing the route; BGP withdraws it and traffic reconverges to the next-nearest PoP in seconds, independent of any cache. This is why every root DNS server and every major CDN edge runs on anycast. The cost is control and statefulness: you steer by network topology, not by weight or per-geo policy, and a route change mid-flow can reset a long-lived TCP connection — fine for stateless UDP DNS, dangerous for naive anycast of long HTTP/TCP sessions.

The contrast that should drive your design: DNS-based failover waits out caches (the timeline above), anycast failover waits out BGP convergence.

CDNs compose all three

A CDN is not a fourth peer technique — it is these mechanisms stacked. Your DNS record CNAMEs to the provider (www.example.com. CNAME example.map.cdn.net.); the CDN's authoritative DNS is a GSLB that returns an anycast (or geo-steered) edge address; the edge PoP that finally serves the packet was reached by anycast. When you point a site at a CDN you inherit its anycast failover and its GSLB health routing for free.

One trap: this CNAME works for www.example.com but is illegal at the zone apex — example.com itself must carry SOA and NS records, and RFC 1034 forbids a CNAME from coexisting with other data at the same name. Providers work around it with synthetic apex records (Route 53 ALIAS, Cloudflare CNAME flattening): the authoritative server chases the target itself and returns plain A/AAAA answers, so the apex behaves like a CNAME without being one — at the cost of the TTL and geo-answer now being controlled by YOUR authoritative provider, not the CDN's.

Pitfalls

• The TTL you set is advisory. Resolvers may clamp it to a minimum (often 30–60s), cap a maximum, or — with buggy or aggressive caches — ignore it entirely. Setting TTL=0 does not buy instant failover; it just hammers your authoritative servers while many resolvers floor it anyway.
• Browser/OS caches and connection pinning outlive the DNS change: an open HTTP keep-alive connection stays glued to the old IP even after the record is fixed.
• Round-robin is not even load balancing. Caching pins whole populations behind one busy resolver to a single IP for the TTL, and it never sees CPU, connections, or health.
• Geo/GSLB misroutes centralized public resolvers. If routing keys off the resolver's IP, users of 8.8.8.8 look like they're wherever Google's resolver is — unless EDNS Client Subnet is used, and ECS in turn fragments the cache (lower hit rate, more load).
• Anycast + long-lived TCP is risky: a mid-session route flap can land packets at a different PoP and reset the connection. Safe for UDP DNS; needs care for anycast HTTP.
• DNS failover is coarse regional steering, not HA for the load-balancer tier. Do not rely on it for sub-second or per-request failover.

When to use which — and when not to

Round-robin DNS — choose it when you want dead-simple, zero-cost spreading across a few endpoints and can tolerate minutes-scale failover and lumpy load. Prefer a real L4/L7 load balancer behind a single VIP when you need per-request balancing, health-based ejection in seconds, and even distribution.

Anycast — choose it when failover must be seconds and transparent to clients, latency must be minimal, and traffic is stateless/UDP or short TCP (DNS itself, CDN edges); it costs BGP/AS operational expertise, gives only coarse topology-driven control, and endangers long TCP flows. Prefer GSLB/geo-DNS when routing must be policy- or health-aware (weights, canaries, per-geo answers) rather than purely topological.

GSLB / geo-DNS — choose it for health-aware, policy-driven routing across regions (active-passive DR, latency-based, weighted rollout) where TTL-scale failover is acceptable; it costs you TTL-bound recovery, ECS cache fragmentation, and vendor lock-in. Prefer anycast when you need faster, cache-independent failover and don't need per-request policy.

Decision in one line: pick anycast when failover must beat the TTL; pick GSLB/geo-DNS when the answer must be policy- and health-aware and minutes are fine; use round-robin only for cheap coarse spreading — and put a real L4/L7 load balancer with health checks behind whichever answer to do the actual per-request balancing inside each region.

Takeaways

• DNS load balancing chooses the answer; it never sees the actual request load — it is coarse, regional steering, not per-request balancing.
• The TTL is the hard ceiling on DNS-based failover, and resolvers may clamp or ignore it, so real recovery ≈ detection + remaining TTL + client caches.
• Anycast fails over at BGP convergence (seconds), independent of TTL and caches, but trades away fine-grained control and safe long-lived TCP.
• Layer them: anycast/GSLB/round-robin for cross-region steering, plus a real L4/L7 load balancer with health checks for per-request balancing within a region.

Re-authored/Deepened for this guide. Sources: RFC 1035 (TTL and caching semantics), RFC 4786 (operation of anycast services); Cloudflare Learning Center (What is anycast?, DNS load balancing); AWS Route 53 documentation (routing policies, DNS health checks, TTL guidance); NS1/Akamai GSLB documentation; Tanenbaum & Wetherall, Computer Networks; and the original educative/Grokking DNS chapter that this page expands.