DNS can do more than map a name to a single address. By returning different answers, or the same answers in a different order, it can spread traffic across several servers and even steer users to the server nearest them. The three building blocks you will meet are plain round-robin, weighted records, and geolocation-based answers, often called GeoDNS. Each one solves a different problem, and each one is limited by the same stubborn fact: resolvers cache answers and reuse them for many clients. This guide explains what each method can and cannot guarantee, and why a location-aware propagation check legitimately shows varied results.
Round-robin: the same records in rotating order
Round-robin is the simplest form of DNS load spreading. You publish more than one A or AAAA record for the same name, and the authoritative server rotates the order it lists them on each query. Clients generally try the first address they receive, so rotating the order spreads connections across the addresses over time.
$ dig +short www.example.com A
203.0.113.10
203.0.113.11
203.0.113.12
; a moment later, the order rotates
$ dig +short www.example.com A
203.0.113.11
203.0.113.12
203.0.113.10Round-robin is easy and costs nothing extra, but it is blunt. It knows nothing about server load, and critically it knows nothing about server health. If one of those three addresses is down, roughly a third of clients still receive it first and may hang until they time out and retry the next one. Round-robin distributes names, not load, and it is not failover.
Weighted records: biasing the distribution
Weighted DNS lets you assign a share to each answer so that traffic is split unevenly on purpose. Instead of an even rotation, the authoritative provider returns a given address for a configured percentage of queries. This is useful for sending more traffic to a larger server, for canary releases where a new backend gets a small slice first, or for gradually draining a server before maintenance.
| Method | What it varies | Health aware | Typical use |
|---|---|---|---|
| Round-robin | Order of a fixed set of records | No | Simple, even spreading |
| Weighted | Probability each record is returned | Only if the provider adds checks | Uneven splits, canaries, draining |
| GeoDNS | Which record is returned, by location | Only if the provider adds checks | Sending users to the nearest region |
Weighting is a feature of a managed DNS platform rather than a record type you write by hand. The zone file concept is still just multiple address records; the weighting lives in the provider's answer logic. Because the choice is made per query at the authoritative server, the split you configure is only approximate once caching enters the picture, as we will see below.
GeoDNS: answers that depend on where the question came from
GeoDNS returns different records based on the geographic location of whoever asked. A visitor in Europe might receive the IP of a Frankfurt server while a visitor in North America receives a Virginia server, both asking for the same hostname. The goal is lower latency: send each user to the closest healthy region.
The hard part is that the authoritative server does not see the end user. It sees the recursive resolver that forwarded the query. If a user in Spain uses a resolver hosted in Germany, a naive GeoDNS setup will place them in Germany. The fix is EDNS Client Subnet (ECS), defined in RFC 7871, which lets the resolver pass along a truncated portion of the client's IP so the authoritative server can locate the real user rather than the resolver.
; Conceptually, the same name resolves differently by region
www.example.com. (asked from Europe) -> 203.0.113.50 ; Frankfurt
www.example.com. (asked from North America) -> 198.51.100.50 ; Virginia
; With ECS, the resolver forwards the client's subnet:
; OPT PSEUDOSECTION showing edns-client-subnet 198.51.100.0/24Why caching limits all three
Every one of these methods makes a decision at query time, but resolvers cache the answer for the length of its TTL and hand that same cached answer to every client behind them until it expires. This has concrete consequences:
- Round-robin rotation is flattened by caching. A busy resolver may cache one order and serve it to thousands of clients, so the spread you see from one vantage point is not the spread a global audience experiences.
- Weighted splits are statistical, not exact. A 90/10 weight applied across millions of queries trends toward 90/10, but a single resolver caching one answer can skew its own users heavily toward whichever record it happened to cache.
- GeoDNS is only as accurate as the location signal. Without ECS, accuracy depends on resolver placement, and even with ECS the cached answer is scoped per subnet.
The single most effective lever over all of this is the TTL. A low TTL makes rotation, weighting, and geo decisions refresh often, at the cost of more queries and slightly slower first connections. A high TTL improves cache hit rates but freezes clients onto whatever answer they received. For traffic steering you want a short TTL, commonly in the range of 30 to 300 seconds, so changes take effect quickly.
Choosing the right tool
Match the method to the problem. If you simply have two equal web servers and want casual spreading, round-robin is fine and free. If you need to bias traffic, test a new backend on a small slice, or drain a node, reach for weighted records on a managed provider. If latency across regions is your concern and you run servers in several places, GeoDNS with ECS and health checks is the real answer. Many production setups combine them: GeoDNS picks the nearest region, then round-robin or weighting spreads load among the servers within that region.
Remember that none of these is a substitute for true failover. DNS steering reacts on the order of its TTL, not instantly, because old answers linger in caches. For fast recovery you pair short TTLs with provider health checks that pull an unhealthy address out of the rotation, or you put a load balancer behind a single stable address.
Verify what your routing actually returns
Because these methods deliberately return different answers in different places, the only way to know what your audience really sees is to look from many locations at once. Run your hostname through the Valla DNS propagation checker to see the addresses returned across regions, confirm that a weighted or geo setup is steering the way you intended, and watch that a TTL change has taken hold everywhere. Pair this with our guides on DNS TTL strategy and on why a checker shows different IPs by location to interpret the results with confidence.