How to Lower DNS TTL Before Domain Migration

Problem/Symptom

High default TTLs lock recursive resolvers to legacy IPs, causing extended propagation windows and split-brain routing during domain migrations. Uncontrolled caching triggers 5xx errors, session loss, and email routing failures. Establish baseline values across all authoritative zones before initiating decay.

  • Extract full zone files via dig AXFR @ns1.provider.com domain.com or provider API endpoints.
  • Map A/CNAME/AAAA/MX records to current TTLs using CSV export for batch processing.
  • Identify negative caching (NXDOMAIN) TTLs that may persist post-migration.
  • Cross-reference CDN origin pull settings with DNS TTLs to prevent edge-cache desync.

Exact Execution/Config

Systematically decrease TTL values to 300s or 60s prior to cutover. Avoid triggering provider rate limits or recursive resolver rejection. Apply progressive decay models to maintain stability and prevent zone transfer failures.

  • Apply progressive TTL decay: 86400s → 3600s → 300s over 48–72 hours using TTL Optimization Strategies decay models.
  • Execute bulk updates via nsupdate or provider CLI with transactional batching.
  • Verify SOA refresh/retry/expire alignment to prevent secondary nameserver zone transfer failures.
  • Monitor recursive resolver acceptance rates using dig +stats to confirm TTL propagation.
nsupdate -v <<EOF
server ns1.provider.com
zone domain.com
update delete example.com. A
update add example.com. 300 A 203.0.113.5
send
EOF
record_type,hostname,current_ttl,new_ttl,ip_target,target_provider
A,www,86400,300,203.0.113.5,cloudflare
CNAME,mail,3600,300,mx.provider.com,aws
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Validation

Validate global DNS resolution consistency before modifying production routing. Synchronize staging environments to match authoritative targets and verify propagation across edge networks.

  • Query 12+ global resolvers using dig @resolver domain.com +short and aggregate results.
  • Compare staging vs production IPs via regex extraction: grep -Eo '([0-9]{1,3}\\.){3}[0-9]{1,3}' dig_output.txt | sort -u
  • Flush local resolver cache: ipconfig /flushdns (Windows) / sudo killall -HUP mDNSResponder (macOS) / sudo systemctl restart systemd-resolved (Linux).
  • Validate staging environment parity before executing authoritative record swaps.
  • Monitor curl -I -s -o /dev/null -w '%{http_code}' https://domain.com for immediate HTTP status validation.

Rollback/Emergency Steps

Execute immediate fallback procedures if post-migration latency, 5xx errors, or cache poisoning occur. Halt propagation drift instantly and restore authoritative routing to legacy infrastructure.

  • Revert zone file to pre-migration snapshot via git revert or provider backup API within 5 minutes.
  • Restore original TTLs immediately to stabilize recursive resolver caches.
  • Purge CDN edge cache using curl -X PURGE https://cdn.provider.com/* or equivalent API endpoint.
  • Run dig +trace domain.com to verify authoritative delegation loops and NS record consistency.
  • Reference DNS Configuration & Hosting Cutover for load balancer sync and TLS handshake verification during fallback routing.
# Rollback execution sequence
1. Halt all active DNS updates
2. aws route53 change-resource-record-sets --hosted-zone-id Z123456 --change-batch file://rollback.json
3. Verify TTL restoration via dig +noall +answer +ttlid domain.com
4. Trigger CDN full purge
5. Validate HTTP 200/301 responses across 10 global nodes

Common Pitfalls Checklist

  • Ignore registrar-level TTL floors (e.g., 300s minimum causing silent rejection).
  • Allow CDN edge caches to override DNS TTL with custom max-age directives.
  • Assume NXDOMAIN negative caching clears immediately after TTL reduction.
  • Trigger rate limits via bulk nsupdate or API calls, causing split-brain DNS.
  • Overlook stale OS-level resolver caches on load balancers bypassing TTL entirely.

FAQ

What is the minimum safe TTL before a domain migration cutover? 60–300 seconds. Values below 60s often trigger aggressive caching by recursive resolvers or hit provider rate limits, increasing propagation latency and risking split-brain routing.

How do I verify if a resolver is ignoring my lowered TTL? Run dig @resolver domain.com +noall +answer +ttlid and compare the returned TTL against your authoritative zone. Persistent high values indicate stale cache, proxy override, or resolver non-compliance with RFC 2181.

Does lowering TTL affect email deliverability during migration? Yes. MX record TTLs must be lowered identically to A records. Failure to do so causes mail routing failures if the primary mail server IP changes before propagation completes, resulting in deferred or bounced messages.

How do I handle CDN edge cache when DNS TTL is reduced to 60s? Configure the CDN to respect origin Cache-Control headers, enable stale-while-revalidate, and purge edge caches immediately after DNS propagation. This prevents 404/502 errors on the old IP while respecting the new authoritative routing.