A DNS record change is not an instant client route change. Recursive resolvers may keep an earlier positive answer until its TTL expires; a missing name can also be cached as a negative answer. Applications add their own connection reuse and address caches. A low TTL set minutes before a cutover cannot retroactively shorten answers already cached with a longer TTL. DNS decides where a new connection may go; it does not make an in-flight request, browser tab, or database write safe. A cutover plan must include overlap between old and new endpoints, certificate coverage, health checks, and a rollback window.
DNS TTL, Negative Cache, and Cutover Planning
Working case
The permit portal moves its case API from region 29 to region 47. The old record has a one-hour TTL. An operator lowers it to 63 seconds and changes the address five minutes later, then turns off region 29. Some users still resolve the old address and receive connection errors. A new status host was also queried before it existed, so a resolver has cached the negative answer. The revised plan lowers TTL well ahead of the move, brings up the new endpoint and certificate first, keeps both endpoints safe during overlap, then observes resolver and connection behavior before draining the old route. A rollback remains possible while the old service stays healthy.
Implementation boundary
function oldEndpointMustStay(nowSeconds, oldAnswerCachedAt, oldTtlSeconds) {
return nowSeconds < oldAnswerCachedAt + oldTtlSeconds;
}
console.log(oldEndpointMustStay(300, 0, 3600));
// Output: trueInventory authoritative records, aliases, dependent hostnames, current TTLs, negative-answer policy, and the resolvers used by important clients. Change a long positive TTL at least one previous TTL before the traffic switch, then verify authoritative answers from more than one network. Create new hostnames before clients first request them; if an NXDOMAIN result has already been cached, wait for its negative cache window or choose a different rollout path. Run both destinations during the overlap and make each serve the same current authorization and data contract. Do not use DNS alone as a per-request health mechanism; existing connections and clients that cache addresses may persist. Drain old endpoints only after observed traffic, connection lifetime, and rollback needs have been addressed.
Cost and boundaries
A lower TTL increases resolver queries and may reduce cache efficiency, but it does not guarantee a precise failover second. Two active endpoints during overlap consume capacity and may require shared sessions or data routing. Negative answers can block a newly created hostname even though authoritative configuration is correct. Monitor query failures, connection attempts to old addresses, TLS handshakes, request error rates, and data-write ownership by destination. A short TTL has limited value if the browser or proxy keeps one long-lived connection. Measure the actual cutover distribution rather than claiming all clients switched when a DNS console changed.
Failure trace
Lower a record from 3,600 seconds to 63 seconds and switch immediately. A resolver that cached the old 3,600-second answer may continue using it; keep the old service available. Query a nonexistent status hostname, then create it and observe a negative cached answer. Test both IPv4 and IPv6 records, including an old address left in one family. Remove the old certificate while some clients still connect there and watch the handshake fail. Simulate rollback after half the clients reached the new destination; both sides must preserve the same case permission and write-owner rule.
Verification
- TTL reduction precedes the switch by at least the previous cache window.
- Positive and negative answer caches are tested.
- Old and new destinations remain contract-compatible during overlap.
Practice drill
Plan a move for case API host 47 from region 29 to 47. Record a 3,600-second old TTL and a 63-second target TTL. Schedule the reduction, new hostname creation, certificate deployment, dual-endpoint checks, traffic switch, and old-endpoint drain. Run synthetic resolvers with old positive and negative answers and compare their results over time. Send reviewer 62 to both destinations and confirm current case authorization. Report the observed time of the last old-address request and the point at which rollback is no longer cheap.
Decision note
DNS changes guide new connections; safe cutover comes from overlapping compatible endpoints and measured traffic.
Common Mistakes
- Assuming a new low TTL changes answers already cached.
- Deleting the old endpoint when the DNS console shows the new address.
- Testing only one address family or resolver.
Related lessons
Network Transport and Domain Operations; TLS Certificate Rotation and HSTS Scope; HTTP/2, HTTP/3 Negotiation, and Fallback Testing; Early Data Replay and Safe Request Admission; First connection: separate name resolution, TLS, and HTTP; Multi-Region Web State and Recovery.
Apply and check
Build Project: permit domain cutover and transport recovery and review Web Development: network transport operations quiz.
