DNS is often described as the internet’s phone book, but the analogy hides the parts that matter in production. DNS is a distributed, cached naming system. It returns typed records, delegates authority between zones, and can influence where a client sends traffic. It does not maintain a live session with that client, and it cannot guarantee that every client immediately follows a routing change.
Those properties are central when DNS becomes part of a deployment, regional routing, or disaster-recovery design.
Follow a query from client to authority
Suppose an application needs an address for api.example.com. The browser or application runtime may already have a valid answer. The operating system can also maintain a cache. If neither can answer, the client’s stub resolver asks a configured recursive resolver, commonly provided by an enterprise, network operator, or public DNS service.
The recursive resolver checks its own cache. On a miss, it follows the hierarchy:
- a root server provides a referral to servers for the top-level domain;
- a top-level-domain server provides a referral to the domain’s authoritative name servers;
- an authoritative server returns the requested records, an alias that requires another lookup, or a negative response.
The recursive resolver caches eligible results and returns an answer to the client. Future clients using that resolver may receive the cached answer without repeating the hierarchy.
This separation matters operationally. Updating the authoritative zone does not push the new value into browser, operating-system, or recursive-resolver caches. The old answer can remain usable until its caching lifetime ends.
Records have different jobs
A records map a name to IPv4 addresses, while AAAA records contain IPv6 addresses. CNAME records make one name an alias of another name, subject to DNS rules that restrict coexistence with other data at the same owner name. Providers may offer non-standard alias-style behavior at a zone apex, so understand whether a feature is standard DNS or provider-side synthesis.
MX records identify mail exchangers and express preference. NS records identify authoritative servers for a zone or delegation. TXT records carry text used by several verification and policy mechanisms. Traffic-routing designs usually focus on A, AAAA, or aliases to provider-managed endpoints, but the surrounding delegation remains part of the failure path.
TTL controls reuse, not universal refresh time
A record’s time to live tells caches how long they may reuse that record. A longer TTL reduces repeated resolution work and can make the system less sensitive to transient authoritative DNS problems. It also allows an old routing answer to remain in use longer after a change.
A shorter TTL can reduce the permitted cache lifetime, but it does not create instantaneous failover. Changes made before the previous TTL expires can still be hidden by caches holding the old answer. Applications and intermediaries may also keep established connections after DNS is resolved. Some software applies its own resolution or connection-reuse behavior.
Negative responses can be cached too. If a name is queried before it exists, creating the record immediately afterwards does not guarantee that all clients can see it at once. Plan migrations and new hostnames with negative caching in mind.
TTL changes require sequencing. If a record currently has a long TTL, lower it far enough in advance for existing cached copies to expire before the planned routing event. After the transition is stable, decide whether the lower TTL is still worth its query and dependency tradeoffs.
Multiple addresses distribute opportunities
An authoritative answer can contain multiple A or AAAA records. The order may vary, and clients can choose among the returned addresses. This can spread connection attempts across endpoints without placing an application-aware load balancer at that exact decision point.
It is not precise request balancing. Recursive resolvers cache answers for many clients, client selection behavior varies, and existing connections bypass further DNS decisions. Uneven users and resolver populations can produce uneven load even when addresses appear equally often. DNS does not know whether one request is expensive or whether one endpoint is close to saturation.
Weighted, latency-based, geolocation, or health-aware DNS features are policies implemented by authoritative DNS providers. Their exact semantics differ. Treat them as control-plane decisions that produce DNS answers, not as continuous per-request routing.
For application-level algorithms, backend readiness, connection draining, and retry behavior, use the complementary discussion in Load Balancing in Production.
DNS failover has several clocks
A health-aware DNS service can stop returning an unhealthy endpoint, but at least four intervals affect what users experience:
- time for the health check to detect and confirm failure;
- time for the authoritative routing policy to change;
- remaining lifetime of previously cached answers;
- lifetime of established connections and application pools.
Removing an address from new answers does not revoke old answers. Clients can continue contacting the failed endpoint until their cache expires, and some may retry it according to local behavior. A short TTL narrows one interval but does not eliminate detection delay or connection reuse.
Health-check design needs the same care as load-balancer health checks. A superficial endpoint can report healthy while a critical dependency is broken. An overly broad check can remove an otherwise useful region because one optional dependency failed. Decide what user capability the check represents and whether failover has enough healthy capacity to accept the moved traffic.
Failback deserves equal attention. Automatically returning traffic to a recovered endpoint can create oscillation if health is unstable. Use confirmation thresholds, staged reintroduction where supported, and operational visibility into which answers are being served.
Protect the DNS control plane
Authoritative DNS is part of the service path even though clients can temporarily rely on caches. Use more than one authoritative server in an appropriately resilient setup. Protect registrar and DNS-provider accounts, apply controlled changes, and keep a recoverable record of zone configuration.
Delegation errors can make correct zone data unreachable. DNSSEC can provide authenticity for signed DNS data, but it introduces key and delegation management that must be operated correctly. Decide whether and how to use it based on the threat model and operational capability.
Monitor from outside the authoritative provider as well as inside it. Useful checks include delegation, expected record sets, resolution from representative resolvers, and connection success to the resulting destinations. Query success alone does not prove the application journey works.
Plan routing as a complete path
Before using DNS for regional or recovery routing, document the expected behavior during normal operation, partial failure, total endpoint failure, and recovery. State TTLs and detection intervals explicitly. Test with realistic caches and persistent connections rather than only querying an authoritative server directly.
An architecture review can help map DNS policy to downstream balancers, application capacity, state ownership, and recovery procedures. The important question is not whether DNS “supports failover,” but whether the complete path meets the application’s recovery needs under the expected failure modes.
DNS is excellent at scalable naming and cached distribution of routing answers. Its limitations are equally important: answers persist, clients retain choice, and connections outlive lookups. Designs that respect those facts are easier to operate than designs that assume a DNS edit behaves like an immediate global switch.
