What is DNS propagation and how do I migrate a website with zero downtime?
DNS propagation is the time for DNS record changes to spread across all global DNS resolvers. It typically completes in 1-4 hours though can take up to 48 hours. You can achieve near-instant propagation by lowering TTL before migration, keeping both servers live during transition, and verifying from multiple geographic locations.
DETAILED EXPLANATION:
DNS uses a distributed caching system. When you update an A record, your authoritative nameserver updates immediately. But ISP resolvers worldwide cache the old record until its TTL (Time to Live) expires. Only after expiry do they query for the new IP.
TTL values and their impact:
- 86400 (24 hours): Standard default. Changes take up to 24 hours globally.
- 3600 (1 hour): Good balance for most records.
- 300 (5 minutes): Pre-migration strategy. Near-instant effective propagation.
- 60 (1 minute): Active migration. High DNS query load on nameservers.
Why you pre-reduce TTL:
If current TTL is 86400 and you just changed it to 300, you still need to wait 86400 seconds for all cached copies to expire. That is why you change TTL 48 hours BEFORE migration.
WHEN TO USE:
- Migrating website from any host to Connect Quest
- Changing email provider (MX record update)
- Pointing subdomain to new service
- Any DNS record change requiring monitoring
STEP-BY-STEP - Zero-downtime migration to Connect Quest:
48 HOURS BEFORE:
1. Log into current DNS provider
2. Change A record TTL: yourdomain.com A -> [current IP] TTL 300
3. Also change www CNAME/A TTL to 300
4. Wait 48 hours (current 86400 TTL caches to expire everywhere)
MIGRATION DAY:
Step 1: Provision Connect Quest server at connectquest.co.in
Step 2: Deploy identical website on new server
Step 3: Test new server WITHOUT changing DNS (using hosts file):
On your local machine add: [new-server-ip] yourdomain.com
Browse yourdomain.com - should show new server content
Remove hosts file entry after confirming all pages work
Step 4: Export database from old server:
mysqldump -u root -p mydb > mydb_final.sql
Step 5: Import to new Connect Quest server:
mysql -u root -p mydb < mydb_final.sql
Step 6: Update DNS A record to new server IP (takes effect in ~5 min now with TTL 300)
Step 7: Keep OLD server running for 48 more hours
(Users with cached old DNS still reach old server - both serve same content)
Step 8: After 48 hours, verify propagation complete, then shut down old server
Step 9: Restore TTL to 3600 or 86400 once stable
CHECKING PROPAGATION:
Command line checks:
nslookup yourdomain.com 8.8.8.8 (Google DNS - USA)
nslookup yourdomain.com 1.1.1.1 (Cloudflare)
nslookup yourdomain.com 223.5.5.5 (AliDNS - Asia)
Check TTL remaining on cached record:
dig yourdomain.com A
yourdomain.com. 285 IN A 203.0.113.10
The 285 = seconds remaining in cache
Online global check: dnschecker.org/#A/yourdomain.com
Shows 50+ locations - green checkmarks when updated
REAL EXAMPLES:
Cloudflare nameservers: propagation typically under 5 minutes globally
Typical registrar nameservers (GoDaddy, Namecheap): 15-60 minutes
Slow/outdated ISP resolvers: up to 24-48 hours (rare but happens)
Timeline for a smooth migration:
Day 1, 9am: Reduce TTL to 300
Day 3, 9am: Start migration (48 hours elapsed)
Day 3, 9:05am: DNS updated (propagates in ~5 minutes with TTL 300)
Day 5, 9am: Old server safely decommissioned
FLOW:
User browser queries DNS:
-> Cached response (old IP): serve from old server (both servers online = no downtime)
-> Cache expired, queries authoritative: new Connect Quest IP returned
-> From this point: all requests to new server
KEY POINTS:
- Cloudflare proxy (orange cloud) propagates in seconds for any change
- Both servers must serve identical content during transition period
- Database-driven sites need final DB sync just before DNS cutover
- Connect Quest provides free migration assistance - call +91 2269711150
COMMON MISTAKES:
- Not reducing TTL 48 hours before change (stuck waiting full 86400 seconds)
- Shutting down old server immediately after DNS change (users with cached old DNS get errors)
- Testing propagation only from one location (may look complete but ISPs in other cities still cached)
QUICK FIX:
Propagation stuck for one ISP: Their resolver ignores TTL (rare). Nothing to do but wait.
Quick workaround: Tell affected users to change DNS on their device:
Windows: Use 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) instead of ISP DNS
DIFFICULTY: Intermediate
RELATED: Domain Registration, Web Hosting Migration, Connect Quest Hosting
DETAILED EXPLANATION:
DNS uses a distributed caching system. When you update an A record, your authoritative nameserver updates immediately. But ISP resolvers worldwide cache the old record until its TTL (Time to Live) expires. Only after expiry do they query for the new IP.
TTL values and their impact:
- 86400 (24 hours): Standard default. Changes take up to 24 hours globally.
- 3600 (1 hour): Good balance for most records.
- 300 (5 minutes): Pre-migration strategy. Near-instant effective propagation.
- 60 (1 minute): Active migration. High DNS query load on nameservers.
Why you pre-reduce TTL:
If current TTL is 86400 and you just changed it to 300, you still need to wait 86400 seconds for all cached copies to expire. That is why you change TTL 48 hours BEFORE migration.
WHEN TO USE:
- Migrating website from any host to Connect Quest
- Changing email provider (MX record update)
- Pointing subdomain to new service
- Any DNS record change requiring monitoring
STEP-BY-STEP - Zero-downtime migration to Connect Quest:
48 HOURS BEFORE:
1. Log into current DNS provider
2. Change A record TTL: yourdomain.com A -> [current IP] TTL 300
3. Also change www CNAME/A TTL to 300
4. Wait 48 hours (current 86400 TTL caches to expire everywhere)
MIGRATION DAY:
Step 1: Provision Connect Quest server at connectquest.co.in
Step 2: Deploy identical website on new server
Step 3: Test new server WITHOUT changing DNS (using hosts file):
On your local machine add: [new-server-ip] yourdomain.com
Browse yourdomain.com - should show new server content
Remove hosts file entry after confirming all pages work
Step 4: Export database from old server:
mysqldump -u root -p mydb > mydb_final.sql
Step 5: Import to new Connect Quest server:
mysql -u root -p mydb < mydb_final.sql
Step 6: Update DNS A record to new server IP (takes effect in ~5 min now with TTL 300)
Step 7: Keep OLD server running for 48 more hours
(Users with cached old DNS still reach old server - both serve same content)
Step 8: After 48 hours, verify propagation complete, then shut down old server
Step 9: Restore TTL to 3600 or 86400 once stable
CHECKING PROPAGATION:
Command line checks:
nslookup yourdomain.com 8.8.8.8 (Google DNS - USA)
nslookup yourdomain.com 1.1.1.1 (Cloudflare)
nslookup yourdomain.com 223.5.5.5 (AliDNS - Asia)
Check TTL remaining on cached record:
dig yourdomain.com A
yourdomain.com. 285 IN A 203.0.113.10
The 285 = seconds remaining in cache
Online global check: dnschecker.org/#A/yourdomain.com
Shows 50+ locations - green checkmarks when updated
REAL EXAMPLES:
Cloudflare nameservers: propagation typically under 5 minutes globally
Typical registrar nameservers (GoDaddy, Namecheap): 15-60 minutes
Slow/outdated ISP resolvers: up to 24-48 hours (rare but happens)
Timeline for a smooth migration:
Day 1, 9am: Reduce TTL to 300
Day 3, 9am: Start migration (48 hours elapsed)
Day 3, 9:05am: DNS updated (propagates in ~5 minutes with TTL 300)
Day 5, 9am: Old server safely decommissioned
FLOW:
User browser queries DNS:
-> Cached response (old IP): serve from old server (both servers online = no downtime)
-> Cache expired, queries authoritative: new Connect Quest IP returned
-> From this point: all requests to new server
KEY POINTS:
- Cloudflare proxy (orange cloud) propagates in seconds for any change
- Both servers must serve identical content during transition period
- Database-driven sites need final DB sync just before DNS cutover
- Connect Quest provides free migration assistance - call +91 2269711150
COMMON MISTAKES:
- Not reducing TTL 48 hours before change (stuck waiting full 86400 seconds)
- Shutting down old server immediately after DNS change (users with cached old DNS get errors)
- Testing propagation only from one location (may look complete but ISPs in other cities still cached)
QUICK FIX:
Propagation stuck for one ISP: Their resolver ignores TTL (rare). Nothing to do but wait.
Quick workaround: Tell affected users to change DNS on their device:
Windows: Use 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) instead of ISP DNS
DIFFICULTY: Intermediate
RELATED: Domain Registration, Web Hosting Migration, Connect Quest Hosting