High DNS TTL on Failover Records Stalls DR Cutover

The 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.