A disaster recovery plan that says "point DNS at the recovery site" has a number hiding in it. It is the TTL on the record you change, and every resolver that already holds the old answer keeps sending customers to the dead primary until its copy expires. Changing the record during the outage does nothing about copies already handed out.
That number decides DNS failover time more than anything in the DR runbook, so we went and read it off a real population: the public DNS behind all 39 websites in the Central Bank of Kenya's directory of licensed banks. CloudSpinx designs and tests disaster recovery for businesses in Kenya, and the name customers type is the one piece of a switchover that a restore test never touches.
What 39 Kenyan bank websites tell you about DNS failover
We took each website from CBK's directory, asked each bank's own nameservers for the record so the TTL is the owner's figure and not a cache counting down, and looked up who holds the address it ends at.
Two different designs fall out of it.
21 of the 39 end at a proxy or CDN edge: Cloudflare on 10, Imperva on 5, and six other services with one bank each. For these, the address a customer's resolver holds belongs to the proxy. Moving the website to a recovery site means telling the proxy to use a different origin, and no customer's resolver has to notice.
18 point straight at a server address: 17 in a hosting, cloud or ISP network and one in address space the bank announces itself. For the 17, failover is a DNS change, and the TTL is the floor under it. The one could in principle move the route instead, and nothing public shows whether it does. Seven set five minutes or less, short enough that the DNS change is not the slow part. Six sit between ten minutes and an hour. Five set four hours or more: two at four hours, one at 10 hours 40 minutes, one at a day and one at a full week.
- origin moves behind the proxy
- TTL 5 min or less
- 10 min to 1 h
- 4 h or more
The proxy row is not free of DNS either. Six of those banks point their own record at the proxy with a TTL of an hour or more, which only bites when the proxy is what has to be bypassed.
Two oddities from the same run, neither of which changes the counts. Four of the names in the directory do not resolve to an address at all, so we surveyed the name each bank does serve. And seven are a foreign parent group's global website rather than a Kenyan one, counted as listed, because that is the address the regulator gives a customer. It is the population we counted for DMARC, read by website this time instead of by mail domain.
The TTL you set is not the TTL a resolver keeps
The week-long record is the useful one, because any resolver that caps below a week has to show its cap on it. We asked three public resolvers for it, three times each. Google Public DNS never answered with more than 21,600 seconds, six hours, which matches Google's own FAQ: TTLs there "are generally limited to six hours even if the actual TTL is longer". Quad9 never went above 43,200, twelve hours. Cloudflare's 1.1.1.1 handed back the full 604,800.
The one-day record behaved the same way: 21,600 from Google, 43,200 from Quad9, 86,400 from Cloudflare. A 38,400-second record came back whole from Quad9 and Cloudflare and capped at 21,600 by Google.
- old address can still be served
A cap only ever shortens a TTL. Lowering the record before a planned switchover works only if you do it one old TTL ahead, and for this record that is a full week, because one of the three keeps the old figure whole.
So the delay a customer sees depends on a resolver they chose, or their ISP chose for them. We did not measure the resolvers Kenyan ISPs hand their customers, so we do not know what Safaricom's or Airtel's resolvers cap at. Plan as if they keep the full TTL.
This is where the common advice, lower the TTL before you fail over, runs out. It works for a planned move if you lower it at least one old TTL ahead. For an unplanned outage, the TTL that counts is the one that was live yesterday. If yours is a day, some customers are on the dead address for a day, whatever you type at 2 a.m. Google and Cloudflare each run a public page that flushes one name from their caches, which helps their users and nobody on an ISP's resolver or behind a device's own cache.
Some clients ignore the record's TTL entirely. A Java application server caches lookups by its own rule: OpenJDK's java.security file defaults to 30 seconds, and a negative value caches forever. Anything set to -1, or anything that resolves once at start and holds a connection pool, calls the primary until somebody restarts it.
If you want those numbers for your own names before an outage finds them, the DR scoping form takes a list of hostnames, and we send back how long resolvers can keep each one's old address.
A proxy takes the TTL out, and leaves three things in
Cloudflare puts the case against DNS failover better than we can, on its own load balancing proxy modes page. A proxied load balancer "offers faster failover and more accurate routing, which can otherwise be affected by DNS caching". A DNS-only one warns that "if a client has a cached DNS response, they will go to their previous destination, potentially ignoring your load balancer." That is the vendor telling you its own DNS product is the slower way to fail over.
A proxy still leaves work in three places.
The proxy covers web traffic. Cloudflare proxies its listed HTTP and HTTPS ports by default and needs Spectrum, on the Enterprise plan for all TCP and UDP ports, for anything else. An SFTP drop a partner pushes files to, a VPN endpoint, a mail relay: unless each is put through the proxy too, it still reaches you by its own DNS record and TTL, or by an address somebody typed in.
The origin has to accept the proxy at the recovery site too. The firewall that only lets the proxy's ranges in, the TLS certificate the proxy validates and any origin authentication have to exist on the standby before the day, whether it sits in a cloud region reached over a VPN or Direct Connect or in a second facility in Kenya. Otherwise the switch works and the site returns errors.
And the record pointing at the proxy has a TTL of its own. Six of the 21 banks set it at an hour or more, at least two of them at about a day. That does not matter until the proxy is what fails, or what you need to bypass, and then you are on the same clock as everyone in the other row.
Where the nameservers sit matters more than either
Leaving aside the large DNS services, two of the 39 zones keep every nameserver inside one network: one pair in a single /24 the bank group announces itself, the other set inside one ISP's network. If that network is part of the outage, there is no server left to hand out the new address, however short the TTL. RFC 2182, the best current practice on secondary DNS servers (BCP 16), says secondary servers "must be placed at both topologically and geographically dispersed locations on the Internet", and the reason is exactly this day.
Check it the same way we did, against every one of your own nameservers and then against what the big resolvers are holding right now:
for ns in $(dig +short NS example.co.ke); do echo "$ns"; dig +norecurse +noall +answer A www.example.co.ke @$ns; done
dig +noall +answer A www.example.co.ke @8.8.8.8
dig +noall +answer A www.example.co.ke @1.1.1.1The loop prints the TTL you set, once per nameserver, and they can disagree: for one bank in our run, three of its five nameservers answered a day and the other two four hours. The last two lines are what Google's and Cloudflare's resolvers are handing out right now, counting down. If an ISP failover is also in the plan, the same discipline applies to the links: time it, do not assume it.
Who needs this checked
If your site sits behind a proxy, its origin pool already has the recovery site in it, and no partner or app reaches you by any other name, you do not need us for this part. Test the origin switch with the proxy's own health check and move on to the data, which is where CBK's outsourcing approval comes in for a bank.
Then there are the names nobody wrote into the DR plan: the API the mobile app calls, the file drop, the VPN, the mail relay. Send us every hostname customers and partners use, who runs your DNS and the switchover step from your DR plan, through the scoping form or on WhatsApp at +254 713 403 044. You get back how long resolvers can hold each name's old address, read from your own nameservers, what still points at the primary, and a failover test scoped to prove it. If the recovery origin has to be a server in Nairobi, we hand one over in about 24 hours. Reading your DNS costs you nothing and commits you to nothing.