Thinking DNS Failover Is Instant, Until a Day-Long TTL Becomes Your Real RTO

A lot of disaster recovery plans contain a line like this: if the primary server goes down, point the A record at the standby. The assumption behind it is that the moment you click save in the DNS panel, visitors start landing on the standby. They don't. Anyone whose resolver already cached the old address keeps getting sent to the dead server until that cached answer expires, and the record's TTL decides how long that is. If the TTL on that record is a full day, your DNS failover has a recovery time of up to a day, no matter what the DR document says.

Why saving the record doesn't move anyone

When a browser asks for www.example.com, it usually doesn't ask your nameservers directly. It asks a recursive resolver: the one run by the visitor's ISP, their office network, or a public service like 8.8.8.8 or 1.1.1.1. That resolver fetches the answer from your authoritative nameservers once, then keeps it in cache for the number of seconds in the TTL (time to live) field and answers everyone else from that cache. That cache is the whole point of DNS scaling, and it's also why failover isn't instant. Changing the record on your authoritative servers changes what they hand out to resolvers that ask from now on. It does nothing to the copies already sitting in thousands of resolver caches. There is no push mechanism that tells resolvers to forget an answer early. Each one holds on until its own countdown hits zero. So the worst case is simple. A resolver fetched the record one second before you made the change. It will serve the old IP for almost the entire TTL. With a TTL of 86400 seconds, that's close to 24 hours of traffic going to a server that isn't there. In support, this usually shows up as a confusing split: the site owner says the site is back because it loads for them, while some of their visitors still see timeouts. Both are telling the truth. They're just behind different resolvers with different cache ages.

What your effective RTO actually adds up to

RTO (recovery time objective) is the target for how long service can be down. For DNS-based failover, the real number is a sum, not just the time it takes someone to edit a record:

Detection time: how long until monitoring or a person notices the primary is down.
Decision and change time: someone has to decide to fail over and make the edit, or a health-checked failover service has to flip the record automatically.
Nameserver sync: if you run secondary nameservers, they need to pick up the new zone. With NOTIFY and zone transfers configured this is typically quick. If secondaries only check on the SOA refresh interval, it can take much longer, and during that window different nameservers give different answers.
Resolver cache expiry: up to one full TTL of the record, as described above.
Client-side caching: operating systems, browsers, and especially applications can hold on to resolved addresses on their own. Some apps resolve a hostname once at startup and never look again. Long-lived connection pools keep talking to the old IP until the connections break.

As an illustrative example: five minutes to detect, five minutes to act, and a TTL of one hour gives you a worst case a bit over an hour for most visitors, plus whatever the slow clients add. Swap the one hour TTL for one day and the same plan quietly becomes a one-day RTO. The first two steps are the ones people rehearse. Step four is the one that usually dominates. There are a few more wrinkles worth knowing. Some resolvers cap very long TTLs or enforce a minimum, so the TTL you set is a request, not a guarantee. Some resolvers can also serve stale answers when they can't reach your authoritative servers. All of this depends on the resolver software and how its operator configured it, and none of it is under your control. Plan around the TTL you publish, and treat resolver behavior as noise on top.

Checking what TTL the world is actually seeing

The TTL in your DNS panel is the starting value. What matters during an incident is what resolvers hold right now. You can see both with dig: ask your authoritative nameserver directly for the configured TTL, then ask a public resolver to see the remaining countdown in its cache.

BASH

# Configured TTL, straight from your authoritative nameserver
dig +noall +answer www.example.com A @ns1.your-dns-provider.example

# Remaining TTL in a public resolver's cache (run it twice and watch it drop)
dig +noall +answer www.example.com A @1.1.1.1

Illustrative output format:

TEXT

www.example.com.    86400   IN  A   192.0.2.10
www.example.com.    61237   IN  A   192.0.2.10

The second number in each line is the TTL in seconds. The first line is the full configured value. The second is a cached copy that still has about 17 hours left, which means that resolver will keep sending people to 192.0.2.10 for that long even if you changed the record a minute ago. A couple of places hide long TTLs that people forget about:

CNAME chains. If www is a CNAME to lb.example.net, which points to an A record, each link is cached separately with its own TTL. A short TTL on the A record doesn't help if the CNAME in front of it has a long one and you need to change the CNAME target.
Nameserver delegation. If your failover plan involves switching to a different DNS provider, the NS records at the parent zone (the TLD) have their own TTL, set by the registry, and it's often long. You can see it with a non-recursive query to the TLD's servers, for example dig +norecurse +noall +authority example.com NS @a.gtld-servers.net for a .com domain. That number is not something you can lower.

Lowering TTL only works if you did it earlier

The common reaction is: fine, when trouble starts, drop the TTL to 60 seconds. The catch is that the lower TTL only reaches resolvers when they come back to fetch the record, and they only come back after the old TTL expires. Lowering a 24 hour TTL during an outage changes nothing for resolvers that already cached the 24 hour version. You're still waiting out the old value. That's why planned migrations lower TTL a day or more ahead of time. For failover, there is no ahead of time, because you don't know when the outage will happen. The only way to have a short TTL during an incident is to have it all the time on the records you intend to fail over. Even a short TTL isn't a clean switch. Different resolvers expire at different moments, so for a while some visitors reach the standby and some still try the primary. If both are actually running, that can mean writes landing in two places. That problem has its own write-up in Why Dropping DNS TTL to 60 Seconds Fails to Prevent Cutover Split-Brain, so it won't be repeated here. The point for this article is narrower: whatever TTL is live when things break is the floor of your recovery time.

The production pattern that keeps DR plans honest

A few rules of thumb hold up well in practice. Keep failover records on a permanently short TTL. Records that a DR plan expects to change, like the main site A record or an API hostname, should carry a TTL that fits your RTO all year, not just during migrations. The trade-off is more queries to your authoritative servers and an occasional extra lookup for visitors. For most sites that cost is small compared to a day of partial downtime, but it depends on traffic volume and what your DNS provider charges or limits. Records that never move, like MX for a stable mail setup or verification TXT records, can stay long. Write the TTL into the RTO. If the DR document says one hour recovery, someone should be able to point at the TTL of each failover record and see that it fits, with room left for detection and the change itself. Review TTLs as a routine check, not a one-off. TTLs drift. Someone migrates DNS providers and the import resets values to a default, or a well-meaning admin raises a TTL to reduce query volume, and the failover plan quietly breaks without anyone touching it. A small check against your authoritative server makes this easy to catch:

BASH

# Print the configured TTL for each record a failover plan depends on
for name in www.example.com api.example.com; do
  dig +noall +answer "$name" A @ns1.your-dns-provider.example
done

Run it during regular reviews or from monitoring, and alert if any failover record goes above the TTL your RTO allows. Include CNAME targets in the list. Consider failover that doesn't need DNS to change at all. If the address visitors resolve belongs to a load balancer, a floating IP, or something that can be moved between servers, the DNS answer stays the same and caches stop mattering. DNS failover is still useful, especially for simple setups, but it's the option with the cache problem built in. Test it from the outside. A failover drill should be timed from the visitor's side, using a public resolver and a real client, not from the moment the panel says saved. The short version: DNS failover is only as fast as the oldest cached answer out there. Before trusting a failover plan, check the TTL on every record it depends on, make sure the worst case fits the RTO you promised, and put that check on a schedule so it stays true.