DNS as your steering layer: anycast, latency, and EDNS0 reality
Resilient Cloud Networking on AWS — Patterns from the Field, Article 4
A few years ago, I sat with a payments team after a Friday-night failover that did not behave the way the runbook promised.
The application tier in the secondary Region was healthy. Amazon Route 53 had returned the secondary answer for the records that were eligible for failover. Synthetic checks from the recovery environment showed clean latency and clean responses. And yet a stubborn fraction of European users kept reaching the old endpoint, where the database was already in maintenance and the application was returning 5xx.
The first assumption on the bridge was that DNS had not propagated.
The real answer was less satisfying.
DNS had done what DNS could do. Some recursive resolvers and client stacks were still answering from cache, based on records whose Time To Live had been set to 900 seconds years earlier and never revisited.
That incident stayed with me because it exposed a mistake I still see in resilient cloud designs:
treating DNS like a static directory.
DNS is not just a phone book.
In a resilient architecture, DNS is often the steering layer. It is the part of the system that tells clients where to go when the underlying topology changes. If you treat it as a passive name-to-address database, you miss the point of services like Amazon Route 53, and your real blast radius can become wider than your architecture diagrams suggest.
This article looks at DNS as a steering layer on AWS, and why anycast, routing policies, TTLs, latency-based routing, and EDNS0 Client Subnet all matter when you design for resilience.
Anycast under the hood
Amazon Route 53 is a globally distributed authoritative DNS service. Its data plane runs across more than 200 points of presence and answers DNS queries based on your hosted zones and health-check data. Route 53 uses globally distributed DNS infrastructure, including anycast-based techniques, so that DNS queries are answered from resilient, distributed locations rather than from a single centralized endpoint.
When you create a public hosted zone, Route 53 delegates four authoritative name servers to the zone. These name servers are intentionally distributed across different name-server names and top-level domains, reducing dependence on a single name-server name or path. The important operational point is that you should not reason about Route 53 as one server, one Region, or one endpoint.
AWS also separates the Route 53 control plane from the data plane. The control plane is what you use when you create hosted zones, change records, or update configuration. The data plane is what answers DNS queries. For resilience design, this distinction matters. If you build recovery mechanisms that require last-minute control-plane changes during an incident, you are depending on the part of the service you least want to depend on during a severe event. AWS best practice is to rely on data-plane mechanisms for DNS failover and application recovery, including Route 53 health checks and Amazon Application Recovery Controller routing controls.
This is why Route 53 is often a strong foundation for DNS-based resilience. But it also creates a trap: the underlying DNS service can be highly resilient while the steering logic you build on top of it is fragile.
Most DNS-related incidents I see are not caused by authoritative DNS being unavailable. They are caused by incorrect assumptions about routing policy behavior, TTLs, health checks, resolver caching, or where the DNS query appears to come from.
Routing policies as steering primitives
Route 53 provides eight routing policies: Simple, Weighted, Latency, Failover, Geolocation, Geoproximity, IP-based, and Multivalue answer.
Each policy is a steering primitive.
Simple routing returns the configured answer without special steering logic. Weighted routing distributes responses across records according to configured weights and is useful for canaries, migrations, and staged rollouts. Failover routing returns a primary answer while it is healthy and a secondary answer when the primary is unhealthy. Latency-based routing selects the AWS Region that Route 53 determines provides the lowest latency for the user. Geolocation routes based on the geographic location associated with the DNS query. Geoproximity routes based on the location of users and resources, with optional bias to expand or shrink the area served by a resource. IP-based routing lets you map specific client CIDR ranges to specific answers. Multivalue answer routing can return multiple healthy records, up to eight, giving clients a simple form of DNS-level distribution.
The common mistake is assuming these policies magically compose in the way the architecture diagram suggests.
They do not.
Route 53 can support complex routing configurations, including nested combinations using alias records and health checks, but the actual behavior depends on how the records are structured. A design that looks like “health first, then latency” on a slide may not behave that way unless the record hierarchy actually evaluates in that order.
The practical test is simple: draw the resolver’s-eye view.
Start with the exact name being queried. Then walk the record hierarchy from that name downward. At each step, ask which policy is making the decision, what health checks are attached, whether alias evaluation is involved, and what TTL applies to the answer that resolvers and clients will cache.
If that path is not obvious to a colleague who has never seen the design, it will not be obvious to a tired engineer at 3 a.m.
Latency, EDNS0, and the geography problem
Latency-based routing is one of the first policies teams reach for in multi-Region active-active designs.
The intent is clear: send users to the Region that gives them the best network experience. Route 53 does this by using latency measurements between networks and AWS Regions, then selecting the latency record for the Region that appears to provide the lowest latency for the requester.
But there is a critical DNS reality here: authoritative DNS normally sees the recursive resolver, not necessarily the end user.
If a user in one country uses a recursive resolver whose query exits from another country or another network, the authoritative DNS service may only see the resolver’s apparent location or network. That can affect latency-based, geolocation, geoproximity, and IP-based steering decisions.
This is the problem EDNS0 Client Subnet was created to reduce.
With EDNS0 Client Subnet, a participating recursive resolver can include a truncated portion of the client’s IP prefix in the DNS query sent to the authoritative server. The authoritative server can then make a more informed steering decision based on the client subnet rather than only the resolver.
Route 53 supports EDNS0 Client Subnet for latency-based routing, geolocation routing, geoproximity routing, and IP-based routing. This can improve routing accuracy, especially for users behind large public resolvers.
But ECS is not magic, and it is not universal.
The RFC itself is clear that ECS has operational and privacy trade-offs. It exposes part of the client network to the authoritative DNS path. It can fragment resolver caches because different client subnets may receive different answers. It also depends on recursive resolvers supporting and forwarding the ECS option.
For resilient architecture, the design rule is this:
Use ECS-aware DNS steering to improve average routing accuracy, but do not build correctness assumptions on top of it.
If a decision must be exact, enforce it closer to the application data plane: at the load balancer, in the application, with cell-aware routing, with explicit customer-to-cell mapping, or with Amazon Application Recovery Controller for controlled recovery operations.
DNS is a steering layer. It is not a transaction coordinator.
Failover, TTLs, and the cache you forgot about
The 900-second TTL from the opening story is one of the most common DNS failover problems.
A Route 53 health check can detect endpoint failure and Route 53 failover routing can stop returning an unhealthy primary answer. Health checks can run at 30-second or 10-second intervals depending on configuration. For records associated with health checks, AWS recommends a TTL of 60 seconds or less so clients respond quickly to changes in health status.
But a low TTL is not a guarantee that every user moves instantly.
DNS has multiple caching layers. Recursive resolvers cache answers. Operating systems cache answers. Browsers, runtimes, SDKs, connection pools, and applications may also cache or reuse connections. Some resolvers or clients may not honor TTLs exactly. Long-lived TCP connections may continue to use an old endpoint even after DNS has changed.
This is why DNS failover should always be described as bounded and probabilistic, not instantaneous.
A low TTL gives your steering layer a better chance of moving traffic quickly. It does not erase the behavior of every resolver, client, and application on the internet.
For critical workloads, I prefer three practical principles:
- Use low TTLs on records that participate in failover, commonly 60 seconds or less.
- Test failover from real client networks, not only from synthetic probes inside AWS.
- Use data-plane recovery controls for deliberate failover decisions. ARC routing controls are useful because they integrate with Route 53 health checks and let operators switch traffic through highly available data-plane mechanisms rather than relying on emergency control-plane updates during an incident.
This matters most in regulated or high-impact workloads, where the difficult failure mode is not always “primary is clearly dead.” Often the hard case is ambiguity: partial failure, data-plane degradation, dependency brownout, or a business decision to evacuate before health checks become completely red.
Hybrid resolution: keep the chain short
Hybrid DNS adds another layer of risk.
Route 53 Resolver inbound and outbound endpoints allow DNS resolution between VPCs and on-premises environments over private connectivity such as AWS Direct Connect or AWS Site-to-Site VPN. This is powerful, especially when you use private hosted zones and conditional forwarding.
But hybrid DNS designs can become fragile quickly.
The pattern that ages well is to keep authority clear. One zone should have one authoritative owner. Forward conditionally only where required. Avoid long resolver chains. Every additional resolver hop adds timeout behavior, cache behavior, logging gaps, operational ownership questions, and failure modes that are difficult to reason about during an incident.
A DNS path that looks clever during design review can become a forensic nightmare during an outage.
When I review hybrid DNS architectures, I usually ask four questions:
- Who is authoritative for this zone?
- Which resolver receives the first query?
- How many hops exist before an authoritative answer is reached?
- What happens if any one hop is slow, unavailable, or returning stale data?
If the team cannot answer those questions quickly, the DNS design is not operationally ready.
DNS is steering, not salvation
DNS done well is almost invisible.
It sends users where the design says they should go. It supports graceful failure handling. It lets you shift traffic between cells, Availability Zones, Regions, or providers. It gives your architecture a control point that is simple, global, and widely supported.
But DNS cannot compensate for an application that is not ready to receive traffic. It cannot make stale clients disappear. It cannot guarantee that every resolver behaves perfectly. It cannot turn a cold standby into a warm recovery environment. And it cannot replace a tested recovery plan.
The best resilience designs treat DNS as one steering layer among several.
Use Route 53 for globally distributed authoritative DNS, health-aware responses, and routing policies. Use low TTLs for records involved in failover. Use EDNS0 Client Subnet where it helps, but understand its limits. Use ARC routing controls when you need deliberate, data-plane recovery actions. Keep hybrid resolver chains short and authority boundaries clear. Test from real client locations and real resolver paths.
The lesson from that Friday-night failover was not that DNS failed.
The lesson was that the team expected DNS to behave like an immediate command channel when it was actually a cached, distributed steering system.
Once you understand that distinction, you design differently.
And your recovery story becomes much more credible.
Cristian Critelli is the EMEA Lead for Networking and Resilience Specialist Partner Solutions Architect at AWS focused on networking and resilience across EMEA. His book, Cloud Networking and Resilience (Apress), was released in May 2026.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article