DNS Failover and Round-Robin: What Multiple A Records Can and Cannot Do

Publishing several A records for one hostname is the oldest trick in DNS for spreading traffic, and it is also one of the most misunderstood. Plain round-robin DNS hands out multiple addresses in rotating order, which spreads load in a crude way but does nothing when a server dies: DNS has no idea the target is down and keeps returning its address. Real failover needs health checks at the DNS provider, short TTLs, and an honest understanding of resolver caching. This guide explains what multiple A records actually do, why they are not failover on their own, how health-checked DNS failover works, and when you should stop using DNS for this and put a load balancer behind a single record instead.

What round-robin DNS actually does

Round-robin means you publish two or more A records on the same name. The authoritative server returns all of them, rotating the order on each response so different clients tend to pick different addresses:

dig +short A app.example.com
203.0.113.10
203.0.113.11
203.0.113.12

Most clients use the first address in the list they receive, so rotating the order roughly distributes connections across your servers. That is the entire mechanism. It is simple, free, and built into every DNS provider, which is why it is everywhere.

Why round-robin is not failover

Round-robin distributes addresses; it does not know whether any of them work. Three facts make it unsafe to rely on for availability:

• DNS has no health awareness. If 203.0.113.11 crashes, the authoritative server keeps returning it in the rotation. A share of your users keep getting handed a dead address.
• Resolver caching skews distribution. A busy corporate or ISP resolver caches one answer order and serves it to thousands of users for the length of the TTL, so your "even" spread is lumpy in practice.
• Client behavior varies. Some clients always take the first record; others reorder. You do not control how the list is consumed.

There is one saving grace at the client layer. Modern browsers and many libraries implement Happy Eyeballs connection racing: when the first address refuses or times out, they quickly retry the next address in the record set. That means a hard-down server is often masked for interactive web traffic, because the browser silently falls over to a sibling address. But this is a client courtesy, not a guarantee. Older clients, bare API consumers, and SMTP senders may not retry, and a server that is listening but broken (returning errors rather than refusing the connection) will not trigger a retry at all.

Health-checked DNS failover

To make DNS actually fail over, the DNS provider has to probe each endpoint and remove the unhealthy ones from the answer. The provider runs checks on a fixed interval from multiple vantage points. When an endpoint fails its checks, the provider stops returning that record, so new lookups only get healthy addresses.

Two patterns are common:

Active-active with health checks

All endpoints serve traffic, and the provider drops any that fail probes. This is round-robin with a safety net: you still spread load, but a dead server leaves the rotation automatically.

Active-passive failover

A standby record is served only when the primary fails its health check. Normal traffic goes to the primary; if it goes down, the provider swaps in the backup address.

# Primary healthy -> clients get the primary
dig +short A app.example.com
203.0.113.10

# Primary fails health check -> provider serves the standby
dig +short A app.example.com
198.51.100.20

The hard limit: TTL and caching

Even perfect health checks cannot beat DNS caching. The authoritative TTL is the lower bound on how fast a changed answer reaches clients, not the actual time. If a bad address is sitting in resolver caches with a 300-second TTL, the slowest clients keep hitting it for most of those five minutes even after your provider has pulled it. This is why failover setups use short TTLs, typically 30 to 60 seconds, on the records that may change.

Short TTLs are a trade-off. They raise query volume against your authoritative servers and can cost more on metered DNS providers. They also assume resolvers honor your TTL; some aggressively cap very low TTLs upward. Plan for failover time to be your TTL plus the probe interval plus a margin for stubborn caches, never the TTL alone.

When a load balancer belongs behind a single record

DNS failover operates at the granularity of whole addresses and whole TTL windows. For anything that needs sub-second reaction, session stickiness, or per-request health awareness, the right answer is a load balancer behind one stable record. You point a single A record (or a CNAME) at the load balancer, and it handles health checks and traffic distribution at the connection layer, far faster than DNS can.

A practical decision guide

• Just spreading read traffic across a few stateless servers? Plain round-robin is fine, and client retry will cover most hard failures.
• Availability matters and you cannot tolerate dead addresses in rotation? Add DNS health checks and lower the TTL to 30 to 60 seconds.
• You have a primary and a disaster-recovery site? Use active-passive DNS failover and accept failover time measured in a minute or two.
• You need instant, intelligent routing? Put a load balancer behind a single record and let it do the work.

Whatever pattern you choose, verify what resolvers are actually returning rather than trusting the control panel. Run your hostname through the Valla DNS propagation checker to see the live answers from resolvers around the world and confirm your TTLs, then explore our related guides in the Valla DNS learning hub on TTL strategy and DNS record types to tune the setup further.