You change a DNS record, refresh the dashboard, and wait for traffic to move. Ten minutes later, one backend is still hot, the new pool is barely used, and someone in Slack starts asking whether the change even applied. That moment is where the common understanding first learns that DNS load balancing is not a request-by-request traffic cop, it is a name resolution decision with caching in the middle of the road.
The surprise is usually not the DNS change itself. The surprise is that clients, recursive resolvers, and operating system caches can keep using the old answer until TTL expiry, so the traffic shift you expected can arrive late, unevenly, or only for some users. If your mental model still sounds like a classic load balancer, this is the place to reset it.
Table of Contents
- The Day the DNS Change Did Nothing
- What DNS Load Balancing Does
- Common DNS Load Balancing Algorithms
- TTL, Caching, and the Traffic Lag
- Health Checks and Failover Patterns
- When DNS Load Balancing Is the Wrong Tool
- Monitoring and Incident Response for DNS Routing
- A Pre-Production Checklist for DNS Load Balancing
The Day the DNS Change Did Nothing
The on-call engineer does everything by the book. A regional pool looks unhealthy, so they update the hostname to point at a newer set of servers. The authoritative zone is correct, the change has been saved, and the team is watching the graphs. Yet the old region keeps taking most of the traffic.
That is the point where confusion usually starts. People check the authoritative records, then the application layer, then the firewall, and then they start wondering whether the wrong service was updated. The answer is often simpler and more annoying, the change was real, but the world outside the authoritative server had not caught up yet.
A recursive resolver can keep serving the old answer until the TTL expires. A client's own resolver cache can do the same thing. Even if the new records are perfect, the old answer can stay alive in enough places that the traffic shift looks broken when it is just delayed.
Practical rule: if a DNS change seems to do nothing, assume caching before you assume failure.
That is the core mental shift with DNS load balancing. You are not steering each request as it arrives. You are publishing an answer and waiting for the ecosystem around DNS to pick it up at its own pace. That is why changes can feel clean in the control plane and messy in production.
For a quick refresher on DNS troubleshooting itself, the walkthrough at How to fix DNS issues is a useful companion when you need to separate record mistakes from caching behavior.
What DNS Load Balancing Does
DNS load balancing decides which IP address a client gets when it asks for a hostname. It does not forward packets the way a layer 4 device does, and it does not inspect application content the way a layer 7 proxy does. Instead, DNS answers the naming question and lets the client connect to one of the returned addresses. That is why the setup depends so heavily on resolver caching and TTL behavior (source).
How the answer gets chosen
An authoritative DNS server can return different addresses for the same name. Those answers may be rotated, weighted, or selected by geography or proximity, but the key point is that the decision happens at resolution time. Before any TCP connection opens, the first hop of traffic has already been influenced, which is why DNS is a common way to spread load across multiple backends (source).
That design is simple, but production behavior is messier than many engineers expect. A client may not ask again right away after the first lookup. A recursive resolver may answer from cache for many clients. The operating system can also keep the older response for a while, so the original choice keeps echoing through the stack. A record change can be correct in the authoritative zone and still look uneven for some time after the update.
Why it is not a packet forwarder
A layer 4 balancer sees connections as they arrive. DNS does not. It changes the address a client receives, then steps back and lets the rest of the network do the work. That is why DNS is best understood as distribution by naming, not distribution by forwarding.
For IPv6-heavy environments, the same logic still applies, only the record family changes. The lookup behavior is still the lever, not the packet path, which is why IPv6 DNS server behavior pairs well with this topic when teams are untangling address selection.
DNS can influence where traffic starts, but it cannot force every request to land where you want it.
That distinction matters in production. If you need strict per-request steering, immediate health-based removal, or session-aware routing, DNS on its own will not give you that control.
Common DNS Load Balancing Algorithms
A DNS answer can do only a few things. It can return one address, rotate through several addresses, or bias the reply toward a region, a network path, or a target with more capacity. The hostname stays the same, but the authoritative server decides which A or AAAA record to hand back first, or which subset to include in the response.
| Algorithm | How it picks an answer | Strengths | Where traffic skews |
|---|---|---|---|
| Round-robin | Cycles through the available addresses in sequence | Simple, easy to reason about, good first step for shared capacity | Resolver caching, retry behavior, and uneven query patterns can concentrate load |
| Weighted rotation | Returns some addresses more often than others | Useful when backends have different capacity or you want gradual shifts | The intended split can drift because caches and retries do not follow the weight exactly |
| Geo or proximity-based routing | Selects an answer based on client location or network proximity | Better user experience for regional services and lower latency | Location databases, resolver placement, and mobile networks can blur the intended region |
Round-robin and weighted rotation
Round-robin is the plainest option. The answer set moves through the available backends in sequence, so each lookup has a clear next target. Weighted rotation adds control when one pool should take more traffic than another, or when a new region needs a gentler ramp instead of an abrupt cutover.
Both methods work at the name resolution step. They shape the first address a client receives before any connection exists. That makes them useful for spreading initial demand, but the choice is still just a selection rule, not a per-request traffic scheduler.
The mechanics are easy to misread in production. A backend can receive more or less traffic than the rotation pattern suggests because the authoritative answer is only one part of the path. Client libraries may reuse what they already have, and different resolvers can ask at very different times, so the same rotation policy can produce uneven results even when the record order looks clean on paper.
Geo and proximity routing
Geo-based routing fits services that care more about user experience than about equal splitting. It steers a lookup toward a nearby region or a preferred network path, which can reduce the distance between the client and the first hop. Proximity-based routing usually aims at the same operational result, a better place for the next connection, not strict fairness across the fleet.
The tradeoff is control. Geo databases, resolver placement, and mobile networks all affect what location the system thinks a client is using. A user in one region may resolve through a recursive resolver in another, and that resolver's viewpoint can influence which answer gets returned. For teams that want to compare placement choices against application latency, the guidance in latency and response behavior helps frame what the lookup is optimizing.
The answer that looks balanced in DNS logs is not always balanced in backend logs.
Health checks belong next to these algorithms. They remove dead targets from the answer set and keep the routing choice tied to systems that can still serve traffic. From there, teams can decide whether proximity rules, weight changes, or resource-aware routing fit the service better than a simple rotation.
TTL, Caching, and the Traffic Lag
DNS is often treated like a routing layer, but that view can be misleading in production. What usually happens is a one-time name resolution decision, then a chain of caches keeps that answer in place until it ages out. ISC draws a sharper line here and notes that distributing queries across DNS servers is often closer to load sharing than true load balancing (source). That is why a DNS change can look correct in the zone file and still leave one backend carrying more traffic than expected.
Recursive resolvers do not refresh together. A client may ask a resolver that still trusts an older answer, while another client reaches a resolver that has already picked up the new one. Operating system caches and client-side caches add another layer, so the rollout is never perfectly synchronized.
Short TTLs are often set around 30 to 60 second TTLs when teams want faster failover, but the tradeoff is straightforward. Lower values make resolvers ask more often, which increases DNS load. Higher values reduce that pressure, but they leave stale answers in circulation for longer when traffic needs to move away from a bad region (source).
For a practical way to think about the delay between a DNS change and what users experience, latency of response is a useful reference, especially if your team tends to treat “record updated” as the same thing as “traffic moved.”
What that means in practice
A low TTL buys faster propagation, but it also increases query volume. A high TTL cuts lookup churn, but it slows the shift away from a broken target. Neither choice removes caching surprises. It only changes how long those surprises last.
A DNS answer is not a live steering decision for every request. It is the answer that a resolver happened to cache, and that answer can continue guiding users until the cache expires.
Operational takeaway: DNS routing is time-lagged by design, so plan around cache expiry, not around the moment you click save.
That lag is why DNS load balancing behaves more like load sharing than a hard switch. The system can converge, but the path to convergence is shaped by caches you do not control.
Health Checks and Failover Patterns
Health checks are what keep DNS-based routing from blindly serving dead endpoints. The DNS layer can only remove an unhealthy address from future answers if something upstream tells it that the address is no longer fit for service. Without that feedback, the resolver keeps seeing a valid record long after the backend should have been retired.
Three ways teams usually wire failover
- Active probing: The control plane checks whether each backend still responds as expected, then stops returning failed endpoints. This is the cleanest fit for straightforward service pools because it mirrors actual availability.
- Weighted failover: Traffic is reduced gradually toward a region or pool before it is removed completely. Teams use this when they want to drain a site without forcing every resolver to flip at once.
- Geo-based failover: Requests from one region can be shifted toward a nearby healthy region when the preferred site degrades. This is most useful when the user base is spread across multiple geographies and the routing policy already understands location.
Getting TTL and probing to agree
The failure detector and the TTL need to tell the same story. If probes are too slow, the DNS record can keep advertising a failing backend for longer than the team expects. If the TTL is too long, clients may continue using the stale answer even after the health system has done its job.
That is why incident-safe designs treat health checks and TTLs as one decision, not two. A fast probe with a long TTL still leaves stale clients in the wild. A short TTL with weak health checks still routes traffic toward broken systems.
There is also a human side to this. The runbook should make it obvious who owns the routing policy, who flips the failover state, and who confirms that the answer set has changed. If those responsibilities are vague, the incident slows down even when the mechanism is technically sound.
A good DNS failover pattern feels boring during a calm day and obvious during a bad one.
That is the standard worth aiming for. If the operational steps feel improvised, the routing layer will feel unreliable when the next region goes quiet.
When DNS Load Balancing Is the Wrong Tool
A DNS change can look correct on paper and still fail to move much traffic in practice. That usually happens when the core problem is not name resolution, but immediate control over where each connection goes. DNS answers one question, which hostname should this client try next, and then recursive resolvers, caches, and client behavior take over.
Use DNS load balancing when a delayed transition is acceptable. It works well for planned cutovers, regional maintenance, and simple multi-region exposure where you can live with old answers fading out over time. It is a poor fit when you need exact per-request steering, because DNS does not make a fresh decision for every request the way an in-path balancer does.
Good fits
- Planned cutovers: DNS works well when a team can shift traffic gradually and wait for cached answers to age out.
- Regional maintenance: You can lower traffic to one site before taking it offline, as long as the handoff does not need to be immediate.
- Simple multi-region exposure: A hostname that points to several healthy pools is a natural fit for DNS-based steering.
Bad fits
- Hot-standby incident response: If a region is failing now, waiting on cache expiry gives you the wrong kind of control.
- Strict request affinity: If the application needs precise per-request routing, DNS cannot guarantee it.
- Rapid rollback under load: The same caching behavior that makes a rollout calm also makes rollback slow and uneven.
DNS makes a one-time name resolution decision, then the resolvers keep that answer alive for their own clients. After a record change, traffic can skew away from your intended split for a while, especially when different resolvers refresh at different times and client address selection is involved. A routing plan can look clean in the zone file and still send an uneven share of users to the old pool.
The practical rule is simple. If the next connection must be controlled immediately, use an in-path load balancer or another routing layer. If a slower transition is acceptable, DNS is the right tool.
DNS is specific, not weak. The mistake is expecting it to act like a live traffic director, when in production it is really handing out answers that other systems may reuse long after you changed them.
Monitoring and Incident Response for DNS Routing
DNS incidents are hard to debug because the signal is spread across layers. The authoritative DNS answer may be correct, the resolver cache may still be stale, and the application error rate may be rising for only part of the user base. If you only watch backend health, you miss the routing layer. If you only watch DNS, you miss the user impact.
The most useful signals are the ones that tell you how the answer is behaving in the wild. Query volume by region shows where requests are landing. Answer distribution tells you whether the intended pool is showing up. External probes help you see what TTL and cache behavior look like from outside your network.
You also want those signals next to backend logs, not in separate tabs that nobody can correlate under pressure. A centralized log platform gives the on-call engineer one place to line up the DNS change, the resolver behavior, and the resulting application errors. Fluxtail is built around that sort of incident view, with protocol-first ingest, named streams, live tail, and built-in analysis that keeps noisy systems separated while the event is unfolding.
During a routing incident, the question is not only “did DNS change?” It is “which clients still see the old answer, and what did that do to the app?”
That is the query to answer in the first few minutes. Once you know which traffic is still pinned to the wrong place, the rest of the diagnosis gets easier. If your team uses MCP-compatible AI clients, Fluxtail's chat-based queries can also help surface recent error spikes without screenshot hunting or dashboard hopping.
A Pre-Production Checklist for DNS Load Balancing
Before you put DNS load balancing in front of a production service, make the decisions that will matter during an incident. TTL should be chosen on purpose, not inherited from a template, and the team should understand the tradeoff between faster recovery and higher DNS load. The 30 to 60 second range is a practical starting point for fast failover, but it only works if the rest of the system is prepared for cache lag (source).
A clean checklist usually includes these items:
- Choose the routing pattern: round-robin, weighted, or geo-based, and make sure the choice matches the service, not just the platform default.
- Define the health check rule: decide what failure looks like, who owns the probe, and how quickly an unhealthy endpoint is removed.
- Set the TTL intentionally: align cache duration with the acceptable delay in cutover or rollback.
- Write the failover runbook: identify the person who verifies the answer set and the person who validates backend impact.
- Connect observability early: confirm that DNS answers, probe results, and application logs can be reviewed together.
The most important reminder is simple. DNS load balancing is a name-resolution decision, not a packet-forwarding balancer. If you cannot prove the routing behavior from logs and probes, you do not really know how the traffic is moving.
If you want a cleaner way to watch DNS changes, backend errors, and resolver behavior in one place, try Fluxtail. It's built for exactly the kind of incident work where DNS routing surprises show up first in logs, not in theory.