A DNS cutover is only as fast as the cache entries you created before it. Once a resolver has stored a record with an 86400-second TTL, that resolver will serve the old value for up to a day no matter what you do afterwards — including setting the TTL to 60. Lowering a TTL does not shorten caches that already exist; it only shortens the ones created from that moment onwards. That single fact is the entire reason the lowering has to happen in advance.
Why does lowering the TTL have to happen first?
Think of it as two nested waits. When you lower the TTL from 86400 to 300, resolvers that already cached the record keep the old copy — and the old 86400 TTL — until it expires. Only when they re-query do they receive the 300-second version. So the short TTL is not in force everywhere until one full old TTL has elapsed. After that point, every resolver in the world is holding a copy that expires within five minutes, and your cutover becomes near-instant.
The four-phase timeline
- T minus 48 to 24 hours — lower. Set the TTL on every record you intend to change to 300 seconds (60 if your provider allows and the change is high-stakes). Change *only* the TTL; leave the values alone. Note the old TTL of each record so you know exactly how long to wait.
- T minus 0 — verify the short TTL is in force. Query several public resolvers and confirm they now return the short TTL, not the old one. If any resolver still reports a large TTL, the lowering has not fully taken hold and you should wait longer.
- T — cut over. Change the record values. Verify at your authoritative nameservers immediately, then watch public resolvers pick up the new value over the next TTL window.
- T plus 24 to 48 hours — raise. Once the new values are confirmed everywhere and the service is stable, put the TTL back to its normal value (3600 for most records, longer for stable infrastructure). Leaving everything at 300 forever is not harmful, but it costs query volume and removes the cache buffer that protects you when nameservers get slow.
# Step 2 check — does every resolver now report the short TTL?
for r in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
echo -n "$r "
dig @$r +noall +answer www.example.com A | head -1
doneA worked example
You are moving www.example.com from an old host at 203.0.113.10 to a new one at 198.51.100.25. The A record has been at 86400 seconds for years, and you want the swap to happen during a Tuesday 02:00 maintenance window.
| When | Action | What is true afterwards |
|---|---|---|
| Sunday 02:00 | Set the www A record TTL to 300. Value stays 203.0.113.10. | New cache entries carry a 300s TTL; old entries still carry up to 86400s. |
| Monday 02:00 | Do nothing. One full old TTL has now elapsed. | Every cached copy anywhere has been refreshed at least once and now expires in ≤5 minutes. |
| Monday 20:00 | Spot-check four public resolvers for the 300s TTL. | Confirmed ready. If any still show 86400, postpone the window. |
| Tuesday 02:00 | Change the A record value to 198.51.100.25. | Authoritative servers answer with the new IP immediately. |
| Tuesday 02:05 | Verify at the authoritative NS, then across public resolvers. | Traffic has effectively moved; stragglers are limited to the 300s window. |
| Tuesday 02:30 | Confirm the old host is receiving no meaningful traffic. | Safe to begin decommissioning — but keep it serving for at least a few more hours. |
| Wednesday 02:00 | Raise the TTL back to 3600. | Normal caching resumes; query load returns to baseline. |
Verify the cutover itself against many vantage points with the DNS Propagation Checker, and confirm the resulting address with the A Record Lookup.
What TTL should each record use normally?
| Record | Steady-state TTL | Pre-migration TTL | Why |
|---|---|---|---|
| A / AAAA for a web host | 3600 | 300 | Frequently changed; short enough to move quickly, long enough to absorb query load. |
| CNAME to a SaaS or CDN endpoint | 3600 | 300 | The provider changes the target behind the CNAME; you rarely change the CNAME itself. |
| MX | 3600–14400 | 300 | Sending servers cache MX answers, and a bad MX bounces mail rather than showing an error page. |
| TXT (SPF, DKIM, DMARC) | 3600 | 300 | Verifiers query these constantly; a stale SPF record causes authentication failures, not outages. |
| NS (in-zone) | 86400 | Leave alone | The delegation TTL that matters lives in the parent zone and is set by the registry, not by you. |
| SOA minimum (negative TTL) | 300–3600 | 300 | Governs how long "this name does not exist" is cached — lower it before creating new hostnames. |
| Domain-verification TXT | 3600 | n/a | One-off; the value is checked once and rarely changes. |
What about a nameserver migration?
Lowering record TTLs does not help when you are changing the delegation itself, because the TTL that governs the wait belongs to the parent zone and is set by the TLD registry. You cannot lower it. The mitigation is different: build the new zone completely, verify it record-for-record against the old one, and keep both zones live and identical through the entire parent-TTL window.
- Export the old zone and diff it against the new one before switching. Missing SPF, DKIM, and DMARC TXT records are the most common casualties — verify with the SPF Checker, DKIM Checker, and DMARC Checker.
- If the zone is DNSSEC-signed, coordinate the DS record at the registrar with the new provider's keys. A stale DS makes the whole zone fail validation with SERVFAIL — see SERVFAIL vs NXDOMAIN and test with the DNSSEC Checker. Many operators disable DNSSEC before the move and re-enable it after.
- Do not cancel the old DNS service the moment the new nameservers appear. Resolvers will keep hitting the old ones until the parent TTL expires, and an unanswered query is worse than an old answer.
- Confirm the delegation has actually moved with the NS Record Lookup and by querying the TLD servers with
dig +trace.
For the full mechanics of what is caching what, see How Long Does DNS Propagation Take?. If something still looks stuck after the cutover, work through Why Is My DNS Not Propagating?.