Why the TTL has to come down first
A resolver that caches a record may keep serving that copy for as long as the TTL it received. Lowering the TTL in your zone does not reach copies that are already cached: a resolver that fetched the record a minute before you lowered a one-day TTL can keep the old answer for almost a full day. So the TTL has to be lowered at least one old-TTL period before the change, and the planner counts backwards from your change time to find that moment.
After the switch, the short TTL limits how long anyone can keep seeing the old value. That window is what you have to cover by keeping the old server, IP, or platform binding alive.
How the timeline is calculated
| Step | Formula |
|---|---|
| Lower the TTL no later than | change time − current TTL − margin |
| Make the change | your planned time |
| Last moment a resolver may still return the old answer | change time + temporary TTL |
| Keep the old destination running until at least | change time + temporary TTL + margin |
| Raise the TTL again | after you have verified the new answer everywhere you check |
If you skip the first step, the worst case becomes change time + current TTL. The planner shows that number too, so you can decide whether the preparation is worth it for this record.
What a TTL cannot promise
- Resolvers apply their own limits. Some enforce a minimum or maximum cache time, so a 30-second TTL may be held longer.
- Clients cache too. Operating systems, browsers, and applications keep short caches of their own, and open connections keep talking to the old address until they close.
- Brand-new names are different. If a name did not exist and someone queried it, the "does not exist" answer is cached for the negative TTL taken from the zone's SOA record. Create new records before anyone looks them up; see negative caching.
- Proxied Cloudflare records are fixed. Proxied records use Auto, which Cloudflare currently sets to 300 seconds, and it cannot be edited. The planner switches to that value when you tick the box.
Checking progress during the change
Query the zone's authoritative server first: if it does not return the new value, nothing downstream will. Then compare public resolvers with the DNS lookup tool or from a terminal:
dig @ns1.example-dns.net app.example.com A +norec
dig @1.1.1.1 app.example.com A +noall +answer
dig @8.8.8.8 app.example.com A +noall +answerThe number in the second column of a resolver's answer is its remaining cache time. When it reaches zero the resolver asks again and should come back with the new value and a fresh TTL.