DNS Load Balancing: Algorithms, Failover, and Operations

DNS load balancing distributes new connections by changing which address records or targets an authoritative DNS service returns for a hostname. It can rotate records, apply weights, choose a location-aware answer, or exclude targets according to health policy. It does not forward each request like a layer 4 or layer 7 load balancer, so resolver caches and client connection behavior strongly influence the result.

That distinction explains most surprises. A correct control-plane change does not immediately move every user. Existing DNS answers can remain cached, applications can reuse open connections, and some recursive resolvers can serve expired data during an authoritative outage. DNS is therefore a useful coarse steering layer, especially across regions, but it is not a precise per-request scheduler.

What DNS load balancing actually controls

A normal lookup passes from an application or operating-system stub resolver to a recursive resolver. If the recursive resolver has no usable cached answer, it follows the delegation to the authoritative DNS service. A routing policy at that authoritative service decides which record or record set to return. The client then opens a connection to one of the addresses it received.

The policy acts at answer time. After the answer is cached, the authoritative service does not control the requests that use it. One recursive answer may serve many clients, while one client may reuse an address for several connections. DNS is therefore less exact than a proxy that sees every request.

DNS-only routing versus a proxy

Keep these architectures separate:

DNS-only steering returns an origin or load-balancer address. The client connects directly to that address, and cached answers can continue to send traffic there until they expire or are otherwise replaced.
Layer 4 forwarding accepts a transport connection and chooses a backend. It can make a new decision for each connection.
Layer 7 proxying accepts an application request, such as HTTP, and can route by host, path, header, cookie, or other application context.
Hybrid managed load balancing uses DNS to reach a provider edge, then proxies connections or requests through that edge. Health and failover behavior can differ from the same provider's DNS-only mode. Cloudflare, for example, documents distinct DNS-only, layer 4, and layer 7 proxy modes rather than treating them as equivalent (Cloudflare proxy modes).

DNS-only routing fits coarse regional distribution and origin selection. A proxy fits per-request decisions or application-aware routing. Some systems combine both: DNS selects a regional proxy, then the proxy selects an application instance.

Anycast and DNSSEC solve different problems

Anycast advertises the same service address from multiple locations and lets the routing system choose a path to an instance. It provides routing reachability to a stable IP, not a policy that changes the DNS answer for each user. The operational behavior and failure domain are different from DNS answer steering (RFC 4786). A service can use both Anycast and DNS load balancing.

DNSSEC also has a narrower job. It lets validating resolvers authenticate the origin and integrity of DNS data. It does not encrypt DNS, test application health, balance traffic, or guarantee that an authenticated endpoint is working (RFC 4033). Treat signing, routing, health, and transport confidentiality as separate controls.

DNS load-balancing algorithms and policies

The names vary across providers, but most policies fit a few operational patterns. Google Cloud DNS, for example, documents weighted, geolocation, and failover policies. The right choice depends on whether the goal is capacity distribution, a controlled rollout, regional placement, or disaster recovery.

Multi-value and round-robin answers

A multi-value answer returns several A or AAAA records for one hostname. A basic round-robin service changes record order or rotates the selected subset across queries. This is easy to deploy and avoids a single origin address, but it does not prove equal load.

Clients can try addresses in their own order, race address families, retry another target, or reuse one successful connection. A recursive resolver can also serve one cached answer to many clients. Round-robin therefore provides distribution, not fairness.

Use it when every returned target can safely receive traffic and modest skew is acceptable. A dead address can cause delay or failure until health policy removes it or another layer retries safely.

Weighted routing

Weighted routing biases DNS selection toward some records. It is useful for unequal capacity, regional preference, and staged migrations. In Amazon Route 53, for example, a record's weight is evaluated relative to the total weights among records with the same name and type (Route 53 weighted records).

A configured 90:10 weight is not a promise that exactly 90% and 10% of requests, users, or bytes will reach the two targets. It describes selection at the provider's DNS decision boundary. Recursive caching, unequal resolver populations, multiple returned addresses, client retries, long-lived connections, and application traffic patterns can all move observed backend traffic away from the configured ratio.

Measure canary requests, errors, latency, and resource use by target and release. Increase a weight only after DNS answers and application outcomes are acceptable. A tiny weight is not sufficient protection against an unexpectedly large share.

Latency and proximity routing

Latency-based or proximity routing chooses a region that the provider estimates will offer a better network path. The estimate may come from provider measurements and topology rather than a fresh latency test for each lookup. It can improve placement, but it is not a guarantee of the fastest application response: congestion, the user's access network, endpoint load, and dependencies still matter.

Keep a fallback for clients that do not fit the expected geography. Validate corporate resolvers, mobile networks, VPNs, and public resolvers. A provider's map is a model; endpoint outcomes are the proof.

Geolocation routing and EDNS Client Subnet

Geolocation routing chooses an answer from an inferred location. Without extra client-location information, an authoritative service commonly sees the recursive resolver, which may be far from the user. EDNS Client Subnet, or ECS, allows a resolver to include a truncated portion of the originating client's network so an authoritative service can make a more specific decision. ECS is optional, affects cache partitioning, and exposes additional network-location information. RFC 7871 explicitly documents the resulting privacy concerns and recommends address truncation (RFC 7871).

Do not interpret a geo rule as exact user location. Confirm whether the provider uses resolver location, ECS, or another signal. Provide a default for unknown locations. Test privacy, cache efficiency, and regional correctness together.

Active-passive failover

Active-passive routing normally returns the primary while its health condition passes, then returns a secondary after the provider marks the primary unhealthy. This is useful for disaster recovery, but the switch is not instantaneous. It includes the provider's health-detection time and policy-evaluation time, then the lifetime of earlier answers in recursive and client caches. Open connections and application retries add more delay.

Provider behavior when all targets are unhealthy is critical. Route 53 documents that it treats all records as healthy for selection when none is healthy; its active-passive example returns the primary when both primary and secondary health checks are unhealthy (Route 53 health selection). Google Cloud DNS also documents mode-specific behavior: when all policy buckets are unhealthy, it behaves as if all endpoints are healthy, while geofencing and failover rules affect which answers remain eligible (Google Cloud DNS routing policies). Test the exact provider, policy, and all-unhealthy state rather than assuming fail-closed, fail-open, or no answer.

Caching determines how quickly a change appears

DNS caching is part of the protocol's scalability, not an error to work around. Resource records carry a TTL that limits how long a normal cached answer may be reused. RFC 2181 clarifies that this is a maximum, not a mandatory cache lifetime: a resolver can retain the record for less time (RFC 2181).

The configured TTL is an upper bound for the cached record's normal lifetime, not a complete failover timer. End-to-end movement can also include:

time for the health checker to detect and confirm a failure;
time for the authoritative policy to change its answer;
the remaining TTL on answers already held by recursive, operating-system, or application caches;
application-specific DNS refresh behavior;
reuse of existing TCP, TLS, HTTP, or database connections;
retries that continue using a previously selected address;
resolver behavior that deliberately serves stale data during authoritative failures.

RFC 8767 permits recursive resolvers to use expired cached data when authoritative servers cannot be reached, improving availability at the cost of keeping an old answer longer. This is one reason a DNS cutover cannot promise that every conforming client stops using an old target exactly at TTL expiry.

Negative answers and lookup failures are cached too

Caching is not limited to successful A and AAAA answers. NXDOMAIN and NODATA responses can be negatively cached according to DNS rules, so creating a previously missing name may not become visible immediately to resolvers that cached its absence (RFC 2308).

Modern resolver requirements also include bounded caching for resolution failures such as certain SERVFAIL conditions. RFC 9520 requires resolvers to cache resolution failures for at least one second and no longer than five minutes, with implementation details varying by resolver (RFC 9520). A short authoritative outage or DNSSEC validation error may therefore have effects that persist briefly after the underlying fault is corrected.

Monitor response codes, timeouts, and returned addresses. A dashboard that only counts successful answers can miss the cached negative or failure state that users are actually encountering.

Choose TTL from an operating requirement

There is no universal correct 30- or 60-second TTL. A lower TTL can reduce the normal lifetime of a cached answer, but it increases authoritative query volume and dependence on the authoritative service. It does not eliminate client caching, health-check delay, stale serving, connection reuse, or lookup-failure caching.

Choose the TTL by balancing:

the longest stale-answer period the application can tolerate;
the authoritative service's capacity, query cost, and availability;
how frequently planned changes occur;
provider minimums and health-policy behavior;
observed recursive and client behavior in the important networks;
whether another layer can stop unsafe traffic after DNS returns an old address.

For a planned migration, lowering TTL helps only if old records have time to expire. Restore the steady-state TTL after the change. A permanently tiny TTL does not replace a tested proxy, drain strategy, or connection-lifetime policy.

Design health checks around the user-serving path

Managed DNS health checks typically run on a schedule independently of client DNS queries. Cloudflare, for example, documents monitors that send requests at configured intervals and remove unhealthy origins from pools according to configured thresholds (Cloudflare monitors). Route 53 likewise evaluates endpoint health periodically rather than performing an application probe for each DNS request.

A good check is safe, bounded, and representative of the capability required to serve traffic. A TCP connect can show that a socket accepts connections but not that the application can complete useful work. A deep check that mutates data or exercises every dependency can create side effects and amplify an outage. Prefer a read-only endpoint that verifies the minimum critical dependencies, and monitor deeper dependencies separately.

Document these properties for each health policy:

protocol, hostname, path, port, expected status or body, and TLS hostname;
source networks that must be allowed through the firewall;
interval, timeout, failure threshold, recovery threshold, and probing regions;
which record or pool the check controls;
behavior when the health checker itself loses connectivity;
behavior when one target, one region, or every target fails;
who may change the check and where audit events are retained.

Avoid an endpoint that returns success while the application behind it is unavailable, or a check that can exhaust the dependency it protects. The check should distinguish a target ready for new traffic from one with only a running process.

Treat IPv4 and IPv6 as separate paths

If a hostname publishes both A and AAAA records, clients can evaluate IPv6 and IPv4 paths independently. Happy Eyeballs algorithms attempt connections across address families to reduce user-visible delay when one family is impaired (RFC 8305). That client behavior can hide a broken family from aggregate success metrics while adding delay or shifting load.

Verify that health checks cover the same families the authoritative service publishes. Do not assume an IPv4 success proves the IPv6 endpoint works, or the reverse. Cloudflare's health-monitor documentation, for example, states that monitors use IPv4 by default and use IPv6 when the origin has no A record rather than probing both families automatically. Provider details differ, so confirm the active configuration.

Track answers and endpoint outcomes by address family. During a change, query both A and AAAA and test the actual application path over each supported family. For record-level checks, see how to diagnose DNS issues.

Plan and verify a safe DNS change

Treat DNS changes as production changes even though the configuration may be only a few records. Define the intended routing result, fallback, and evidence before editing the zone.

Before the change

Record the current record sets, TTLs, routing policies, health state, delegation, and DNSSEC status.
Confirm that every candidate target accepts the correct hostname and TLS Server Name Indication, serves the expected application version, and is reachable from intended networks.
Verify that health checks are application-relevant, read-only, and allowed through network policy.
Decide how to recover if the primary target, secondary target, health checker, or authoritative service fails.
If a shorter TTL is justified, apply it far enough in advance for previously cached records with the old TTL to age out.
Define success and stop conditions using endpoint traffic, error, latency, and capacity signals—not DNS answers alone.

Observe authoritative and recursive views

The following are read-only command templates. example.test, example.net, and the shown names are reserved examples; replace them with your hostname and verified DNS servers:

dig @ns1.example.net app.example.test A +noall +answer +authority
dig @ns1.example.net app.example.test AAAA +noall +answer +authority

dig @resolver.example.net app.example.test A +noall +answer
dig @resolver.example.net app.example.test AAAA +noall +answer

dig @resolver.example.net app.example.test A +dnssec +noall +answer +comments

An authoritative query shows what that authoritative server currently publishes. A recursive query shows that resolver's present view, which may be cached. The ad flag from a trusted validating resolver can indicate authenticated data; merely seeing an RRSIG in an authoritative response does not prove that the local path validated it.

One dig result never proves global propagation. Query every authoritative server, then relevant recursive resolvers and regions. Compare TTLs, answers, response codes, DNSSEC validation, and A/AAAA behavior. Verify delegation outside the managed zone as well as in the provider console. How to fix DNS issues covers broader checks.

Change gradually and verify outcomes

For weighted routing, start with a canary weight that is safe even if caching produces more traffic than the nominal ratio. Observe endpoint results by target, region, address family, and release. Increase the weight in controlled steps only after the service remains healthy.

For failover, deliberately exercise the documented failure modes in a controlled environment: one unhealthy target, all targets unhealthy, lost health-check reachability, and recovery. Confirm both the authoritative response and actual connections. Test whether existing clients keep using cached answers or open connections.

Do not remove the old target immediately. Stop new selection, wait for previous TTLs and relevant connections, and verify traffic has drained. Keep a recovery path until DNS and endpoint evidence show completion, then restore the normal TTL.

Monitor the control plane and the user outcome

DNS monitoring needs several viewpoints because no single signal proves availability.

Monitor the control plane for record, policy, health-check, DNSSEC, credential, and delegation changes. Retain provider audit events and alert on unexpected modifications. Where the authoritative provider exposes them, watch query volume, latency, response codes, and failures by record type and region. These are provider-specific capabilities, not universal DNS signals.

Use external probes from relevant networks to resolve the hostname and attempt a safe application request. The probe should record the resolver, returned addresses, response code, timing, and selected endpoint without storing sensitive payloads. Test A and AAAA separately as well as the normal client behavior that may race both.

At each endpoint, monitor requests, errors, latency, saturation, release, region, and address family. This reveals the real weighted split and geo placement. Connect DNS changes to application outcomes, but keep symptom, routing decision, and root cause distinct.

DNS query and audit data can expose hostnames, client-network information, infrastructure layout, and change history. Collect only what the investigation needs, restrict access, protect transport and storage, and set retention by purpose. If ECS is present, treat its client prefix as potentially sensitive network-location data.

Write alerts for actionable conditions. Examples include a health policy with no healthy target, sustained DNS error responses, a target receiving traffic after it should have drained, or a regional endpoint failing while DNS still selects it. Apply the same principles as the alerting best practices guide: give each alert an owner, evidence window, runbook, and tested route rather than paging on every DNS fluctuation.

When DNS load balancing is the right layer

DNS fits regional steering, active-passive recovery, or gradual address migration. It works best when endpoints have stable addresses and traffic skew is acceptable.

DNS alone is a weak fit when the requirement is strict per-request ratios, immediate target removal, path- or header-based routing, session affinity, centralized TLS policy, or protection that depends on inspecting application traffic. Add a layer 4 or layer 7 proxy when those are actual requirements. Do not force DNS to imitate a component that operates later in the connection path.

A resilient design states which answer is published, how long it may be cached, how clients select addresses, what a proxy does, how retries behave, and how an origin drains. Simplicity comes from clear boundaries.

Use centralized logs as supporting evidence

DNS answers alone do not show whether an application served users successfully. Provider audit events, health-check events, and endpoint application logs can help reconstruct a change when those sources already emit records through a supported collector or receiver. Normalize stable fields such as event time, provider, zone, record name, record type, target, region, health state, release, and request ID without discarding the original event.

Fluxtail is a paid Starter/Pro, logs-focused service. It can search and filter received logs, show recent events in Live Tail, and evaluate log alerts when the relevant source data has been delivered and mapped. It does not run DNS health checks, query authoritative servers, measure resolver propagation, collect DNS metrics automatically, or perform DNS load balancing. Validate the collector path and field mapping before relying on a DNS-related search or alert.

Keep the operating evidence layered: DNS probes establish resolution behavior, endpoint monitoring establishes application outcome, and retained logs explain specific events. Centralization helps investigation, but it does not turn any one of those sources into a complete view of DNS behavior. For the broader collection and retention model, see the log management guide.

DNS load-balancing operations checklist

Before putting a routing policy into service, verify all of the following:

The architecture identifies DNS-only, layer 4, layer 7, hybrid proxy, and Anycast responsibilities correctly.
Every A and AAAA target is independently reachable and can serve the intended hostname and TLS identity.
The algorithm matches the goal: distribution, staged rollout, proximity, geography, or failover.
The team understands that weights affect DNS selection rather than guaranteeing request percentages.
Geo behavior accounts for recursive-resolver location, optional ECS, default routes, privacy, and cache fragmentation.
TTL was chosen from stale-answer tolerance and measured resolver behavior, not copied as a universal value.
Negative answers, resolution failures, stale serving, connection reuse, and retries are included in the recovery model.
Health checks are read-only, dependency-aware, allowed through network controls, and tested from their actual probe regions.
All-unhealthy and health-check-network-failure behavior is known for the exact provider and proxy mode.
IPv4 and IPv6 answers, checks, connections, and endpoint outcomes are tested separately.
DNSSEC validation, delegation, and authoritative consistency are checked without confusing authentication with availability.
A planned change uses gradual traffic movement, explicit stop conditions, a drain period, and a verified recovery path.
Monitoring covers provider changes, DNS responses, external resolution, endpoint outcomes, and user impact.
DNS and application logs are minimized, access-controlled, and retained only as long as their purpose requires.

DNS load balancing works best when its limits are part of the design. Model the authoritative decision, caches, client behavior, health policy, and endpoint outcome separately. Then test how they interact before an outage makes those boundaries visible for the first time.