DNS TTLs and Failover: Tuning for Fast Recovery

The Problem With Default TTLs

Most DNS providers ship with default TTLs of 3600 seconds — one hour. That's fine for stable infrastructure, but it's a disaster waiting to happen when you need to cut over to a backup IP during an outage. Resolvers and ISP caches across the internet will keep serving the dead address for up to an hour, and there's nothing you can do about it after the fact.

TTL tuning is one of those things that only matters when everything is going wrong. That's exactly why you should think about it now.

How TTLs Actually Work

A TTL (Time to Live) is a value in seconds attached to each DNS record. When a resolver fetches your record, it caches it for that duration. Until the TTL expires, it won't go back to your authoritative nameserver — it'll serve the cached answer, even if you've already updated it.

A few things worth knowing:

• TTLs are set per record, not per zone globally. Your A record and MX record can have different TTLs.
• Resolvers are not required to honor TTLs exactly. Some enforce a minimum floor (often 30–60 seconds). A TTL of 0 is technically valid but widely mishandled.
• The clock starts when the resolver fetches the record, not when you make a change. A cached record with 45 minutes left will stay cached for 45 minutes regardless of what you do upstream.
• Negative TTLs (for NXDOMAIN responses) are controlled by the SOA record's minimum field.

Choosing the Right TTL for Your Records

Production A and AAAA Records

For services where you need fast failover, a TTL of 60 seconds is a reasonable floor. It's low enough that most of the internet will pick up your change within a couple of minutes, without hammering your authoritative DNS with excessive queries.

Some teams go as low as 30 seconds. Below that, you're in diminishing-returns territory, and a handful of resolvers will ignore it anyway.

CNAMEs Pointing to Load Balancers or CDNs

If you're using a CNAME to a provider like Cloudflare or AWS CloudFront, the TTL on your CNAME matters less — the provider controls the final resolution. Follow their recommendations, but 300 seconds is typically fine here.

Pre-Failover Lowering (The Key Technique)

This is the most important pattern: lower your TTL well before you think you'll need failover, not after an incident starts.

Here's a practical pre-maintenance rundown:

1. 72 hours before: Drop TTL from 3600 to 300 seconds. This gives existing caches time to expire at the old value before you lower further.
2. 24 hours before: Drop to 60 seconds.
3. During maintenance or failover: Update the A record to point to your backup. Most resolvers will pick it up within 1–2 minutes.
4. After recovery: Update back to your primary, then gradually raise the TTL back to 300 or 3600 over the following days.

Skipping step 1 is the classic mistake. If your TTL is 3600 and you lower it to 60 right before a failover, resolvers that cached the record 30 minutes ago still have 30 minutes left to serve. You haven't bought yourself anything.

DNS Failover With Health Checks

Many DNS providers (Route 53, Cloudflare, NS1, DNSimple) support health-check-based DNS failover. The nameserver itself monitors your endpoint and swaps the record automatically when it goes down.

This is powerful, but it has limits:

• Health checks originate from a fixed set of probe locations. A regional outage or network partition may not be visible from those locations.
• The failover only triggers after the health check fails and the TTL on the cached record expires. At 60 seconds, that's manageable. At 3600, it's not.
• Some providers add their own propagation delay on top.

Running independent uptime monitoring from multiple geographic regions — separate from your DNS provider's health checks — gives you a second opinion. If Pingy's monitors in Frankfurt, Singapore, and São Paulo all see your endpoint as down but your DNS provider's US-only probe still thinks it's up, you catch the discrepancy before your provider's failover logic does.

What About Anycast and GeoDNS?

If you're using Anycast routing or GeoDNS, TTL tuning still matters for the CNAME or NS delegation records higher up the chain. A long TTL at the delegation layer can trap users on a stale path even when your Anycast infrastructure has already rerouted. Keep delegation TTLs in the 300–600 second range.

Key Takeaways

• Default TTLs of 3600 seconds are too long for any service that needs fast failover.
• Lower TTLs before planned maintenance, not during an incident — you need to wait out the old TTL first.
• 60 seconds is a practical minimum for production A/AAAA records; below 30 seconds offers little real-world benefit.
• DNS provider health checks are useful but probe from limited locations — supplement with independent multi-region monitoring.
• Raise TTLs back up after recovery; perpetually low TTLs increase DNS query load and reduce cache efficiency unnecessarily.