DNS load balancing

DNS load balancing distributes traffic by returning different IP addresses to different clients from the same hostname. In its simplest form, round-robin DNS, you publish several A records for one name and let resolvers hand them out in rotation. Managed DNS services add weights, health checks and geographic steering on top.

It is the cheapest way to spread traffic across regions and the worst way to fail over, and the gap between those two facts is what this page is about.

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

What the biggest sites actually publish

Before taking anyone's architecture advice, look at what production zones return. Queried against each domain's own authoritative nameserver on 2026-08-19:

Site	A records returned	Authoritative TTL
github.com	1	60s
shopify.com	1	60s
x.com	1	300s
cloudflare.com	2	300s
stripe.com	2	30s
amazon.com	3	900s
netflix.com	3	60s
reddit.com	4	300s

Two patterns worth copying.

Three of the eight publish a single address. GitHub, Shopify and X do no DNS load balancing at all on their apex. They put one anycast address in DNS and balance underneath it, at the network and at the load balancer. DNS is not carrying the traffic decision; it is carrying one stable pointer.

Nobody uses a long TTL. The range here is 30 to 900 seconds, clustered at 60 to 300. The advice you still see to set a 3600-second TTL on records you intend to steer is simply wrong: TTL is the resolution of every routing decision you make in DNS. Stripe runs 30 seconds on two addresses, which buys tight control at the cost of a fresh query from every recursive resolver twice a minute. Amazon's 900 seconds across three addresses is the opposite trade, and it tells you Amazon is not relying on those records for failover.

We also checked whether resolvers really do rotate. Over five consecutive queries to 1.1.1.1, reddit.com returned three distinct orderings of its four addresses and amazon.com three orderings of its three. Rotation is real. It is just not the same thing as balance.

Why round-robin is not load balancing

Four reasons, and only the first one is widely known.

No health awareness. A plain A record set has no idea one of its addresses is dead. A third of your users keep getting it until someone edits the zone.

You are weighting resolvers, not users. DNS sees resolver populations, not people. One large ISP resolver behind millions of users counts once. Traffic splits end up lumpy in a way no amount of weighting in the control panel fixes, because the control panel is weighting answers, not sessions.

Caching makes users sticky. Once a resolver has an answer, everyone behind it gets the same answer until the TTL expires. Within a TTL window your "balanced" traffic is a set of large sticky blocks. See DNS cache and DNS resolution for the mechanics, and DNS propagation for why an edit is not instant.

The client reorders you anyway. This one surprises people. RFC 6724 tells the operating system how to sort candidate destination addresses, and RFC 8305 (Happy Eyeballs v2) tells the browser to race the first few in parallel and keep whichever connects first. Browsers also keep their own internal DNS cache independent of the record's TTL. Whatever order your nameserver picked is a suggestion that three layers of client software are free to ignore.

What managed DNS adds

Every serious provider layers real routing policies on top of the record set:

• Weighted routing. Split by percentage, for gradual rollouts or migrations between two stacks.
• Health checks. The provider probes each origin and stops answering with the dead ones. This is the feature that turns round-robin into something usable, and it is what DNS failover means in practice.
• Latency-based routing. Answer with the origin measured fastest from the resolver's location.
• Geo routing. Send European resolvers to European origins, usually for data residency rather than speed.

The caveat that applies to all four: they steer at resolver granularity, and their reaction time is a health-check interval plus a TTL. Assume tens of seconds at best, minutes in the normal case.

Failover math, honestly

The number people want is "how fast does DNS fail over". Add these up:

1. Detection. Health-check interval times the failure threshold. Typically 30 to 120 seconds.
2. Propagation of the new answer. Up to the record's full TTL for any resolver that just cached the old one.
3. Client cache. Browsers and JVMs hold their own entries. The JVM historically cached DNS forever under a default networkaddress.cache.ttl of -1 when a security manager was installed, and long-running services still hit variants of this.

A 60-second TTL with a 30-second check does not give you 60-second failover. It gives you something in the range of a minute and a half to three minutes for most users and longer for the unlucky ones. If your requirement is measured in seconds, DNS is the wrong layer and you want anycast plus a real load balancer at the edge, where withdrawal of a route or a failed health check takes effect without any client needing to look anything up again.

When DNS is the right layer

It is genuinely the correct tool for:

• Region and multi-CDN steering, where decisions are coarse and change slowly.
• Gradual migrations, shifting a few percent at a time between two stacks.
• Disaster failover with an accepted recovery time of minutes, not seconds.
• Protocols with no smarter option, where there is no CDN or L7 proxy in front.

And it is the wrong tool for per-request balance, session stickiness, sub-second failover, or anything that needs to know about server load right now.

The apex problem, and why it pushes you here

You cannot put a CNAME at an apex domain. That single rule is why so many teams end up hand-managing A records at the root and calling it DNS load balancing when what they wanted was a hostname pointing at someone else's load balancer.

The real fixes are ALIAS or ANAME records and CNAME flattening, where the DNS provider resolves the target for you and serves the resulting addresses at the apex with the target's own TTL. That gives you the target's load balancing rather than a frozen copy of it. Route 53's Alias records do the same thing but only for AWS resources and same-zone records, not arbitrary third-party hosts.

Checking what you are actually serving

# What does the authoritative nameserver say, cache bypassed?
dig @$(dig +short NS example.com | head -1) example.com A

# What is each public resolver handing out right now?
for r in 1.1.1.1 8.8.8.8 9.9.9.9; do dig @$r +short example.com A; done

The DNS record lookup shows the full record set with TTLs, the DNS propagation checker shows which resolvers are still serving an old answer, and the website status checker tells you whether the addresses you are handing out are answering at all. For the record a customer points at you, the CNAME lookup resolves the chain.

In a multi-tenant SaaS

For a platform serving custom domains, DNS load balancing is not usually your problem, because your customers' records point at your edge and the edge does the balancing. What matters is the opposite property: the hostname you ask customers to CNAME to should be stable and short-TTL, so you can move your own infrastructure without asking thousands of customers to change anything.

Domainee is a custom domains API for SaaS with a native MCP server — 50 domains and 100 GB free. Customers point one CNAME at the platform and the routing behind it is ours to change. If you are wiring this up yourself, connecting custom domains to your SaaS covers the record set your customers need, and the DNS API page covers automating it.

FAQ

What is a DNS load balancing service? A managed DNS provider that answers queries with different addresses based on a policy rather than a static list: weights, health checks, latency or geography. Route 53, NS1, Cloudflare, Akamai, Azure Traffic Manager and DNSimple all sell this. The distinguishing feature over plain round-robin is that the provider probes your origins and stops advertising the ones that fail.

Is round-robin DNS good enough for production? Only for services that tolerate a portion of requests hitting a dead address for the length of a TTL. It has no health awareness, so a failed origin keeps being handed out. Add health checks or put a real load balancer behind a single address.

How fast can DNS fail over? Detection time plus TTL plus client-side caching. With a 60-second TTL and a 30-second health check, realistic recovery is roughly one and a half to three minutes, not 60 seconds. Anything tighter belongs at the anycast or load-balancer layer.

What TTL should I use for load-balanced records? Between 30 and 300 seconds. Of eight major sites we measured, the authoritative TTLs ran 30 to 900 seconds and clustered at 60 to 300. Long TTLs make DNS-level steering useless, since the TTL is the granularity of every decision you make.

Does DNS load balancing distribute traffic evenly? No. It distributes answers across resolvers, and resolvers sit in front of wildly different numbers of users. Combined with caching and client-side address selection, even a perfectly even answer split produces a lumpy traffic split.

Should I use DNS load balancing or anycast? Anycast for latency and fast failure handling, DNS for coarse policy you want to change from a control panel. Most large sites use both: an anycast address in DNS with a short TTL, and the routing decisions made in the network rather than in the answer.