DNS cutovers: budget for resolver caches and mixed destinations

Operational decision

A claims endpoint moves to a new edge provider. Lower the existing record's TTL ahead of the cutover and wait at least the prior TTL before relying on the lower value. Prepare both old and new backends to serve compatible requests during the overlap. The shell sample reads a public name through two recursive resolvers and checks the TLS handshake; it does not alter DNS or verify the application response. Record the authoritative answer, resolver answers, certificate, route, and a user transaction from outside the cluster. Keep the old destination healthy through the cache window and connection-drain period. If the new route fails, restoring the previous record does not instantly move clients back; the new answer may also be cached. Confirm the domain's delegated name servers point to the zone you edited before declaring a propagation incident.

dig claims.aitrove.test A @1.1.1.1
dig claims.aitrove.test A @8.8.8.8
openssl s_client -connect claims.aitrove.test:443 -servername claims.aitrove.test -verify_return_error </dev/null

Cost and verification

A short TTL increases resolver traffic and can make an emergency change appear quicker, but it cannot erase values already cached under the old TTL. Maintaining two serving destinations costs extra compute and coordination. DNS health is not application health: a correct address may lead to an invalid certificate or a broken write path. Measure a real external transaction and continue watching both destinations until old connections have drained.

Common Mistakes

• Do not lower TTL at the exact cutover and expect old caches to forget their answer.
• Do not shut down the old endpoint as soon as the authoritative record changes.
• Do not treat one resolver response as global propagation proof.

Connected lessons

• DevOps: delivery, infrastructure, and reliable operations
• DNS, TLS, and reverse-proxy failure boundaries
• Egress policy and DNS: restrict destinations without breaking name resolution
• Progressive delivery: canary checks and rollback
• Synthetic transactions: measure the route a user actually takes

Practice and check

• Project: release across identity, capacity, DNS, and events
• DevOps system boundaries decisions

Advanced follow-up

• DNS negative caching: avoid creating a name after clients already asked for it

Recovery execution follow-up

• Cutover drains: handle old connections and ambiguous client retries