Introduction DNS cutover propagation delays extend migration downtime beyond the planned window. When DNS TTL is too high, some users continue reaching the old infrastructure for hours or days.

Symptoms - Some users reaching old infrastructure after DNS change - DNS propagation incomplete after expected TTL - Mixed traffic between old and new infrastructure - Health check failures from old DNS resolution - Users in specific regions affected longer

Common Causes - DNS TTL not reduced before cutover - ISP DNS servers ignoring TTL - Negative caching of NXDOMAIN responses - Multiple DNS records (A, AAAA, CNAME) with different TTLs - DNS change made during peak traffic

Step-by-Step Fix 1. **Check DNS propagation status': ```bash # Check from multiple locations dig @8.8.8.8 example.com A +short dig @1.1.1.1 example.com A +short dig @208.67.222.222 example.com A +short # Use online tools: dnschecker.org ```

  1. 1.**Reduce TTL before future cutovers':
  2. 2.```bash
  3. 3.# At least 24-48 hours before cutover
  4. 4.aws route53 change-resource-record-sets \
  5. 5.--hosted-zone-id <zone-id> \
  6. 6.--change-batch file://low-ttl.json
  7. 7.# Set TTL to 60 seconds
  8. 8.`
  9. 9.**Run old and new infrastructure in parallel':
  10. 10.Keep old infrastructure running until DNS propagation is complete.

Prevention - Reduce DNS TTL to 60 seconds at least 48 hours before cutover - Monitor DNS propagation from multiple global locations - Plan cutover during low-traffic periods - Keep old infrastructure running for at least 1 TTL period - Use DNS-based load balancing for gradual migration