Round-Robin DNS Explained

Round-robin DNS is load balancing the way a coin flip is a decision-making framework—technically distributing outcomes, but with no intelligence behind the distribution.

How It Works

You create multiple DNS A records pointing the same hostname to different IP addresses:

example.com.  300  IN  A  192.0.2.1
example.com.  300  IN  A  192.0.2.2
example.com.  300  IN  A  192.0.2.3

When a DNS resolver queries for example.com, the authoritative nameserver returns all three addresses, rotating the order with each query. First query: 192.0.2.1, 192.0.2.2, 192.0.2.3. Next query: 192.0.2.2, 192.0.2.3, 192.0.2.1. Since most clients use the first address in the list, traffic spreads across all three servers.

In theory.

The Caching Problem

DNS caching destroys round-robin's distribution logic. When a recursive resolver caches your DNS records, every client using that resolver receives the same ordered list until the TTL expires.

Consider what this means in practice. Comcast's resolver serves millions of users. When it caches your DNS response with 192.0.2.1 first, millions of users all connect to that same server. Meanwhile, your other two servers sit idle. You configured three servers expecting 33% of traffic each. You got one server handling 70% because of when various ISP resolvers happened to query your nameserver.

The problem compounds at multiple layers. Recursive resolvers cache. Operating systems cache. Browsers cache. Some clients ignore TTLs entirely—Java applications, notoriously, can cache DNS indefinitely regardless of what TTL you set. The rotation happening at your authoritative nameserver becomes irrelevant. Caching has already decided where traffic goes.

Shorter TTLs redistribute traffic more frequently but increase DNS query volume and add latency. Longer TTLs reduce DNS load but lock users to the same server for extended periods. Neither solves the fundamental problem: you cannot control how resolvers and clients cache and reorder your records.

No Health Awareness

Round-robin DNS has no idea whether your servers are alive. If one crashes, DNS keeps advertising its IP address. Users connecting to that address see connection timeouts. They wait. They fail. Some clients eventually try the next address in the list, but that retry adds 30 seconds of delay.

You can manually remove the failed server's A record, but then you wait for caches to expire. With a 5-minute TTL, users face failures for 5 minutes. With longer TTLs, longer outages. There's no automatic failover, no health checking, no intelligence.

This makes round-robin DNS unsuitable for anything requiring high availability. Failures aren't handled poorly—they aren't handled at all.

Distribution Is Never Even

Even ignoring caching and failures, round-robin DNS distributes connections, not load. One connection might be a mobile app making 1,000 API calls per minute. Another might be someone loading a single webpage and leaving. Round-robin treats them identically.

Session affinity doesn't exist. If your application requires users to maintain sessions with the same backend server, round-robin DNS offers nothing. Users hit different servers on subsequent requests, breaking session state unless you've implemented distributed session storage.

Geography is ignored. A user in Singapore connects to your server in Virginia when you have a perfectly good server in Tokyo. Round-robin DNS doesn't know or care where anyone is.

When It Works

Despite everything, round-robin DNS has legitimate uses:

Static content mirrors. Every server returns identical content. Occasional failures are acceptable. Round-robin provides free distribution with zero infrastructure.

Development environments. Perfect distribution doesn't matter. Configuration simplicity wins.

Stateless read-only services. Any server can handle any request. No session state. You accept uneven distribution in exchange for zero implementation cost.

The tradeoff is explicit: you're exchanging reliability for simplicity.

Modern Alternatives

Production applications needing real load balancing use purpose-built solutions.

Layer 4 load balancers like HAProxy or NGINX perform health checks, remove failed servers automatically, and distribute based on actual connection counts or server load.

Layer 7 load balancers add application awareness—routing based on URL paths, HTTP headers, or request content. They terminate SSL, manage sessions, and make intelligent routing decisions.

Cloud load balancers (AWS ELB, Google Cloud Load Balancing, Azure Load Balancer) provide managed health checking, automatic scaling, and geographic distribution without maintaining infrastructure.

GeoDNS and Anycast address geographic limitations by routing users to nearby servers. CDNs combine geographic distribution with caching and traffic management.

These solutions cost more than round-robin DNS. But they work.

Sources