Reviewed and substantially updated in August 2026.
Multiple A or AAAA records can spread DNS answers across servers, but they are not automatically a failover system. Load balancing decides how traffic is distributed; failover detects an unhealthy destination and stops sending it new traffic. A resilient design may do both, but the mechanisms and guarantees must be explicit.
DNS load balancing versus failover
| Approach | Primary purpose | Health awareness | Important limitation |
|---|---|---|---|
| Several A/AAAA records (round robin) | Return multiple origin addresses | Usually none in plain DNS | Resolvers and clients may continue using a failed address |
| Health-checked DNS steering | Change DNS answers according to health or policy | Configured probes | Cached answers remain until resolvers/clients refresh them |
| Reverse proxy or load balancer | Choose an origin for each connection/request | Usually active and passive checks | The proxy layer and shared dependencies must also be resilient |
| CDN/edge load balancing | Route at a distributed edge | Provider-specific monitors and steering | Requires correct origin, state, security, and recovery design |
What happens with multiple A records
A DNS name can publish several IPv4 A records or IPv6 AAAA records. Authoritative DNS may rotate their order, and recursive resolvers can cache the set. The operating system or application then decides which address to try and whether to retry another one.
This can distribute some new connections, but it does not guarantee an even split. Recursive resolvers aggregate many users, caches have different lifetimes, clients use different address-selection and retry behavior, and long-lived connections do not consult DNS again until they reconnect.
Most importantly, plain round-robin records do not prove that an origin is healthy. If a server is down or its application is returning errors, its address can remain in the cached answer. Some clients may retry another address; others may show an error or wait for a timeout. Do not describe multiple records alone as seamless automatic failover.
TTL helps, but does not eliminate cache delay
The DNS time to live (TTL) tells caches how long an answer may be reused. A lower TTL can make future changes visible sooner, but it does not revoke answers that are already cached. Resolvers can also impose their own minimums, applications may cache independently, and existing connections are unaffected.
Choose TTL as an operational trade-off, not a promise. Very low values increase query volume and still cannot provide request-by-request routing. Before a planned migration, reduce TTL far enough in advance for the old value to expire, then restore an appropriate value after the change is stable.
When round-robin DNS can still be useful
Multiple records can be reasonable when every destination is independently safe to receive traffic, the application tolerates client-side retry behavior, and occasional uneven distribution is acceptable. It can also expose several edge or service addresses where another layer handles failures.
It is a poor fit when a failed address must disappear quickly, requests modify tightly coupled state, users need sticky sessions, origins have unequal capacity, or the application cannot tolerate timeouts during retry.
What health-checked failover adds
A health-aware service probes each origin and changes routing when defined failure thresholds are met. The check should represent readiness to serve traffic, not merely that a machine responds to ping. Define protocol, path, expected status/body, timeout, interval, and the number of consecutive failures and successes.
Health-checked DNS still has propagation and caching behavior. A reverse proxy, application load balancer, or CDN edge can generally make a decision for a new connection or request without waiting for the user’s cached DNS answer to change.
Cloudflare-specific behavior
Cloudflare’s round-robin DNS documentation distinguishes unproxied multi-record DNS from proxied behavior. With DNS-only records, multiple addresses are returned and client behavior matters. With proxied records, users connect to Cloudflare; Cloudflare documents Zero-Downtime Failover for eligible proxied multi-origin records. For configurable health monitors, pools, steering, and automatic failover, Cloudflare provides its paid Load Balancing product.
If that is your platform, use the current Cloudflare automatic IP failover setup guide. Do not use legacy API-v1 scripts or expose a Global API Key.
Prepare the origins before distributing traffic
- Application versions: deploy compatible code and configuration to every origin.
- Database writes: choose an architecture with defined consistency and conflict behavior. Do not adopt multi-primary replication merely to make a diagram symmetrical.
- Sessions: use a shared store, stateless signed sessions, or intentional affinity. Local in-memory sessions do not follow a user to another server.
- Uploads and files: use shared/object storage or reliable replication, and test read-after-write behavior.
- Queues and scheduled work: prevent duplicate processing and ensure work survives the loss of one origin.
- TLS and hostnames: every route must validate and serve the intended name correctly.
- Security: restrict origin access where appropriate, protect health endpoints, and use least-privilege credentials.
- Capacity: the surviving route must handle the load it will inherit.
A safe test plan
- Map the path from authoritative DNS through resolver/cache, edge or load balancer, origin, session store, database, and third-party dependencies.
- Record normal answers and origin health from more than one external network.
- Test the dedicated health endpoint and a small set of critical user journeys.
- During a maintenance window, withdraw or disable one origin at the routing layer instead of unexpectedly crashing a production server.
- Measure detection, cached-answer behavior, new and existing sessions, errors, writes, queue processing, and recovery.
- Restore the origin, confirm consecutive healthy results, and watch for flapping or data reconciliation problems.
- Document rollback steps and the person authorized to execute them.
Monitor from outside the routing system
A provider’s health probe tells that provider what it can reach. An independent check tells you more about the path a user sees and can reveal a provider-wide, DNS, certificate, or configuration failure. Hitsteps uptime monitoring can serve as one external availability signal; it does not replace application, infrastructure, database, or security monitoring.
Bottom line
Use multiple DNS records when all returned addresses are safe and simple distribution is sufficient. Use health-checked routing when failed destinations must be removed automatically. Use a proxy, load balancer, or edge service when decisions need to happen faster than DNS caches refresh. In every case, resilient routing only works when sessions, data, files, capacity, TLS, health checks, monitoring, and rollback have been designed and tested together.
