High DNS TTL on Failover Records Stalls DR Cutover
A failover CNAME or A record carries the zone's default TTL of an hour or more, so when disaster recovery routing flips at the authoritative nameserver, cached answers on recursive resolvers, container stub resolvers, and ISP infrastructure keep pointing clients at the dead primary for the full TTL window, regardless of how fast the health check reacts.
At a glance
- Unsafe setting
- Failover CNAME/A records inherit the zone's default TTL of 3600s or higher instead of a dedicated low-TTL failover profile.
- Failure trigger
- Primary site fails and failover routing updates the authoritative answer while resolvers still hold the long-TTL cached record.
- Blast radius
- Clients and application connection pools keep resolving to the dead primary for up to the full TTL duration, turning a minutes-long RTO into a multi-hour outage.
- Recommended control
- Cap TTL at 60 seconds on all failover-participating records and validate propagation across independent resolvers before relying on DNS-based cutover.
Fix commands and configuration
aws route53 change-resource-record-sets --hosted-zone-id ZXXXXX --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"app.example.com","Type":"CNAME","TTL":60,"ResourceRecords":[{"Value":"failover-target.example.com"}]}}]}'dig +nocmd app.example.com CNAME +noall +answer @8.8.8.8The Trap
Failover-critical A and CNAME records ship with a TTL inherited from the zone’s steady-state defaults, typically 3600 seconds or higher, with no separate low-TTL profile for records that participate in disaster recovery cutover.
The Default State
Most managed DNS platforms — Route 53, Azure DNS, Cloudflare — apply a default TTL of 300 to 3600 seconds when a hosted zone is created, and operations teams routinely raise this further, to 43200 or 86400 seconds, on records they consider “stable” because the target rarely changes. Failover CNAMEs pointing at a load balancer, a Traffic Manager profile, or an active-passive VIP get folded into this same policy. Nobody distinguishes between a marketing subdomain that changes once a year and a database endpoint that must repoint within the RTO window during an outage.
The Blast Radius
When the primary site fails and the failover routing policy flips the answer, the new record is correct at the authoritative nameserver within seconds. Every recursive resolver that already holds the old answer keeps serving it until the cached TTL expires — up to 24 hours if that was the configured value. Worse, several large public resolvers enforce a minimum TTL floor regardless of what the authoritative server publishes for negative or low-TTL answers, and stub resolvers inside application containers and the Windows DNS Client service cache independently of the OS-level TTL, adding further drift. Client connection pools keep retrying a dead IP, health checks on the DNS provider’s side show green because they query the authoritative server directly, and the incident bridge spends hours chasing an application fault that is actually a caching artefact. An RTO of five minutes documented in the DR runbook becomes a multi-hour outage purely because nobody touched the TTL before the record was declared failover-capable.
The Lead Mechanic Fix
Set a hard ceiling of 60 seconds on any record participating in a failover or health-check-based routing policy, enforced separately from the zone’s general TTL policy — for Route 53, this means the alias or weighted/failover record set explicitly, not the apex NS/SOA. Stage the change at least one TTL cycle before any planned DR test: aws route53 change-resource-record-sets --hosted-zone-id ZXXXXX --change-batch '{"Changes":[{"Action":"UPSERT","ResourceRecordSet":{"Name":"app.example.com","Type":"CNAME","TTL":60,"ResourceRecords":[{"Value":"failover-target.example.com"}]}}]}'. Verify propagation with dig +nocmd app.example.com CNAME +noall +answer @8.8.8.8 against at least three independent resolver populations, and confirm no floor is being applied above the configured value. For any RTO under 60 seconds, do not rely on DNS TTL at all — front the failover with an anycast IP or a load balancer that reassigns backend targets without a resolver round-trip.