DNS as a Traffic-Steering Tool

In one line: DNS is not just a lookup you depend on — it is a control point you can steer with. It is the only load balancer that runs before the client has connected to anything, which makes it the natural place to do global routing and the wrong place to do anything fast.

Round robin: the simplest version

Run nslookup on a large site twice and the IP addresses may come back in a different order. That is DNS round robin, a technique used to load balance traffic across multiple servers.

Clients typically try the first address, so rotating the order distributes connections. It is free, requires no additional infrastructure, and is genuinely used at scale.

The full set of routing policies

Managed DNS providers extend this considerably:

This is global server load balancing (GSLB) — the tier above the load balancers inside each region. DNS picks the region; a load balancer inside that region picks the server.

Geo-steering has a blind spot: you cannot see the user

Every geographic policy above assumes the authoritative server knows where the user is. It does not. It knows where the resolver is.

The recursive resolver is the only client the authoritative server ever talks to, so its address is the only location signal available. When users pick their own resolver — a public one, a corporate one, a VPN's — that signal stops corresponding to the user at all.

For most of DNS's history this was fine, because resolvers were operated by the user's own ISP and were therefore near the user. Widespread public resolvers broke that assumption, and the accuracy of every geographic routing policy fell with it.

The protocol-level fix is EDNS Client Subnet: the resolver forwards a truncated prefix of the client's address alongside the query, so the authoritative server can steer on roughly where the user is rather than where the resolver is.

That third row is the one worth volunteering, because it is a genuine architectural cost rather than a configuration detail. The answer is no longer the same for everyone, so the shared cache that made DNS cheap becomes a partitioned cache. You are trading the efficiency of caching for the accuracy of steering, and both matter.

Which reinforces the broader point this lesson is making: DNS is a coarse steering tool. It cannot see the user precisely, it cannot react quickly because of TTLs, and it hands out an answer before knowing anything about the request that will follow. Use it to get a client into roughly the right region, then let a real load balancer — which can see the actual connection — make the precise decision.

The job DNS does that nothing else can

Before cataloguing what DNS steering cannot do, it is worth stating the one thing it does that no load balancer can do for itself.

A load balancer distributes traffic across servers. So what distributes traffic across load balancers?

This is the recursion that has to stop somewhere. Every layer of a system can be made redundant by putting a balancer in front of it — until you reach the balancer itself, and there is nowhere left to stand. DNS is where the recursion terminates, because the client does the choosing: it receives several addresses and can move on when one does not answer.

That reframes round robin, which looked like the crudest policy in the list. It is not primarily a load-distribution mechanism — it is client-side load balancing plus entry-point redundancy, and it works precisely because the resolver hands the decision to the client rather than making it.

Two caveats keep it honest. Failover is the client's behaviour, so how fast it happens and whether it happens at all depends on the client library, and the browser's retry is not something you control. And a returned address is only as good as the health checking behind it — a managed provider removing an unhealthy endpoint from the answer is what makes this reliable, rather than the rotation itself.

Why DNS alone is not enough

Everything that makes DNS scalable also makes it a poor fine-grained balancer:

The uneven-distribution trap

DNS round robin is often described as load balancing. It is really request distribution at the resolver level, and the distinction matters.

A single large ISP resolver caches one answer and hands it to every one of its users for the whole TTL. So the traffic split is across resolvers, weighted by how many users each serves — not across users. With a handful of large public resolvers dominating, the resulting distribution can be sharply skewed. Real balancing has to happen at a tier that sees individual requests.

Never make DNS your only failover

The failure mode is specific and common: the primary region dies, health checks notice within seconds, the DNS record updates — and users continue hitting the dead address for minutes because their resolver, OS, or application is still holding the old answer.

DNS failover is a coarse, eventually-consistent mechanism, appropriate for shifting regional traffic over minutes. For anything requiring seconds, the mechanism must be closer to the client: anycast so the network itself reroutes, a load balancer with an address that does not change, or client libraries that retry across the full returned address list.

Making DNS steerable by design

Two design habits that keep this layer useful:

• Point names at stable addresses. CNAME to a load balancer or anycast address so the routing decisions happen at a layer you control in real time, and DNS stays a directory rather than a deployment tool.
• Keep TTLs matched to intent. A record you may need to fail over should carry a short TTL permanently — not one you plan to lower during the incident, which is far too late.

Interview signal by level

Next: watching all of this happen on your own machine.