TL;DR: Three delays stack: the health check needs several consecutive failures to declare a region dead (tens of seconds), ordinary DNS TTL bounds cache lifetime, while resolver serve-stale policy and application connection caching can extend use of an old endpoint. Budget a minute to many minutes of user-visible impact, and treat DNS as coarse regional routing rather than a failover mechanism.
How to approach it
Walk the timeline of a request during failure, naming where time accumulates. Then state what DNS failover is actually good for, because the senior answer includes knowing when not to use it.
A strong answer
Detection lag. Health checks poll from multiple locations on an interval (minimum 10 seconds typically) and require a threshold of consecutive failures before flipping routing. A region that degrades gradually (timeouts instead of refusals) can take several intervals plus retries to trip. Thirty to ninety seconds from first user impact to route change is normal and by design; flapping protection exists so one dropped check does not evacuate a healthy region.
Propagation lag. The TTL you set (60 seconds if you were aggressive) is an upper bound on ordinary use of that cached record, not a minimum. Each resolver may hold a different remaining TTL when routing changes. Serve-stale is a separate policy for using expired data during refresh failures, and negative answers have their own caching rules. RFC8767 explains the stale-data exception.
Client-side caching. Browsers, mobile SDKs, JVMs (whose positive and negative cache settings depend on runtime version and configuration), gRPC channel state and long-lived connection pools hold resolved addresses regardless of DNS. A native app that resolved your old region IP will keep hammering it until its own retry or reconnect logic gives up. Nothing you do in the DNS console reaches these clients until they look up again.
So the honest budget is the sum of three independent delays, and it is worth adding up once because each layer is owned by someone different.
Detection comes first: health checks on a 10-second interval requiring three consecutive failures is 3 × 10 = 30 seconds before routing changes, and a region that degrades into timeouts rather than refusals stretches that to a minute or more as checks wait out their own timeouts.
Residual cache comes second, and what matters about it is that each resolver holds a remainder rather than a fresh TTL. Resolvers that fetched the record at staggered moments hold staggered remainders, so with a 60-second TTL the population drains over the following 60 seconds instead of switching together. Users move in a smear, not a step, which is why the error rate decays rather than dropping.
The third delay has no ceiling, because it belongs to the client. A process that resolved once and pooled the connection is not consulting DNS at all, and a runtime whose positive cache is effectively unbounded never will until it restarts. So the floor is roughly 30 + 60 = 90 seconds and the tail is set by the worst-behaved client in your install base, which for a mobile app is a number you do not control and cannot measure from the DNS console.
That asymmetry is the whole finding: lowering the TTL shortens the second term only, and the second term is rarely the one that hurts. That is why DNS failover is the wrong tool for hiding a zonal failure but a reasonable tool for surviving a total regional loss, where minutes of degradation beat hours of darkness.
Making it better within DNS's limits:
- Lower TTLs ahead of known risky windows (they cost resolver QPS permanently otherwise).
- Health-check aggressively from multiple regions against real user journeys (a page that renders), not TCP port checks that pass while the app 500s.
- Combine with client-side resilience: SDKs with endpoint lists and their own health checking fail over in seconds without DNS at all.
- For active-active, weight traffic across regions permanently rather than flipping: this keeps both regions active, but clients caching a failed endpoint still experience errors until they resolve or reconnect elsewhere.
The position that follows: DNS decides which region users start with. Availability inside that decision comes from anycast networks, load balancer health checks and application-level retries, all of which react in seconds. Teams that reach for DNS as their primary failover mechanism usually need one of those layers instead.
What interviewers probe next
"Why not set TTL to zero?" Resolvers treat very low values as abusive, some clamp to minimums anyway, and your authoritative servers face query storms. You buy seconds at real cost.
"Active-active versus active-passive here?" Active-passive wastes a region idling and still eats the flip delay; active-active with weighted routing keeps both warm but the affected fraction depends on weights, caching and connections, not a fixed half.
"How would you prove the recovery time?" Drill it: fail the active region's health endpoint in staging-equivalent and measure client-visible error duration from real client SDKs, not from the console's view of itself.
Common mistakes
Quoting the console TTL as user-impact time. Detection plus propagation plus client caches is the real number, and each term exceeds intuition.
Health-checking the load balancer instead of the user journey. Green checks on a port that accepts connections while every request fails are how false confidence ships.
Designing DNS failover as the only line of defence and discovering mobile clients never asked DNS again.