Lowering a DNS TTL at the moment of a migration does not shorten the lifetime of answers already cached with the old TTL. Those caches have not seen the new value yet. A reliable cutover plan lowers the TTL in advance, keeps both destinations working and verifies the authoritative change separately from cached answers.
TTL is a cache instruction measured in seconds. It is one part of a migration timeline, alongside negative caching, resolver behaviour, application caches, connection reuse and the health of the old and new services. Treating it as a universal propagation timer leads to premature shutdowns.
Start with the TTL that clients already received
The DNS TTL calculator converts durations and helps reason about timing. It does not query every resolver or predict when all clients will refresh. Before planning a change, inspect the actual authoritative record and record its current TTL.
Suppose the old TTL is 86,400 seconds, or one day. If you lower it to 300 seconds five minutes before changing the address, a resolver that cached the old answer just before the reduction can still retain it for nearly a day. The new five-minute value applies only after that resolver retrieves the updated answer.
Lower the TTL early enough for the old lifetime to expire before the intended cutover, allowing operational margin. Confirm that all authoritative nameservers serve the lower value. A control panel showing the new TTL is not proof that the public authoritative set has applied it consistently.
Build a worked cutover timeline
Imagine moving www.example from one server to another at 14:00 UTC on Friday. The existing TTL is 24 hours. You lower it to five minutes by 13:00 UTC on Thursday and verify the authoritative responses. That provides more than one old TTL before the planned address change.
At Friday's cutover, update the record and check each authoritative server. Then query representative recursive resolvers and watch real traffic on both destinations. Keep the old server able to handle requests during the transition. A resolver returning the new address is one observation, not evidence that every client has switched.
After the new service is stable and the intended transition window has passed, raise the TTL to a value suited to normal operation. Record the change and monitoring results. A permanently tiny TTL can increase query load and dependency on resolver availability without solving application-level caching.
| Time | Action | Evidence to retain |
|---|---|---|
| Thursday 13:00 UTC | Lower 86,400-second TTL to 300 | Authoritative responses from every nameserver |
| Before Friday 14:00 UTC | Validate the new service | Hostname, TLS and application checks |
| Friday 14:00 UTC | Change the address | Old and new values with timestamps |
| Transition window | Observe both destinations | Resolver samples and actual traffic |
| After stability review | Restore normal TTL | Final configuration and rollback decision |
Account for cached absence
If a name did not exist before the migration, some resolvers may have cached a negative answer. Adding a new A or AAAA record does not immediately replace that cached absence. Negative caching uses information from the zone's SOA response according to DNS rules.
For a planned new hostname, publish and validate it before announcing it to clients where possible. If a deployment checks the name too early and receives NXDOMAIN, that check itself can populate a cache with a negative result. Repeating the query every second does not force the resolver to discard it.
Distinguish NXDOMAIN, which concerns the queried name's nonexistence, from a response indicating that the name exists but lacks the requested record type. Preserve the response status and authority information. A vague report that DNS is empty loses the evidence needed to reason about caching.
Inspect every record in an alias path
A CNAME chain can involve several cached record sets with different TTLs. Lowering one link does not necessarily refresh all the others. Follow the chain to the final address and identify which record will change during the migration.
Also inspect A and AAAA records separately. Moving IPv4 traffic while leaving an old IPv6 destination can create a split experience in which some users reach the new service and others reach the old one. A test from an IPv4-only network can miss that problem.
Nameserver delegation changes have their own parent and child data. A zone-level TTL adjustment does not automatically shorten cached delegation information at the parent. For provider migrations, keep the old and new authoritative services consistent during the planned overlap and verify registrar-side changes explicitly.
Remember that DNS refresh is not connection refresh
An application may keep an established connection open after a DNS record changes. Connection pools, persistent browser connections and long-running processes can continue using the old destination without performing a new lookup. A short DNS TTL cannot force those connections to close.
Some applications also maintain their own DNS caches or use runtime-specific cache policies. If one service continues reaching the old address long after representative resolvers refresh, inspect that process's resolver and connection behaviour. Restarting everything immediately can conceal the cause and disrupt unrelated work.
Design the old service to drain connections gracefully where appropriate. If traffic writes data, define how both destinations remain consistent during overlap. DNS alone cannot coordinate database ownership or prevent split writes between two independently active systems.
Plan rollback as another cached change
Changing the record back does not instantly recall the new address from clients that already cached it. A rollback creates another transition with both values potentially in use. Keep the new destination able to return a controlled response while clients move back.
Set rollback criteria before cutover: which error rate, failed transaction or certificate problem triggers action, and who owns the decision. Preserve old configuration and certificates. A record value saved in a note is not enough if the old server has already been dismantled.
For stateful services, decide whether data written after cutover can be read safely after rollback. That problem can be harder than the DNS change itself. Test the application transition and recovery path before making the hostname switch the only remaining step.
Use resolver samples honestly
Querying several public resolvers helps identify inconsistent observations, but it is not a census of the internet. Each resolver has its own cache state and network path. Record the remaining TTL returned with an answer, because it helps explain whether the value was recently refreshed or is nearing expiry.
Separate authoritative correctness from recursive freshness in the incident note. If authoritative servers disagree, repair publication first. If they agree and recursive answers differ within expected cache windows, continued overlap may be the intended migration state rather than a new outage.
Use application monitoring to confirm the user's experience. DNS can return the new address while the new server presents the wrong certificate or serves an unhealthy application. Complete the check through TLS and the actual endpoint, using the requested hostname.
Frequently asked questions
Does a five-minute TTL mean everyone updates in five minutes?
No. Previously cached values can have a longer remaining lifetime, and applications may reuse connections or apply their own caching. The value describes a DNS record's cache lifetime when received. Plan around the old TTL and observe the actual transition rather than promising a universal deadline.
Can I flush every resolver remotely?
No general mechanism lets a domain operator clear every client's cache. Some resolver services offer limited cache-purge tools, but they do not cover all users or application caches. Correct the authoritative data and keep the migration overlap sufficient for the clients you support.
Why is the returned TTL decreasing?
A recursive resolver commonly reports the remaining lifetime of its cached answer. As time passes, that value decreases until refresh. A smaller returned TTL does not necessarily mean the authoritative configuration changed. Compare with an authoritative query when reviewing the configured value.
Will TTL zero disable all caching?
It expresses that the record should not be retained for ordinary reuse beyond the relevant transaction, but it does not control every application or connection layer. Extremely low values also increase dependency on fresh DNS lookups. Use a considered operational value instead of expecting zero to solve all migration timing.
Why does a new hostname still return NXDOMAIN?
The resolver may hold a negative answer obtained before the name was published, or the authoritative change may be incomplete. Check the authoritative servers, response status and negative-cache information. Adding the record does not automatically invalidate a previously cached absence.
Should I lower TTLs for every record in the zone?
Focus on the records and delegation paths involved in the change. A broad reduction can add unnecessary query load and obscure which values matter. Inventory aliases, IPv4 and IPv6 addresses, mail records or delegation data according to the migration's actual scope.
When can I shut down the old server?
Use the planned cache window, observed traffic, connection-draining behaviour and application consistency requirements together. The first successful query to the new address is too early. Preserve a practical recovery path until the transition has met the criteria your service needs.