DNS as a Traffic-Steering Tool

Why this matters: 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.

Key takeaway

Because DNS returns a list of addresses and you control which list, it doubles as a global traffic director. It can send users to the nearest region, shift load between data centers, and route around failures — all before a single packet reaches your infrastructure.

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:

Policy	How it decides	Use it for
Round robin	Rotates the order of returned addresses	Crude, free distribution across equivalent servers
Weighted	Returns addresses in a configured ratio	Canary releases, gradual migrations, uneven capacity
Geolocation	Based on the resolver's inferred location	Data residency, region-specific content
Latency-based	Measured network latency to each region	Sending users to the genuinely fastest region
Failover	Health checks; returns the standby when primary fails	Disaster recovery, active-passive setups
Multivalue with health checks	Returns several healthy addresses	Client-side retry across a live set

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.

Why DNS alone is not enough

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

Limitation	Cause	Consequence
Slow to react	TTL plus non-compliant resolvers	Failover takes minutes with an unbounded tail
Uneven distribution	One resolver caches one answer for thousands of users	Load skews badly; round robin is not evenly balanced in practice
No visibility into server load	DNS knows health at best, never utilization	Can send traffic to a healthy-but-saturated server
Resolver location is not user location	Geolocation infers from the resolver, not the client	A user on a distant public resolver gets routed wrong
Clients ignore TTL	Long-lived processes resolve once at startup	Some traffic never moves until a restart

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.

Key takeaway

DNS is your coarse, global, slow routing layer. Use it to pick a region, run a canary, or shift traffic over minutes. Never use it for fast failover or precise balancing — those belong to a tier that sees individual requests.

Interview signal by level

Level	What a strong answer sounds like
L4	"DNS round robin can spread traffic across servers."
L5	Uses it for geography: "latency-based DNS routing sends users to their nearest region, then a regional load balancer picks the instance."
Staff+	Bounds what it can do: "DNS is my global tier — region selection, canaries, weighted migration. It can't be my failover mechanism because TTL and non-compliant resolvers make convergence minutes with a long tail, and round robin skews since one resolver caches one answer for thousands of users. Fast failover goes to anycast or the load balancer."

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