Choosing DNS TTLs before a migration cutover
DNS Time-To-Live (TTL) values control how long resolvers cache your DNS records. During a network migration or IP address cutover, TTL becomes critical: too high and old IPs remain cached after you've moved; too low and you risk resolver load spikes. Choosing the right TTL strategy weeks before cutover is one of the highest-impact decisions you can make to ensure a smooth transition.
Why TTL matters during migration
When you change a DNS A record to point to a new IP address, not every client sees that change immediately. Recursive resolvers (operated by ISPs, enterprises, and public DNS services) cache your record for the duration you specified in the TTL field. If your TTL is 86400 seconds (24 hours) and you cut over at noon on Tuesday, some clients may still reach your old IP until Wednesday noon, causing service interruption or split-brain scenarios.
Conversely, a TTL of 30 seconds means resolvers re-query your authoritative nameserver every half-minute. This increases query load on your nameservers and reduces the benefit of caching, but it allows rapid failover and cutover without stale records persisting.
Pre-migration TTL reduction strategy
The standard approach is to lower your TTL well in advance of the cutover window, typically 1 to 2 weeks before. This gives the DNS ecosystem time to propagate the lower TTL value and trains resolvers to re-query more frequently. Then, on cutover day, you update the A record itself. Because resolvers are already checking every few minutes instead of every few hours, the new IP propagates rapidly.
- →Week 1 before cutover: Reduce TTL from 3600 or 86400 to 300-600 seconds (5-10 minutes)
- →Days 2-7: Monitor resolver query patterns; confirm caches are respecting the new TTL
- →Cutover day: Change the A record IP; new address propagates within one TTL cycle
- →Post-cutover: After 24-48 hours, raise TTL back to normal to reduce nameserver load
Practical TTL values for migration
- →300 seconds (5 min): Aggressive; high resolver query load, but fastest propagation. Use for critical cutover windows.
- →600 seconds (10 min): Balanced; most resolvers re-query within one business cycle. Recommended for most migrations.
- →1800 seconds (30 min): Conservative; still faster than standard, acceptable for low-risk moves.
- →3600 seconds (1 hour): Default for many zones; only use if cutover is staggered or low-impact.
- →86400 seconds (24 hours): Never use before cutover. This is your normal, post-migration value.
If you operate your own recursive resolver or control client-side DNS settings (common in enterprise environments), you can also manually flush caches on cutover day to accelerate the transition. However, public resolvers and ISP caches are outside your control, so TTL reduction is your primary lever.
Common mistakes to avoid
- →Lowering TTL only hours before cutover: Resolvers may not have fetched the new TTL yet; old records still cache for days.
- →Setting TTL to 0: Some resolvers ignore or reject zero; use 60-300 seconds instead.
- →Forgetting to raise TTL post-cutover: Sustained low TTLs waste nameserver resources and increase latency.
- →Changing multiple records at once: If cutover fails, you cannot easily roll back. Update one record per cutover window.
- →Ignoring secondary nameservers: Ensure all authoritative nameservers are updated and serving the new TTL before cutover.
Testing your DNS changes in a non-production zone or lab environment before cutover is essential. Use tools like dig or nslookup to verify that resolvers are respecting your new TTL, and confirm that your nameserver configuration is correct across all secondaries.