DNS load balancing

DNS load balancing is the pattern of distributing user traffic across multiple servers by returning different IP addresses in DNS responses. The simplest form is "round-robin DNS": you list multiple A records for the same hostname, and resolvers rotate through them.

api.example.com. IN A 203.0.113.10
api.example.com. IN A 203.0.113.11
api.example.com. IN A 203.0.113.12

Each resolver gets a different ordering, so clients distribute across the three IPs.

The classic problem with round-robin DNS

• No health awareness. If 203.0.113.11 is down, the DNS server still hands it out to one-third of users. Clients see errors.
• Caching. Once a resolver has cached an A record, it returns the same answer until TTL expires. Real load distribution depends on TTL being short.
• Sticky users. A returning user often gets the same answer from their cached resolver. Not great for spreading load uniformly.

Smarter DNS load balancing

Modern managed DNS (Route53, NS1, Cloudflare, Akamai, DNSimple) offers weighted, latency-aware, and health-checked DNS:

• Weighted routing. Send X% to region A, Y% to region B. Good for gradual rollouts or A/B testing.
• Health checks. DNS provider periodically probes each origin; pulls dead ones out of the response automatically.
• Latency-based routing. Resolver-aware routing to the lowest-latency origin.
• Geolocation-based routing. Send EU resolvers to EU origins.

When DNS load balancing isn't enough

If you need sub-second failover, request-level health awareness, or session stickiness, DNS isn't the right layer. Use:

• A real load balancer (ALB, NLB, HAProxy, nginx) in front of your origins. Health-checks every few seconds; failover within seconds.
• Anycast IPs (typically via your CDN), so the network picks the nearest healthy PoP.

DNS load balancing is the cheap, coarse, geo-aware first layer. The real fine-grained balancing happens at the load balancer one hop deeper.

In a SaaS

For most apps, DNS load balancing is:

• One layer above your CDN or load balancer.
• Geo or latency routed across regions.
• Tied to health checks so failed regions drop out of the rotation.

You don't usually use raw round-robin DNS in production for an HTTP service; you use the smarter primitives. Round-robin is mainly useful for protocols that can't fall back well (a few legacy protocols) or for very simple multi-region setups.