Network & Infrastructure / High Availability & Recovery Design
DNS-based failover and the cache contribution to recovery time
A failover platform changes a service address rapidly, but some clients continue using the failed destination. The recovery promise excluded resolver and application caching behavior.
Environment and inputs: Routed and clustered services; define failure ownership, fencing and application recovery requirements before testing. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Record health-detection time, publication time, previous TTLs, recursive remaining lifetimes and application connection reuse. Include negative caching if the cutover can temporarily remove a record.
Explain the result
DNS publication does not force every client to refresh immediately. Effective failover time includes cache and connection behavior outside the authoritative service's direct control.
Plan the fix
Design overlap, endpoint persistence or another failover mechanism when the required recovery bound is tighter than observed caching behavior. Set expectations using tested clients and previous TTLs.
Check the result and rollback
Test warm-cache clients and long-lived connections during a controlled endpoint failure. Restore the previous design if the new mechanism cannot meet the documented objective for supported clients.