Round-Robin DNS: Load Balancing With Nothing but Multiple A Records

Round-robin DNS doesn't require any special record type or configuration flag. It's just what happens when a hostname has more than one A record:

example.com.    A    203.0.113.10
example.com.    A    203.0.113.11
example.com.    A    203.0.113.12

Three servers, one name, no load balancer in front of any of them. It's the simplest form of distributing traffic across multiple servers that DNS offers, and it's simple in a way that comes with real limitations worth knowing before relying on it.

How the "rotation" actually happens

A resolver querying a name with multiple A records typically gets all of them back in one response, and many authoritative nameservers rotate the order of that list on each query, which is where the "round-robin" name comes from. But that rotation only controls the order servers appear in the answer, not which one actually gets used, and that final choice happens somewhere else entirely. A browser or OS-level resolver library might pick the first address in the list every time, might pick randomly, or might implement something more deliberate like Happy Eyeballs for connection racing. DNS itself has no say in that last step. It just hands back a list.

What round-robin DNS doesn't do

No health checking. DNS has no concept of whether 203.0.113.11 is actually alive right now. If that server crashes, its A record keeps getting handed out in the rotation exactly as before, sending a fraction of traffic to a dead server until someone notices and manually removes the record.

No weighting. All records for a name are treated as equally preferred. There's no way to say "send twice as much traffic to this bigger server" the way SRV records support with their weight field for the protocols that use them, and no equivalent mechanism exists for plain A records.

Caching works against fast recovery. A resolver that cached one specific address keeps using it for the remainder of that record's TTL, the same caching behavior covered in TTL explained, so removing a dead server's A record doesn't instantly stop clients who already cached it from trying to reach it.

Round-robin vs. an actual load balancer

A real load balancer, hardware or software, actively health-checks its backends and stops routing to one that fails, often within seconds. Round-robin DNS does none of that. It's blind in both directions: it doesn't know a server died, and it has no mechanism to react even if it did. The "balancing" is really just distribution, spreading requests across a fixed list, with all the actual intelligence left to whatever's downstream of the DNS answer, if anything is watching at all.

Where it's still used

Round-robin DNS shows up as one layer in front of infrastructure that has its own health-awareness elsewhere, a set of load balancer IPs behind a single name, for instance, rather than as the sole traffic-management mechanism for anything that matters. It's also common in smaller or legacy setups where the simplicity is the point: a handful of interchangeable servers, none of which are expected to fail often, where manually pulling a record on the rare occasion one does is an acceptable trade for not running separate load-balancing infrastructure at all.

The real risk: a dead server nobody's watching

The practical danger isn't the technique itself, it's the assumption that DNS is doing more than it actually is. A team that sets up round-robin A records and doesn't separately monitor whether each individual server is actually healthy has no way of knowing that a fraction of their traffic is quietly failing, since DNS will keep handing out the dead server's address with total confidence until a record is manually removed.

Checking a domain's round-robin setup

dig A example.com +short

More than one address in the response means round-robin is in play. Running this repeatedly against different public resolvers can also show whether the rotation order actually changes between queries, or whether a particular resolver is caching and returning the same order every time. OneDollarDNS's DNS resolver comparison tool does this in one query across Google, Cloudflare, Quad9, and OpenDNS instead of running dig against each manually.

How DNS monitoring fits in

OneDollarDNS catches the DNS-visible half of this: if an A record is added to or removed from the rotation, that's a monitored change like any other. What it doesn't do, and what round-robin DNS structurally can't do on its own, is tell you whether one of the addresses currently in the set is actually serving traffic. That's a server-health question, not a DNS-record question, and it needs its own monitoring layered on top rather than being something DNS was ever built to answer.