Multiple A Records: Round-Robin DNS, Load Balancing & Its Real Limits

What Happens When One Name Has Several Addresses

Nothing in the DNS specification says a hostname can only have one A record. Publish three, and any resolver that queries the name gets back all three, typically in a rotated or randomized order from one query to the next — a pattern generally called round-robin DNS. It's the oldest, simplest form of load distribution the internet has, predating dedicated load balancer hardware and application-layer traffic managers by a wide margin, and it's still genuinely useful today, provided you understand exactly what it does and, more importantly, what it doesn't.

This guide covers both halves: how multiple A records actually get used by clients, and the real operational limits that catch people who assume it behaves like a full-featured load balancer.

How Clients Actually Use Multiple A Records

When a resolver returns several A records for one name, the client application decides what to do with the list — DNS itself doesn't dictate this. Most modern clients pick one address to connect with (often the first in the list, though ordering isn't guaranteed to be meaningful) and, if that connection fails, fall back to trying the next address in the list. This is genuinely useful resilience: a single dead server among several doesn't necessarily break the connection for a client that implements sensible fallback behavior, though not every client library does this equally well, and some simply use the first address and give up on failure.

The Core Limitation: DNS Doesn't Know What "Healthy" Means

This is the single most important thing to understand about round-robin DNS, and the thing most often assumed away. Plain DNS has no concept of server health whatsoever. If one of three servers behind a round-robin A record set crashes, DNS keeps handing that server's IP out in rotation exactly as often as the two healthy ones, indefinitely, until a human or an external automated system removes that specific record. A DNS server answering a query has no visibility into whether the IP address it's returning actually has anything listening on the other end.

This is a fundamentally different failure model from an actual load balancer, which continuously health-checks backend servers and stops routing to any that fail, typically within seconds. Round-robin DNS, left unmanaged, can silently keep sending a fraction of visitors to a dead server for as long as that record remains published — which, depending on TTL, could be hours if nobody's watching.

Round-Robin DNS vs a Real Load Balancer

Static vs Dynamic Approaches to Multiple A Records

A static configuration — several A records added manually and left alone — works fine for genuinely stable infrastructure where servers rarely change and health issues are rare and quickly noticed by other monitoring. A dynamic approach uses automation (health-check-driven DNS updates, or a managed DNS provider's built-in traffic policies) to add and remove records based on real server status, closing the biggest gap round-robin DNS has on its own.

Geo-Distribution With Multiple A Records

Some DNS providers offer geo-aware responses — returning a different subset or ordering of A records depending on where the query originated, routing a European visitor toward a European server IP and an Asian visitor toward an Asian one. This isn't part of plain, standards-based round-robin DNS; it's a provider-specific feature layered on top, using the resolver's apparent location (often derived from EDNS Client Subnet information) to customize the answer. It's a genuinely different mechanism from simple rotation, worth distinguishing when evaluating whether a DNS provider's "load balancing" claim matches what you actually need.

CDNs and Anycast: A Related but Distinct Pattern

Content delivery networks often publish what look like multiple A records, but frequently these are anycast addresses — the same IP announced from many physical locations simultaneously, with network-layer routing (not DNS) determining which physical location a given connection actually reaches. This is a different mechanism from client-side round-robin selection among genuinely distinct IPs, even though both can appear as "multiple A records" in a casual lookup. Anycast solves the health and proximity problem at the network routing layer instead of leaving it to DNS or client behavior.

Common Mistakes

Best Practices

• Pair multiple A records with genuine external monitoring, not just DNS itself, for anything production-critical.
• Keep TTL low enough that removing a bad record actually helps within a reasonable window.
• For workloads needing real health-aware failover, use a load balancer or a DNS provider's health-check-integrated traffic policy, not plain static round-robin.
• Don't assume even distribution — design for the possibility that traffic skews toward whichever record a given client or caching resolver happened to pick up first.

Related Tools

Check exactly how many A records a domain currently publishes with A Record Lookup, which flags round-robin configurations directly in its results. For the full DNS picture, use DNS Lookup, and to verify a record removal has actually propagated, check DNS Propagation Checker. If you're deciding between record types for a given hostname, see A Record vs CNAME.