DNS weights distribute answers, not individual requests. Resolver caching and persistent connections can make traffic shares differ from configured weights.
Coarse on purpose
Resolvers cache and represent many users. Use weights for region splits and canaries, not per-request fairness. Inside a pool, keep an application load balancer.
The delivery model
DNS load balancing
- 01ChoosePolicy selects an eligible weighted answer.
- 02ReuseA resolver shares its cached answer with clients.
- 03ObserveActual traffic reflects caching and client behavior.
Start conservative
Publish the new pool at a low weight with suitable health checks. Observe actual backend traffic and error rates before increasing the weight. Existing cached answers can delay the shift.
Subnet splits
When you know resolver space, subnet load balancing is finer than continent maps. Use it sparingly; it is easy to overfit.
CDN in the mix
DNS can steer to more than one CDN or origin hostname. Cloud CDN origin groups handle delivery-side failover after the client has arrived.
Validate before production
Begin with a small canary weight and monitor requests and errors at each backend. Do not interpret a 10% weight as a guarantee of exactly 10% of sessions. Verify health exclusions and define a rollback before expanding the canary.
- Record the configuration and expected result before changing traffic.
- Keep evidence of the test and a working rollback for the previous behavior.
