Every DNS record carries a TTL, and most estates set them by superstition: 300 because a tutorial said so, 86400 because it was the default. The TTL is actually your failover clock and part of your latency budget, and it deserves engineering per record class.
What resolvers actually do with your TTL
The configured TTL is an upper bound on caching, not a contract: some resolvers clamp long TTLs down, some enforce minimums that stretch short ones, a few historically ignored them under load, and client-side caches (OS, browser, app) add their own layers with their own rules. Design for the distribution, not the config: your effective failover time is the tail of resolver behavior, which is why measured failover always lags the whiteboard number.
The TTL trade, stated plainly
Short TTLs buy agility, traffic moves within minutes for failover, steering, migration, and cost resolution latency (more lookups on user critical paths) plus higher authoritative query load. Long TTLs buy resolution speed and resilience to DNS-provider wobbles, and cost you agility exactly when an incident wants it. The resolution: classify records. Steering hostnames and anything multi-CDN: short (sixty to three hundred seconds). Stable infrastructure (MX, apex to load balancer that never moves): long. Nothing gets a TTL nobody chose.
The failover-drill evidence makes this concrete: estates that rehearse provider failover (our multi-CDN discipline) consistently find the DNS tail dominates recovery time, traffic follows a decay curve shaped by resolver caching, with a stubborn last few percent taking many times the configured TTL to move. The operational conclusions: quote failover in percentile terms (time to move 90 percent, 99 percent) rather than a single number, hold long-tail traffic capacity on the failed-from side longer than intuition suggests, and where the platform supports it, pair DNS steering with anycast or client-side switching for the traffic that must move instantly. The clock you configure is the beginning of the story, never the end.
CNAME chains, the hidden multiplier
Each CNAME hop is potentially another resolution with its own TTL, and modern delivery stacks love chains: your hostname to a vanity CNAME to a CDN service name to a regional target. Cold-cache resolution pays every link, and the chain’s effective TTL is its shortest hop. Audit real chains with dig +trace from multiple networks, flatten where vendors allow (ALIAS/ANAME at apex), and treat every added hop as a latency and failure-surface line item someone must justify.
In practice
Inventory records with owners and chosen TTLs; drop steering names to short TTLs a week before any planned migration (pre-warming the agility); measure actual propagation with distributed probes rather than trusting arithmetic; and put authoritative-DNS query load on a graph before shortening anything estate-wide. DNS is the layer above every failover plan in this series; its timers gate all of them.
Failover drills with measured decay curves are part of every resilience engagement here. The curve is the finding.