DNS Propagation Complete Guide: How Long Does It Take & How to Speed It Up (2025)
You changed your DNS records 6 hours ago. The new IP is correct in your DNS dashboard. You’ve tested it yourself and everything works perfectly.
But half your users still see the old site.
Or maybe you’re planning a website migration tomorrow. Someone told you “DNS takes 24-72 hours to propagate.” But you need your site live in 2 hours, not 2 days.
You’re wondering if there’s any way to speed this up.
Or perhaps you deleted an old subdomain yesterday. Your DNS shows it’s gone. But when you test it, the subdomain still resolves to the old server.
DNS propagation is torturing you with its mysterious timeline.
Here’s the frustrating truth: Most advice about DNS propagation is outdated, vague, or just plain wrong. “Wait 24-72 hours” isn’t a strategy—it’s giving up. And worse, it’s often unnecessary.
DNS propagation isn’t magic, and it’s not as slow as everyone claims. Once you understand what’s actually happening (hint: nothing is “propagating”), why different servers update at different times (TTL is everything), and which strategies actually work to speed things up (lowering TTL 48 hours early), you can migrate websites in hours instead of days.
This guide reveals the truth about DNS propagation with real timelines, proven acceleration strategies, and step-by-step troubleshooting for every scenario. You’ll learn exactly how long propagation takes for different TTL values, how to reduce a 48-hour migration to 2 hours, why some users see changes while others don’t, and how to avoid the catastrophic email migration mistakes that lose messages forever.
By the end, you’ll control DNS propagation instead of waiting helplessly for it to finish.
Quick Answer: DNS Propagation Essentials
Don’t have time for 10,000 words? Here’s what you need to know:
- How long it takes: 5 minutes to 72 hours, depending entirely on your TTL (Time To Live) value
- What it actually is: NOT propagation—it’s DNS caches expiring based on TTL countdown timers
- Typical timeline: TTL 300s = 30min-2h; TTL 3600s = 2-6h; TTL 86400s = 24-48h
- How to speed it up: Lower TTL to 300s (5 min) 48 hours BEFORE making changes
- Biggest mistake: Changing DNS without lowering TTL first, causing 24-48 hour delays
- Email migration: NEVER delete old MX immediately—add new, wait, swap priorities, wait, then remove
- Check propagation: Use our DNS Lookup tool to test multiple servers globally
- Golden rule: Lower TTL → Make change → Wait for propagation → Raise TTL back
Still here? Let’s master DNS propagation.
What is DNS Propagation?
DNS propagation is the time between updating your DNS records and when those changes become visible globally to all internet users.
But here’s what most guides won’t tell you: DNS propagation doesn’t exist.
The DNS Propagation Myth
What people think happens:
You change DNS → Records "propagate" across internet → Eventually reaches everyone
What actually happens:
You change DNS on authoritative server → INSTANT update there
Cached copies expire based on TTL → Servers fetch new version
Different caches expire at different times → Appears like "propagation"
There is no propagation. There’s only cache expiration.
Think of it like this: You update your profile picture on social media. It appears instantly on your profile. But your friends who loaded your profile an hour ago still see the old picture in their browser cache. As their caches expire and they refresh, they see the new picture. Nothing “propagated”—caches just expired.
Real-World Example
You change your A record:
Before: example.com → 93.184.216.34 (Old Server)
After: example.com → 93.184.216.35 (New Server)
What happens immediately:
Your authoritative nameserver (ns1.cloudflare.com):
✅ Shows 93.184.216.35 INSTANTLY
Google DNS (8.8.8.8):
❌ Still serving 93.184.216.34 from cache (TTL not expired yet)
User's ISP DNS:
❌ Still serving 93.184.216.34 from cache
User's computer:
❌ Still has 93.184.216.34 cached in OS
What happens over time:
After 5 minutes:
Google DNS cache expires (if TTL was 300s)
→ Queries your authoritative NS
→ Gets 93.184.216.35
→ Caches new value
✅ Now serves 93.184.216.35
After 30 minutes:
Most major DNS resolvers refreshed
✅ 60-70% of users see new IP
After 2 hours:
Most ISP DNS caches expired
✅ 90%+ users see new IP
After 24 hours:
Even stubborn caches expired
✅ 99%+ users see new IP
Why DNS Propagation Exists
DNS propagation (cache expiration) exists for performance:
Without caching:
Every website visit:
1. Query root servers
2. Query TLD servers
3. Query authoritative servers
= 3 extra network roundtrips
= 100-200ms added latency PER PAGE LOAD
With caching:
First visit: Full DNS lookup (100-200ms)
Subsequent visits: Cached (0-5ms)
= Dramatically faster browsing
The tradeoff:
- Benefit: 95% faster DNS lookups
- Cost: Changes take time to reach everyone
Common Misconception
WRONG: “DNS changes spread across DNS servers globally”
RIGHT: “Cached copies expire based on TTL timers”
WRONG: “DNS propagation takes 24-72 hours”
RIGHT: “DNS propagation takes TTL × 1-2 for full global expiration”
WRONG: “There’s nothing you can do to speed it up”
RIGHT: “Lower TTL before changes = propagation in hours, not days”
Check your current DNS records and TTL values with our DNS Lookup tool to see exactly when your caches will expire.
How DNS Propagation Actually Works
Understanding the mechanism behind DNS “propagation” helps you control it.
The DNS Caching Hierarchy
When you change a DNS record, it must flow through multiple caching layers before reaching end users:
Layer 1: Authoritative Nameserver
└─ Your DNS provider (Cloudflare, Route 53, etc.)
└─ Updates INSTANTLY when you save changes
└─ Always has correct, current records
Layer 2: Recursive Resolvers
└─ Google DNS (8.8.8.8), Cloudflare (1.1.1.1), ISP DNS
└─ Cache records based on TTL
└─ Refresh when TTL expires
└─ Serve 99% of actual users
Layer 3: Local Router
└─ Your WiFi router
└─ May cache DNS for performance
└─ Refresh behavior varies by model
Layer 4: Operating System
└─ Windows, macOS, Linux built-in DNS cache
└─ Caches for performance
└─ Flush with commands (ipconfig /flushdns, etc.)
Layer 5: Browser
└─ Chrome, Firefox, Safari, Edge
└─ Each has its own DNS cache
└─ Typically caches 1-30 minutes
└─ Independent of OS cache
Each layer delays propagation as its cache expires independently.
Real-World Cache Expiration Flow
Example: You lower TTL to 300s (5 min) and change IP
Hour 0, Minute 0:
Authoritative NS: 93.184.216.35 (NEW) ✅
Google DNS: 93.184.216.34 (OLD, cached for 300s) ⏳
Your ISP: 93.184.216.34 (OLD, cached for 300s) ⏳
Your router: 93.184.216.34 (OLD, cached) ⏳
Your OS: 93.184.216.34 (OLD, cached) ⏳
Your browser: 93.184.216.34 (OLD, cached) ⏳
Hour 0, Minute 5:
Authoritative NS: 93.184.216.35 (NEW) ✅
Google DNS: 93.184.216.35 (NEW, refreshed!) ✅
Your ISP: 93.184.216.35 (NEW, refreshed!) ✅
Your router: 93.184.216.34 (OLD, not checked yet) ⏳
Your OS: 93.184.216.34 (OLD, not refreshed) ⏳
Your browser: 93.184.216.34 (OLD, not refreshed) ⏳
Hour 0, Minute 30:
ALL layers refreshed ✅
Everyone sees new IP: 93.184.216.35
With TTL 300s: Propagation in 30 minutes globally.
Same scenario with TTL 86400s (24 hours):
Hour 0:
Authoritative NS: Updated ✅
Everything else: Still cached for 24 hours ⏳
Hour 12:
Still waiting... ⏳
Hour 24:
Major DNS resolvers refresh ✅
50% of users see new IP
Hour 48:
Most caches expired ✅
95% of users see new IP
With TTL 86400s: Propagation takes 24-48 hours.
The Role of TTL (Time To Live)
TTL is the ONLY factor that controls propagation speed.
What TTL means:
TTL 300 = Cache this record for 300 seconds (5 minutes)
TTL 3600 = Cache this record for 3600 seconds (1 hour)
TTL 86400 = Cache this record for 86400 seconds (24 hours)
How TTL countdown works:
1. You set: example.com A 93.184.216.34 TTL 3600
2. DNS resolver queries your authoritative NS:
"What's example.com?"
Response: "93.184.216.34, cache for 3600 seconds"
3. Resolver caches with countdown timer:
93.184.216.34 (expires in 3600s)
93.184.216.34 (expires in 3599s)
93.184.216.34 (expires in 3598s)
...
4. After 3600 seconds:
Cache expired → Next query fetches fresh data
TTL value examples:
TTL 60 (1 minute):
Pros: Changes propagate in 1-5 minutes
Cons: Excessive DNS queries, higher costs
Use case: Active migration or testing
TTL 300 (5 minutes):
Pros: Fast propagation (30 min - 2 hours)
Cons: More DNS queries than normal
Use case: Before/during planned migrations
TTL 3600 (1 hour):
Pros: Balanced performance and flexibility
Cons: 2-6 hour propagation
Use case: Normal production operations
TTL 86400 (24 hours):
Pros: Minimal DNS queries, best performance
Cons: 24-48 hour propagation
Use case: Very stable, rarely-changing infrastructure
TTL is YOUR control knob for propagation speed.
Authoritative vs Cached Responses
How to tell if you’re seeing cached data:
dig example.com
;; flags: qr rd ra; QUERY: 1, ANSWER: 1
↑
Missing "aa" flag = NON-AUTHORITATIVE (cached)
dig @ns1.cloudflare.com example.com
;; flags: qr aa rd; QUERY: 1, ANSWER: 1
↑
"aa" flag = AUTHORITATIVE (direct from source)
Why this matters:
Cached response:
- May be outdated
- Reflects resolver's cache state
- What users actually see
- Used for propagation testing
Authoritative response:
- Always current
- Direct from your DNS provider
- What you configured
- Used for verification
Testing strategy:
# 1. Verify your change took effect (authoritative)
dig @ns1.cloudflare.com example.com
# Should show NEW value immediately
# 2. Check if propagated to users (cached/recursive)
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
# May show OLD value until TTL expires
When some users see changes and others don’t:
User A:
└─ Uses Google DNS (8.8.8.8)
└─ Google's cache already expired
└─ Sees NEW IP ✅
User B:
└─ Uses ISP DNS
└─ ISP cache still valid
└─ Sees OLD IP ❌
User C:
└─ Uses Cloudflare DNS (1.1.1.1)
└─ Cloudflare cache expired
└─ Sees NEW IP ✅
This is NORMAL during propagation. Each resolver’s cache expires independently based on when they last queried your authoritative nameserver.
Use our DNS Lookup tool to check multiple DNS servers simultaneously and see exactly which have updated.
DNS Propagation Timeline: What to Expect
Exact timelines for each propagation phase based on TTL values.
Immediate Phase (0-5 Minutes)
What happens:
- Your DNS change goes live on authoritative nameservers INSTANTLY
- No delay, no waiting
- Verifiable immediately
How to verify:
# Query your authoritative nameserver directly
dig @ns1.cloudflare.com example.com
# Should show NEW record immediately:
example.com. 300 IN A 93.184.216.35
↑
NEW IP shows instantly
What’s NOT updated yet:
- DNS resolver caches (Google, Cloudflare, ISPs)
- User’s router cache
- User’s computer cache
- User’s browser cache
Percentage propagated: 0% (except your authoritative NS)
What to do:
- Verify change succeeded on authoritative NS
- Document change timestamp
- Begin monitoring recursive resolvers
Early Phase (5-30 Minutes)
What happens:
- Major DNS resolvers (Google, Cloudflare, Quad9) refresh if TTL low
- High-traffic resolvers update quickly
- First users start seeing changes
Conditions required:
IF TTL = 300s (5 min):
- Google DNS refreshes in ~5-10 min
- Cloudflare DNS refreshes in ~5-10 min
- Quad9 refreshes in ~5-15 min
IF TTL = 3600s (1 hour):
- No major resolvers updated yet
- Still waiting for TTL to expire
IF TTL = 86400s (24 hours):
- No updates for 24 hours
- Everyone still sees old record
How to check:
# Check major DNS resolvers
dig @8.8.8.8 example.com # Google
dig @1.1.1.1 example.com # Cloudflare
dig @9.9.9.9 example.com # Quad9
# Look for NEW IP in responses
# If still showing old IP, TTL hasn't expired yet
Percentage propagated (TTL 300s): 20-40%
Percentage propagated (TTL 3600s): 0%
Percentage propagated (TTL 86400s): 0%
What to do:
- Monitor major DNS resolvers every 5-10 minutes
- Track which resolvers updated
- Test from your own connection
Mid Phase (30 Minutes - 4 Hours)
What happens:
- ISP DNS resolvers begin refreshing (if TTL allows)
- Geographic variations appear
- Most users in major markets see changes
- Smaller ISPs still cached
Conditions by TTL:
TTL 300s (5 min):
Hour 0.5 (30 min):
- Major resolvers: 100% updated
- Major ISPs: 60-80% updated
- Small ISPs: 30-50% updated
- Overall: 70% propagated ✅
Hour 2:
- Major resolvers: 100% updated
- Major ISPs: 95% updated
- Small ISPs: 80% updated
- Overall: 90-95% propagated ✅
TTL 3600s (1 hour):
Hour 1:
- Major resolvers starting to update
- Overall: 10-20% propagated
Hour 2:
- Major resolvers: 80% updated
- Major ISPs: 40% updated
- Overall: 50-60% propagated
Hour 4:
- Major resolvers: 100% updated
- Major ISPs: 80% updated
- Overall: 85% propagated ✅
TTL 86400s (24 hours):
Hour 4:
- Nothing updated yet
- Overall: 0% propagated
- Must wait ~20 more hours
How to check geographic propagation:
- WhatsMyDNS.net (tests 20+ global locations)
- DNSChecker.org (global propagation map)
- Our DNS Lookup tool (multiple servers)
Percentage propagated:
- TTL 300s: 70-95%
- TTL 3600s: 50-85%
- TTL 86400s: 0%
What to do:
- Continue monitoring every 30 minutes
- Test from different networks (WiFi, mobile data)
- Watch for user reports
Late Phase (4-24 Hours)
What happens:
- Slow-refreshing ISPs update
- Stubborn caches with aggressive policies expire
- Edge cases resolve
- Near-complete propagation
Conditions by TTL:
TTL 300s (5 min):
Hour 4:
- Overall: 98-99% propagated ✅✅
- Safe to consider complete
- Decommission old infrastructure after 24h
TTL 3600s (1 hour):
Hour 6:
- Overall: 90-95% propagated ✅
Hour 12:
- Overall: 95-98% propagated ✅
Hour 24:
- Overall: 99% propagated ✅✅
- Safe to consider complete
TTL 86400s (24 hours):
Hour 24:
- Major resolvers: Just starting to update
- Overall: 30-50% propagated
- Must wait 24 more hours
Percentage propagated:
- TTL 300s: 99%+ (essentially complete)
- TTL 3600s: 90-99%
- TTL 86400s: 30-50%
What to do:
- Verify near-100% propagation
- Keep both old and new infrastructure running
- Prepare to raise TTL back to normal
Final Phase (24-72 Hours)
What happens:
- Last holdouts with aggressive caching update
- Legacy systems finally expire cache
- Geographic edge cases resolve
- 100% propagation achieved
Conditions by TTL:
TTL 300s (5 min):
Hour 24-48:
- 99.9%+ propagated
- Only extreme edge cases remain
- Safe to decomission old infrastructure ✅
TTL 3600s (1 hour):
Hour 24-48:
- 99.5%+ propagated
- Safe to decomission old infrastructure ✅
TTL 86400s (24 hours):
Hour 48:
- 85-95% propagated
- Most users see new records
Hour 72:
- 98-99% propagated ✅
- Safe to decomission old infrastructure
Percentage propagated:
- TTL 300s: 99.9%
- TTL 3600s: 99.5%
- TTL 86400s: 98-99%
What to do:
- Raise TTL back to normal (300 → 3600)
- Decomission old infrastructure
- Document final timeline
- Close migration tickets
Factors That Affect Timeline
1. Original TTL Value (95% of timeline determination)
TTL 300s → 30 min - 4 hours
TTL 3600s → 2-24 hours
TTL 86400s → 24-72 hours
2. DNS Provider Infrastructure
Anycast DNS (Cloudflare, Route 53):
- Internal sync: Seconds
- Global availability: Minutes
- Fast ✅
Traditional DNS:
- Single location
- Updates: Minutes to hours
- Slower ❌
3. Geographic Distance
Near authoritative NS:
- Faster queries
- Earlier updates
- 30min ahead of remote regions
Far from authoritative NS:
- Slower queries
- Later updates
- May lag 30-60min
4. ISP Caching Policies
Major ISPs (Comcast, Verizon, AT&T):
- Respect TTL accurately
- Predictable timing
Small ISPs:
- May override TTL
- Can cache longer than specified
- Unpredictable timing
5. Time Since Last Query
Popular domain (example.com):
- Cached everywhere
- Must wait full TTL
- Everyone affects
New subdomain (new.example.com):
- Not cached anywhere
- First query fetches new record
- Propagates in minutes
6. Anycast vs Unicast Nameservers
Anycast (Cloudflare, AWS):
- 200+ global locations
- Users query nearest server
- Fast, consistent propagation
Unicast (traditional):
- 1-2 locations
- Everyone queries same server
- Slower, variable propagation
Comparison table:
| TTL Value | Time to 50% | Time to 90% | Time to 99% | Use Case |
|---|---|---|---|---|
| 60s (1min) | 5 min | 15 min | 1 hour | Active testing |
| 300s (5min) | 15 min | 1 hour | 4 hours | Planned migration |
| 3600s (1h) | 2 hours | 8 hours | 24 hours | Normal operations |
| 86400s (24h) | 24 hours | 48 hours | 72 hours | Stable infrastructure |
Key insight: TTL is 95% of the story. Everything else is minor variation.
Common DNS Propagation Scenarios
Real-world timelines for different types of DNS changes.
Scenario 1: Changing A Record (Website Migration)
Most common scenario: Moving website to new server
Change:
Before: example.com → 93.184.216.34 (Old Server)
After: example.com → 93.184.216.35 (New Server)
Timeline with TTL 300s (5 minutes):
Hour 0, Minute 0:
└─ Change made on authoritative NS ✅
└─ Propagation: 0%
Hour 0, Minute 10:
└─ Google DNS updated ✅
└─ Cloudflare DNS updated ✅
└─ Propagation: 30%
Hour 0, Minute 30:
└─ Major ISPs updated ✅
└─ Propagation: 70%
Hour 1:
└─ Most regional ISPs updated ✅
└─ Propagation: 85%
Hour 2:
└─ Slow ISPs updated ✅
└─ Propagation: 95%
Hour 4:
└─ Essentially complete ✅
└─ Propagation: 99%
Timeline with TTL 3600s (1 hour):
Hour 0:
└─ Change made ✅
└─ Propagation: 0%
Hour 1:
└─ First major DNS resolvers updating
└─ Propagation: 15%
Hour 2:
└─ Major DNS resolvers mostly updated
└─ Propagation: 50%
Hour 6:
└─ Most ISPs updated
└─ Propagation: 85%
Hour 12:
└─ Slow ISPs updating
└─ Propagation: 95%
Hour 24:
└─ Essentially complete ✅
└─ Propagation: 99%
Timeline with TTL 86400s (24 hours):
Hour 0-24:
└─ Waiting for TTL to expire
└─ Propagation: 0-5%
Hour 24:
└─ First major resolvers updating
└─ Propagation: 30%
Hour 36:
└─ Major DNS resolvers updated
└─ Propagation: 60%
Hour 48:
└─ Most ISPs updated
└─ Propagation: 90%
Hour 72:
└─ Essentially complete ✅
└─ Propagation: 99%
What users experience during propagation:
Mixed traffic period:
User visits example.com:
├─ ISP DNS cached old IP → Connects to old server
├─ Sees old website content
├─ May lose session if switches servers
Different user:
├─ ISP DNS cached new IP → Connects to new server
├─ Sees new website content
├─ Different experience than first user
Same user later:
├─ ISP cache expired, refreshed
├─ Now connects to new server
├─ May lose session from old server
Problems during mixed traffic:
- Session loss (user logged out unexpectedly)
- Shopping cart cleared (different servers)
- Form resubmission (submission on old server lost)
- Inconsistent content (old vs new)
Solutions:
1. Keep both servers running with identical content
- Old server: Keep online for TTL × 2
- New server: Fully operational
- Both serve same data
- Prevents user-visible issues
2. Share session data between servers
- Use Redis/Memcached for sessions
- NOT local file-based sessions
- Both servers access same session store
- Users maintain sessions across migration
3. Database replication during transition
- Old server and new server share database
- OR replicate database real-time
- Prevents data inconsistencies
4. Monitor traffic on both servers
- Track requests to old vs new
- Watch for declining old server traffic
- Decommission old server when zero traffic for 48h
Scenario 2: Changing MX Records (Email Migration)
Critical scenario: Lost emails are GONE FOREVER
Change:
Before: example.com MX 10 oldmail.example.com
After: example.com MX 10 newmail.example.com
Why email is different:
Website traffic:
- Users can retry if page doesn't load
- Temporary errors acceptable
- Eventually everyone sees new site
Email traffic:
- Sending server tries once (maybe 2-3 times)
- Failed emails often NOT retried
- Lost emails = permanent data loss
- CANNOT accept partial propagation
WRONG approach (causes email loss):
❌ Day 1: Delete old MX, add new MX
Problem: During propagation:
- 50% of DNS servers: New MX
- 50% of DNS servers: No MX (deleted old)
- Result: 50% of emails BOUNCE and are LOST
❌ Day 1: Change old MX to new MX
Problem: During propagation:
- Cached DNS: Points to old mail server
- Old server decomissioned
- Result: Emails to old server are LOST
CORRECT approach (zero email loss):
Phase 1: Add new MX with lower priority (higher number)
Day 0:
Add to DNS:
example.com MX 10 oldmail.example.com (primary)
example.com MX 20 newmail.example.com (backup) ← NEW
Both servers receiving email:
- Sending servers try priority 10 first (old server)
- If fails, try priority 20 (new server)
- Zero email loss
Phase 2: Wait for full propagation (48 hours)
Day 2:
Verify both MX records propagated globally:
dig @8.8.8.8 example.com MX
dig @1.1.1.1 example.com MX
dig @9.9.9.9 example.com MX
All should show BOTH MX records ✅
Phase 3: Swap priorities
Day 2:
Change priorities:
example.com MX 20 oldmail.example.com (backup)
example.com MX 10 newmail.example.com (primary) ← Now primary
New server now receives most email
Old server receives only if new server fails
Phase 4: Wait again (48 hours)
Day 4:
Wait for priority swap to propagate globally
Monitor old mail server:
- Email volume should drop to nearly zero
- Only cached DNS sends to old server
- Old server forwards to new server (ideally)
Phase 5: Remove old MX
Day 6:
Remove old MX entirely:
example.com MX 10 newmail.example.com (only)
Old MX deleted, but safe because:
- New MX propagated for 4+ days
- 99.9% of DNS caches updated
- Old server still online (safety net)
Phase 6: Decommission old server (final)
Day 13 (one week after old MX removal):
Verify zero traffic to old mail server
Check logs: No incoming connections
Safe to decomission old server ✅
Total timeline: 2 weeks for zero-loss email migration
Timeline considerations:
TTL 3600s (1 hour) - Recommended for email:
Phase 1: Add new MX → Wait 48h
Phase 2: Swap priorities → Wait 48h
Phase 3: Remove old MX → Wait 7 days
Phase 4: Decommission old server
Total: ~11 days
TTL 300s (5 min) - Faster but risky for email:
Phase 1: Add new MX → Wait 12h
Phase 2: Swap priorities → Wait 12h
Phase 3: Remove old MX → Wait 48h
Phase 4: Decommission old server
Total: ~4 days
Risky: Shorter windows increase email loss risk
Critical email migration checklist:
☐ Never delete old MX immediately
☐ Always add new MX as BACKUP first (higher priority number)
☐ Wait FULL propagation before swapping
☐ Swap priorities, don't delete old
☐ Wait FULL propagation after swap
☐ Monitor old server for zero traffic
☐ Keep old server online 7+ days after removal
☐ Forward from old to new server during transition
☐ Update SPF record to include both servers
☐ Test email delivery throughout migration
Additional email considerations:
Update SPF record:
Before:
example.com TXT "v=spf1 ip4:93.184.216.34 ~all"
↑ old mail server
During migration:
example.com TXT "v=spf1 ip4:93.184.216.34 ip4:93.184.216.40 ~all"
↑ old ↑ new
After migration:
example.com TXT "v=spf1 ip4:93.184.216.40 ~all"
↑ new mail server only
Update DKIM records:
Add new DKIM selector for new server:
newserver._domainkey.example.com TXT "v=DKIM1; k=rsa; p=..."
Keep old DKIM active during transition
Remove old DKIM after 30 days
Monitor both servers:
# Watch old server logs
tail -f /var/log/mail.log
# Watch new server logs
tail -f /var/log/mail.log
# Track email volume
# Old server: Should decline to zero
# New server: Should increase to full volume
Scenario 3: Changing Nameservers
Longest propagation scenario: Registry-level change
Change:
Before: Nameservers at old DNS provider
ns1.olddns.com
ns2.olddns.com
After: Nameservers at new DNS provider
ns1.cloudflare.com
ns2.cloudflare.com
Why nameserver changes are special:
Normal DNS change:
You → Your authoritative NS → DNS resolvers → Users
Nameserver change:
You → Registrar → Registry → TLD servers → DNS resolvers → Users
↑ ↑ ↑
Extra layers = Extra delay
Timeline breakdown:
Hour 0: Make change at registrar
Log into domain registrar (GoDaddy, Namecheap, etc.)
Change nameservers:
Old: ns1.olddns.com
New: ns1.cloudflare.com
Save changes
Hour 0-2: Registrar processes and submits to registry
Registrar queues update
Registrar submits to registry (.com, .org, etc.)
Registry processes update
Status: Waiting
Check: whois example.com
May still show old nameservers
Hour 2-6: Registry updates TLD servers
Registry updates authoritative TLD servers
.com servers get new nameserver info
TLD updates propagate to global .com servers
Status: Registry level propagating
Check: dig example.com NS @a.gtld-servers.net
Should show new nameservers after Hour 6
Hour 6-12: TLD servers propagate globally
All .com TLD servers now have new NS records
DNS resolvers begin querying TLD servers
TLD servers respond with NEW nameservers
Status: TLD propagation complete
Check: dig example.com NS
Should show new nameservers
Hour 12+: DNS resolvers cache new nameservers
Recursive resolvers (Google, Cloudflare, ISPs) cache new NS
Resolvers query NEW nameservers for DNS records
DNS propagation begins from new authoritative NS
Status: Resolver propagation in progress
Check: dig @8.8.8.8 example.com
Should resolve via new nameservers
Hour 24-48: Full propagation complete
All major resolvers updated
All ISPs updated
Users globally see new nameservers
Status: Complete ✅
Percentage: 95-99% propagated
Hour 48-72: Final stragglers update
Last stubborn caches expire
Edge cases resolve
100% propagation
Status: Fully complete ✅
Percentage: 99.9% propagated
Total timeline: 24-72 hours (CANNOT be sped up at registry level)
Critical pre-migration checklist:
☐ Set up NEW nameservers COMPLETELY before switching
- Copy ALL DNS records to new provider
- Verify every record works on new NS:
dig @ns1.cloudflare.com example.com A ✅
dig @ns1.cloudflare.com www.example.com A ✅
dig @ns1.cloudflare.com example.com MX ✅
dig @ns1.cloudflare.com mail.example.com A ✅
☐ Lower TTL on OLD nameservers 48h before switch
- Lower all record TTLs to 300s
- Wait 48 hours for old TTL to expire
- Ensures fast propagation AFTER nameserver switch
☐ Verify both old and new NS serve identical records
- dig @ns1.olddns.com example.com
- dig @ns1.cloudflare.com example.com
- Both should return SAME data
☐ Document all subdomains and DNS records
- Export zone file from old provider
- Import to new provider
- Manually verify each record
☐ Keep old nameservers online for 7+ days
- Don't decommission old DNS immediately
- Some resolvers may still query old NS
- Gradual transition prevents outages
Diagnosis during nameserver migration:
# 1. Check what registrar shows
whois example.com | grep "Name Server"
# Should show new nameservers after 1-6 hours
# 2. Check what TLD servers say
dig example.com NS @a.gtld-servers.net
dig example.com NS @b.gtld-servers.net
# Should show new nameservers after 6-12 hours
# 3. Check what resolvers cached
dig example.com NS @8.8.8.8
dig example.com NS @1.1.1.1
# Should show new nameservers after 12-24 hours
# 4. Verify new nameservers work
dig @ns1.cloudflare.com example.com A
# Should return correct IP immediately
Common nameserver migration issues:
Problem: Registrar save button didn't work
Solution: Log back in and verify nameservers
Re-save if needed
Check confirmation email from registrar
Problem: 48+ hours, still showing old nameservers
Solution: Contact registrar support
Provide evidence from whois
Request manual push to registry
Problem: Records missing on new nameservers
Solution: Copy all records to new provider
Verify each record individually
Test with dig @new-ns before switching
Problem: Old nameservers decommissioned too early
Solution: Keep old NS online 7 days minimum
Monitor traffic to old NS
Decommission only after zero queries for 48h
Scenario 4: Adding New Subdomain
Fastest propagation scenario: No cache to expire
Change:
Add new: api.example.com → 93.184.216.40
Why new subdomains propagate instantly:
Existing subdomain (www.example.com):
- Already cached everywhere
- Must wait for TTL to expire
- Then resolvers fetch new value
- Slow (TTL-dependent)
NEW subdomain (api.example.com):
- Never cached anywhere (doesn't exist yet)
- First query: Resolver asks authoritative NS
- Authoritative NS returns new record
- Cached immediately
- Fast (minutes)
Timeline:
Hour 0, Minute 0:
Add DNS record:
api.example.com A 93.184.216.40 TTL 3600
Change saved on authoritative NS ✅
Hour 0, Minute 1:
Test immediately:
dig @ns1.cloudflare.com api.example.com
Result: 93.184.216.40 ✅
Works on authoritative NS instantly
Hour 0, Minute 5:
Test from Google DNS:
dig @8.8.8.8 api.example.com
First query ever for this subdomain:
- Google DNS doesn't have it cached
- Queries authoritative NS
- Gets 93.184.216.40
- Caches for 3600s
- Returns to user
Result: Works! ✅
Hour 0, Minute 10:
Users globally can access api.example.com
Any resolver that queries gets instant response
Cached immediately after first query
Percentage propagated: 90%+
(Only needs one query to "propagate" to that resolver)
Hour 0, Minute 30:
Essentially 100% available globally
Anyone who queries gets correct answer
No old cache to fight
Percentage propagated: 99%+
Why it’s fast:
No cache expiration needed!
Just cache population on first query.
Use cases for new subdomains:
✅ Add api.example.com for new API
✅ Add staging.example.com for staging environment
✅ Add cdn.example.com for CDN endpoint
✅ Add shop.example.com for new e-commerce section
All propagate in minutes, not hours/days
Best practices:
☐ Set reasonable TTL (3600s) from the start
☐ Test on authoritative NS first
☐ Test from major DNS resolvers after 5 min
☐ No need to lower TTL beforehand (no cache exists)
☐ Can go live immediately after verifying
Scenario 5: Deleting DNS Record
Trickiest scenario: Negative caching complicates deletion
Change:
Delete: old.example.com (was 93.184.216.50)
Why deletions are complicated:
Normal propagation:
1. Old value cached
2. TTL expires
3. Resolver fetches NEW value
4. New value cached
5. Everyone sees new value ✅
Deletion propagation:
1. Old value cached
2. TTL expires
3. Resolver queries authoritative NS
4. Authoritative NS: "NXDOMAIN (doesn't exist)"
5. NXDOMAIN response ALSO gets cached
6. Negative cache TTL applies (SOA minimum)
7. Eventually everyone sees NXDOMAIN ✅
Extra step: Negative caching
Timeline:
Hour 0:
Delete DNS record:
old.example.com A 93.184.216.50 TTL 86400
↑
Was cached for 24 hours
Status: Deleted on authoritative NS ✅
Hour 0, Minute 1:
Test on authoritative NS:
dig @ns1.cloudflare.com old.example.com
;; status: NXDOMAIN
(Record doesn't exist) ✅
Works on authoritative NS
Hour 0-24:
Test from Google DNS:
dig @8.8.8.8 old.example.com
;; ANSWER SECTION:
old.example.com. 86400 IN A 93.184.216.50
↑
Still cached! TTL hasn't expired yet
Status: NOT deleted for users yet ❌
Hour 24:
Google DNS cache expires (TTL 86400s = 24h)
Queries authoritative NS
Gets: NXDOMAIN
Google DNS caches NXDOMAIN response
Negative cache TTL: 3600s (usually 1 hour, from SOA)
dig @8.8.8.8 old.example.com
;; status: NXDOMAIN ✅
NOW deleted from Google DNS perspective
Hour 24-48:
Other resolvers' caches expire
Each queries authoritative NS
Each gets NXDOMAIN
Each caches NXDOMAIN
Gradually everyone sees deletion
Hour 48+:
All caches expired
Everyone sees NXDOMAIN
Status: Fully deleted globally ✅
Total deletion time: Original TTL + Negative cache TTL
Example:
Original TTL: 86400s (24 hours)
Negative TTL: 3600s (1 hour, from SOA)
Total: 25 hours minimum
Gotcha with negative caching:
Scenario:
1. You add subdomain: new.example.com
2. User typos: nwe.example.com
3. DNS returns NXDOMAIN (doesn't exist)
4. NXDOMAIN cached for 1 hour
5. You realize typo, add: nwe.example.com
6. User tries again 10 minutes later
7. Still gets NXDOMAIN (negative cache)
8. Must wait full negative TTL to expire
Negative cache pollution!
Solutions for faster deletion:
☐ Lower TTL before deletion (same as normal changes)
- 48h before: Lower TTL to 300s
- Day of: Delete record
- Deletion propagates in 30 min - 2 hours
☐ Check SOA record for negative cache TTL
dig example.com SOA
Look at MINIMUM field (last number)
This is negative cache duration
☐ Plan deletions well in advance
Don't delete then immediately re-add
Wait full propagation before re-adding
☐ Communicate deletion timeline to users
"old.example.com decommissioning in 48h"
Users update bookmarks/configs in advance
Negative cache TTL from SOA:
dig example.com SOA
;; ANSWER SECTION:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2025111601 ; Serial
7200 ; Refresh
3600 ; Retry
1209600 ; Expire
3600 ; Minimum (negative cache TTL)
↑
Negative responses cached 1 hour
How to Check DNS Propagation Status
Multiple methods to monitor propagation progress in real-time.
Method 1: Online Propagation Checkers
WhatsMyDNS.net (Recommended for quick visual overview)
Features:
- Tests from 20+ global locations simultaneously
- Real-time results (no waiting)
- Color-coded map (green = updated, red = old)
- Supports A, AAAA, MX, CNAME, TXT, NS records
- Free, no registration
How to use:
1. Visit: whatsmydns.net
2. Enter domain: example.com
3. Select record type: A
4. Click "Search"
5. View results from 20+ locations globally
Green checkmark: Shows NEW value (propagated ✅)
Red X: Shows OLD value (not propagated yet ❌)
Propagation percentage visible at glance
Best for:
- Quick visual propagation status
- Global geographic testing
- Sharing status with non-technical team
- Monitoring during migration window
DNSChecker.org (Detailed propagation tracking)
Features:
- Tests from 30+ global locations
- Shows propagation percentage
- Historical tracking
- Multiple record types
- TTL values displayed
How to use:
1. Visit: dnschecker.org
2. Enter domain: example.com
3. Select record type
4. Click "Search"
5. See detailed location-by-location results
Propagation %: 23/30 servers updated (76%)
Best for:
- Detailed propagation metrics
- Tracking propagation progress over time
- Identifying stuck regions
Our DNS Lookup Tool (Best for technical users)
Features:
- Check multiple DNS servers simultaneously
- Compare authoritative vs recursive resolvers
- See TTL countdown values
- Test specific nameservers
- Export results for documentation
- No ads, fast, mobile-friendly
How to use:
1. Visit: orbit2x.com/lookup
2. Enter domain: example.com
3. Select record types (A, MX, TXT, etc.)
4. View results from:
- Your authoritative nameservers
- Google DNS (8.8.8.8)
- Cloudflare DNS (1.1.1.1)
- Quad9 (9.9.9.9)
- OpenDNS
- Your current DNS
5. See which servers updated
6. Monitor TTL countdown
7. Track propagation progress
Best for:
- Technical troubleshooting
- Comparing authoritative vs cached
- Monitoring specific DNS servers
- Verifying TTL values
- Developer workflows
Method 2: Command-Line Testing
Check specific DNS servers manually:
# Test Google DNS (used by millions)
dig @8.8.8.8 example.com
# Test Cloudflare DNS (privacy-focused)
dig @1.1.1.1 example.com
# Test Quad9 (security-focused)
dig @9.9.9.9 example.com
# Test OpenDNS
dig @208.67.222.222 example.com
# Test your ISP's DNS (default)
dig example.com
# Test authoritative NS (always current)
dig @ns1.cloudflare.com example.com
Automated propagation checker script:
#!/bin/bash
# check_propagation.sh
# Checks DNS propagation across major resolvers
DOMAIN="example.com"
NEW_IP="93.184.216.35"
DNS_SERVERS=("8.8.8.8" "1.1.1.1" "9.9.9.9" "208.67.222.222")
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo "DNS Propagation Check: $DOMAIN"
echo "Expected IP: $NEW_IP"
echo "Time: $(date '+%Y-%m-%d %H:%M:%S')"
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
echo ""
updated=0
total=${#DNS_SERVERS[@]}
for server in "${DNS_SERVERS[@]}"; do
current_ip=$(dig @$server +short $DOMAIN | head -n1)
# Get DNS provider name
case $server in
"8.8.8.8") name="Google DNS " ;;
"1.1.1.1") name="Cloudflare DNS " ;;
"9.9.9.9") name="Quad9 DNS " ;;
"208.67.222.222") name="OpenDNS " ;;
esac
if [ "$current_ip" == "$NEW_IP" ]; then
echo "✅ $name ($server): $current_ip (UPDATED)"
((updated++))
elif [ -z "$current_ip" ]; then
echo "❌ $name ($server): NO RESPONSE"
else
echo "❌ $name ($server): $current_ip (still old)"
fi
done
echo ""
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
percentage=$((updated * 100 / total))
echo "Propagation Status: $updated/$total servers ($percentage%)"
if [ $percentage -eq 100 ]; then
echo "Status: ✅ FULLY PROPAGATED!"
elif [ $percentage -ge 75 ]; then
echo "Status: ⏳ Almost there... ($percentage%)"
elif [ $percentage -ge 50 ]; then
echo "Status: ⏳ In progress... ($percentage%)"
elif [ $percentage -ge 25 ]; then
echo "Status: ⏳ Just starting... ($percentage%)"
else
echo "Status: ⏳ Not propagated yet ($percentage%)"
fi
echo ""
if [ $percentage -ne 100 ]; then
echo "💡 Check again in 30 minutes"
fi
echo "━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━"
Usage:
chmod +x check_propagation.sh
./check_propagation.sh
Output:
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
DNS Propagation Check: example.com
Expected IP: 93.184.216.35
Time: 2025-11-16 14:30:00
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
✅ Google DNS (8.8.8.8): 93.184.216.35 (UPDATED)
✅ Cloudflare DNS (1.1.1.1): 93.184.216.35 (UPDATED)
❌ Quad9 DNS (9.9.9.9): 93.184.216.34 (still old)
❌ OpenDNS (208.67.222.222): 93.184.216.34 (still old)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Propagation Status: 2/4 servers (50%)
Status: ⏳ In progress... (50%)
💡 Check again in 30 minutes
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Advanced: Monitor multiple record types:
#!/bin/bash
# check_all_records.sh
DOMAIN="example.com"
echo "Checking all DNS records for $DOMAIN"
echo ""
echo "A Records:"
dig @8.8.8.8 $DOMAIN A +short
echo ""
echo "MX Records:"
dig @8.8.8.8 $DOMAIN MX +short
echo ""
echo "TXT Records:"
dig @8.8.8.8 $DOMAIN TXT +short
echo ""
echo "NS Records:"
dig @8.8.8.8 $DOMAIN NS +short
echo ""
echo "TTL Values:"
dig @8.8.8.8 $DOMAIN | grep -A1 "ANSWER SECTION"
Method 3: Testing from Different Networks
Why testing multiple networks matters:
Your office WiFi:
└─ Uses corporate DNS
└─ May have custom caching policies
└─ Might see old records longer
Mobile data (4G/5G):
└─ Uses carrier DNS
└─ Different caching than WiFi
└─ Independent view of propagation
VPN to different country:
└─ Uses VPN provider's DNS
└─ Tests geographic propagation
└─ Verifies global availability
Friend's network:
└─ Different ISP
└─ Different DNS resolvers
└─ Independent propagation status
Testing strategy:
1. Test from your current network:
dig example.com
# Uses your default DNS (ISP or custom)
2. Test from mobile data:
# Disconnect WiFi
# Use mobile hotspot
# Connect laptop to mobile hotspot
dig example.com
# Different DNS = different cache state
3. Test via VPN:
# Connect to VPN (different country)
dig example.com
# VPN DNS may show different results
# Helps verify geographic propagation
4. Test from friend’s network:
# Visit friend's house/office
# Connect to their WiFi
dig example.com
# Different ISP DNS = different status
5. Test from public WiFi:
# Coffee shop, library, airport
dig example.com
# Yet another DNS resolver
# More data points
Interpreting mixed results:
Home WiFi: 93.184.216.34 (old)
Mobile data: 93.184.216.35 (new)
VPN (US): 93.184.216.35 (new)
Friend's WiFi: 93.184.216.34 (old)
Analysis:
- Propagation in progress
- ~50% propagated
- Major DNS (mobile carriers, VPN) updated
- Some ISP DNS still cached
- Normal! Wait 1-4 more hours
Method 4: Browser-Based Testing
Using browser developer tools:
Chrome DevTools:
1. Open DevTools (F12)
2. Go to Network tab
3. Clear network log (trash icon)
4. Load your website: example.com
5. Click the first request (document)
6. Look at "Headers" tab
7. Find "Remote Address"
Remote Address: 93.184.216.35:443
↑
This is the IP your browser connected to
Verify it matches your NEW IP
Alternative method:
1. DevTools → Network tab
2. Load page
3. Look at "Name" column for first request
4. Hover over it
5. Tooltip shows IP address
Incognito/Private mode benefits:
Normal browser window:
- Uses browser DNS cache
- Uses browser HTTP cache
- May show old content even if DNS updated
Incognito window:
- Fresh browser session
- No browser cache
- Still uses OS/router DNS cache
- Better for testing
Testing in incognito:
1. Open incognito window (Ctrl+Shift+N)
2. Visit your site
3. Check DevTools → Network → Remote Address
4. Should show current DNS resolution
Clearing browser DNS cache:
Chrome:
1. Visit: chrome://net-internals/#dns
2. Click "Clear host cache"
3. Visit: chrome://net-internals/#sockets
4. Click "Flush socket pools"
5. Restart Chrome
6. Test again
Firefox:
1. Visit: about:networking#dns
2. Click "Clear DNS Cache"
3. Restart Firefox
4. Test again
Safari:
1. Develop menu → Empty Caches
2. Or quit and reopen Safari
3. Test again
Edge:
1. Visit: edge://net-internals/#dns
2. Click "Clear host cache"
3. Restart Edge
4. Test again
Limitation: Browser cache only affects YOU. Doesn’t help other users or show true propagation status.
Method 5: Monitoring Tools and Services
UptimeRobot (Free monitoring service)
Features:
- Monitors DNS from multiple locations
- Alerts when DNS changes detected
- Tracks propagation automatically
- Free tier: 50 monitors
Setup:
1. Sign up: uptimerobot.com
2. Add monitor:
Type: Keyword
URL: http://example.com
Keyword: (unique text on new site)
3. UptimeRobot checks every 5 minutes
4. Alerts when keyword found (= DNS propagated)
Pingdom (Premium monitoring)
Features:
- Real user monitoring
- DNS resolution tracking
- Performance metrics
- Geographic distribution
- $10/month
DNSPerf (DNS benchmarking)
Features:
- Continuous DNS monitoring
- Response time tracking
- Propagation tracking
- Historical data
- Free tier available
Custom monitoring script with cron:
#!/bin/bash
# /usr/local/bin/dns_monitor.sh
# Monitor DNS during migration
DOMAIN="example.com"
EXPECTED_IP="93.184.216.35"
LOG_FILE="/var/log/dns_propagation.log"
ALERT_EMAIL="admin@example.com"
# Get current IP from Google DNS
CURRENT_IP=$(dig +short @8.8.8.8 $DOMAIN | head -n1)
# Timestamp
TIMESTAMP=$(date '+%Y-%m-%d %H:%M:%S')
# Log result
echo "$TIMESTAMP - Google DNS: $CURRENT_IP" >> $LOG_FILE
# Check if propagated
if [ "$CURRENT_IP" == "$EXPECTED_IP" ]; then
echo "$TIMESTAMP - ✅ PROPAGATED to Google DNS" >> $LOG_FILE
# Send success notification
echo "DNS propagation complete for $DOMAIN" | \
mail -s "✅ DNS Propagation Success" $ALERT_EMAIL
# Stop monitoring (remove from cron)
# Comment out or remove cron job
else
echo "$TIMESTAMP - ⏳ Still waiting... (current: $CURRENT_IP)" >> $LOG_FILE
fi
# Check all major DNS every hour
if [ $(date +%M) -eq 0 ]; then
echo "$TIMESTAMP - Hourly full check:" >> $LOG_FILE
for server in 8.8.8.8 1.1.1.1 9.9.9.9; do
ip=$(dig +short @$server $DOMAIN | head -n1)
echo " $server: $ip" >> $LOG_FILE
done
fi
Setup cron (run every 5 minutes during migration):
# Edit crontab
crontab -e
# Add this line:
*/5 * * * * /usr/local/bin/dns_monitor.sh
# Save and exit
# Script runs every 5 minutes
# Logs to /var/log/dns_propagation.log
# Emails when propagation complete
View log:
tail -f /var/log/dns_propagation.log
Example log output:
2025-11-16 10:00:00 - Google DNS: 93.184.216.34
2025-11-16 10:05:00 - Google DNS: 93.184.216.34
2025-11-16 10:10:00 - Google DNS: 93.184.216.35
2025-11-16 10:10:00 - ✅ PROPAGATED to Google DNS
Use our DNS Lookup tool for instant propagation checking without setting up scripts or monitoring services.
How to Speed Up DNS Propagation
Seven proven strategies to reduce propagation time from days to hours.
Strategy 1: Lower TTL Before Making Changes (BEST PRACTICE)
The golden rule of DNS migrations:
Lower TTL 48 hours BEFORE making changes, not after.
Why this works:
Scenario A: Change DNS with high TTL (SLOW)
Hour 0: Change A record, TTL 86400s (24h)
Hour 24: Caches start expiring
Hour 48: 90% propagated
Result: 48-hour propagation ❌
Scenario B: Lower TTL first (FAST)
Hour -48: Lower TTL to 300s
Hour -24: Wait for old TTL to expire
Hour 0: Change A record, TTL now 300s
Hour 0.5: Most caches refreshed
Hour 2: 95% propagated
Result: 2-hour propagation ✅
Step-by-step process:
Day -2 (48 hours before migration):
# 1. Check current TTL
dig example.com
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
↑
86400s = 24 hours TTL
# Note: Must wait 24 hours for this to expire
# 2. Log into DNS provider dashboard
# 3. Edit A record
# 4. Change TTL: 86400 → 300 (5 minutes)
# 5. Save changes
New config:
example.com A 93.184.216.34 TTL 300
# 6. Verify change on authoritative NS
dig @ns1.cloudflare.com example.com
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
↑
Now 300s ✅
Day -1 (24 hours before migration):
# 7. Verify low TTL propagated
dig @8.8.8.8 example.com
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.34
↑
Google DNS now has 300s TTL ✅
# All caches now refresh every 5 minutes
Day 0 (Migration day):
# 8. Make your actual change
Log into DNS provider
Change A record:
Old: example.com A 93.184.216.34 TTL 300
New: example.com A 93.184.216.35 TTL 300
Save
# 9. Monitor propagation
./check_propagation.sh
# Hour 0, Min 10:
Propagation: 30%
# Hour 0, Min 30:
Propagation: 75%
# Hour 1:
Propagation: 90%
# Hour 2:
Propagation: 95% ✅
# 10. After 90%+ propagation, begin migrating traffic
# New server ready to handle full load
# 11. After 100% propagation (2-4 hours):
# Raise TTL back to normal
Change TTL: 300 → 3600 (1 hour)
# Don't keep TTL at 300 forever
# Higher TTL = fewer DNS queries = better performance
Result: 2-4 hour propagation instead of 24-48 hours!
TTL lowering timeline by original TTL:
Original TTL: 86400s (24 hours)
Lower to: 300s (5 minutes)
When: 48 hours before
Why: Need 24h for old TTL to expire + buffer
Original TTL: 3600s (1 hour)
Lower to: 300s (5 minutes)
When: 24 hours before
Why: Need 1h for old TTL to expire + buffer
Original TTL: 600s (10 minutes)
Lower to: 300s (5 minutes)
When: 2 hours before
Why: Already pretty low, quick expiration
Original TTL: 300s (5 minutes)
Lower to: 300s (5 minutes)
When: No change needed
Why: Already optimal for migrations
Common mistakes:
❌ WRONG: Lower TTL AFTER making change
Problem: Old high TTL still cached everywhere
Result: Must wait full old TTL to expire
✅ RIGHT: Lower TTL BEFORE making change
Benefit: Low TTL already cached when you change
Result: Fast propagation
Why 300s (5 minutes)?
Too low (60s = 1 min):
- Excessive DNS queries
- Server load spikes
- Higher DNS costs
- Only marginal speed benefit
Optimal (300s = 5 min):
- Fast propagation (30 min - 2 hours)
- Reasonable query volume
- Good balance
Too high (3600s = 1 hour):
- Slower propagation (2-6 hours)
- But still better than 86400s!
Verification checklist:
☐ Check current TTL (dig example.com)
☐ Calculate when to lower TTL (48h before)
☐ Lower TTL to 300s
☐ Wait for old TTL to fully expire
☐ Verify low TTL propagated (dig @8.8.8.8)
☐ Make DNS change
☐ Monitor propagation
☐ After 100% propagated, raise TTL to 3600s
☐ Document timeline for future migrations
Strategy 2: Use DNS Providers with Fast Propagation
Not all DNS providers are equal.
Provider comparison:
Cloudflare DNS (Recommended)
Infrastructure:
- Anycast network
- 275+ cities globally
- Users routed to nearest server
Update speed:
- Internal sync: 1-5 seconds
- Global propagation: 1-10 minutes
- Authoritative query response: <20ms
Features:
- Free tier available
- DNSSEC included
- DDoS protection
- 100% uptime SLA
- API for automation
Propagation speed: ⭐⭐⭐⭐⭐ (Excellent)
Cost: Free (or $20/month Pro)
AWS Route 53
Infrastructure:
- Global edge network
- 50+ edge locations
- Anycast routing
Update speed:
- Updates: 60 seconds or less
- Global propagation: 2-5 minutes
- Low latency worldwide
Features:
- Geographic routing
- Health checks
- Traffic policies
- 100% SLA
- Deep AWS integration
Propagation speed: ⭐⭐⭐⭐⭐ (Excellent)
Cost: $0.50/hosted zone/month + $0.40/million queries
Google Cloud DNS
Infrastructure:
- Global anycast network
- Google's infrastructure
- 100+ points of presence
Update speed:
- Updates: Seconds
- Global propagation: 2-10 minutes
- Highly reliable
Features:
- DNSSEC
- Private DNS zones
- Managed DNS
- 100% SLA
Propagation speed: ⭐⭐⭐⭐⭐ (Excellent)
Cost: $0.20/zone/month + queries
Traditional Shared Hosting DNS
Infrastructure:
- Often single datacenter
- 1-2 nameservers
- No anycast
Update speed:
- Updates: 5-30 minutes
- Global propagation: 1-4 hours
- Variable performance
Features:
- Basic DNS only
- Limited control
- Often bundled with hosting
Propagation speed: ⭐⭐ (Slow)
Cost: Usually free with hosting
Why modern providers are faster:
Traditional DNS (slow):
Your nameserver: New York
User in Tokyo: 200ms roundtrip to New York
User in London: 80ms roundtrip to New York
User in Sydney: 250ms roundtrip to New York
Result: Slow for non-US users
Anycast DNS (fast):
200+ nameservers worldwide
User in Tokyo: Routed to Tokyo server (10ms)
User in London: Routed to London server (8ms)
User in Sydney: Routed to Sydney server (12ms)
Result: Fast globally
Internal propagation comparison:
Traditional DNS:
- Single master server
- Updates: Manual or slow sync
- Secondary servers: 5-30 min sync
- Total: 30+ minutes internal propagation
Anycast DNS:
- Master updates all edge servers
- Sync: Seconds (automated)
- Edge servers: Instantly available
- Total: 5-60 seconds internal propagation
Migration recommendation:
Currently using shared hosting DNS?
→ Migrate to Cloudflare DNS (free)
Results:
- Before: 24-48 hour propagation
- After: 2-4 hour propagation
- Plus: Better performance, DNSSEC, DDoS protection
Worth it: Absolutely ✅
How to migrate DNS providers:
1. Sign up for new DNS provider (Cloudflare)
2. Add your domain
3. Cloudflare scans existing DNS records
4. Review and adjust records
5. Lower TTL on OLD provider to 300s
6. Wait 48 hours
7. Change nameservers at registrar:
Old: ns1.oldhost.com
New: ns1.cloudflare.com
8. Wait for nameserver propagation (24-48h)
9. Verify all records work
10. Enjoy faster propagation forever ✅
Strategy 3: Clear Caches Manually
Manual cache clearing helps YOU see changes faster. (Doesn’t help other users.)
Your local computer:
Windows:
ipconfig /flushdns
Output:
Windows IP Configuration
Successfully flushed the DNS Resolver Cache.
macOS:
# macOS Big Sur (11.0) and later
sudo dscacheutil -flushcache
sudo killall -HUP mDNSResponder
# Verify
# No output = success
Linux (systemd):
sudo systemd-resolve --flush-caches
# Verify
sudo systemd-resolve --statistics
# Should show "Cache size: 0"
Linux (older systems):
# Ubuntu/Debian
sudo /etc/init.d/nscd restart
# Or
sudo service nscd restart
# CentOS/RHEL
sudo systemctl restart nscd
Your browser:
Chrome:
Method 1: DNS cache
1. Visit: chrome://net-internals/#dns
2. Click "Clear host cache"
Method 2: Sockets
1. Visit: chrome://net-internals/#sockets
2. Click "Flush socket pools"
Method 3: Full clear
1. Ctrl+Shift+Delete
2. Check "Cached images and files"
3. Time range: All time
4. Click "Clear data"
Restart Chrome for best results
Firefox:
Method 1: DNS cache
1. Visit: about:networking#dns
2. Click "Clear DNS Cache"
Method 2: Full clear
1. Ctrl+Shift+Delete
2. Select "Everything"
3. Check "Cache"
4. Click "Clear Now"
Restart Firefox
Safari:
Method 1: Develop menu
1. Enable Develop menu (Safari → Preferences → Advanced → Show Develop menu)
2. Develop → Empty Caches
Method 2: Quit and restart
1. Quit Safari completely
2. Reopen Safari
3. Fresh DNS cache
Edge:
1. Visit: edge://net-internals/#dns
2. Click "Clear host cache"
3. Restart Edge
Your router:
Most effective method:
1. Unplug router power
2. Wait 30 seconds
3. Plug back in
4. Wait 2-3 minutes for full startup
5. Reconnect devices
Alternative (if router supports):
1. Access router admin (usually 192.168.1.1 or 192.168.0.1)
2. Login
3. Look for:
- "DNS cache"
- "Flush DNS"
- "Clear cache"
- "Reboot"
4. Click to clear
5. Reboot router
Not all routers support manual DNS flush
Power cycle is most reliable
IMPORTANT LIMITATION:
Clearing YOUR caches:
- Helps YOU see changes immediately
- Useful for testing
- Doesn't affect other users
- Doesn't speed up global propagation
Global propagation:
- Controlled by TTL
- Must wait for everyone's caches to expire
- Can't force other people's caches to clear
- Only time (or low TTL) works
When to clear caches:
✅ Testing your own changes
✅ Verifying DNS works on your machine
✅ Troubleshooting local DNS issues
✅ During development
❌ Speeding up propagation for users (doesn't work)
❌ As primary migration strategy (not effective)
❌ Instead of lowering TTL (wrong approach)
Verification after clearing:
# Flush DNS cache
ipconfig /flushdns # Windows
# Immediately test
dig example.com
# Should fetch fresh from DNS (not local cache)
# Verify IP matches expected new value
Strategy 4: Use Multiple DNS Providers (Advanced)
DNS failover and multi-provider setup for maximum redundancy and speed.
Concept:
Single provider:
ns1.cloudflare.com
ns2.cloudflare.com
Cloudflare down = DNS completely broken ❌
Multi-provider:
ns1.cloudflare.com (Primary)
ns2.cloudflare.com (Primary)
ns1.awsdns.com (Secondary)
ns2.awsdns.net (Secondary)
If Cloudflare down, AWS serves DNS ✅
Benefits:
1. Redundancy:
- Provider outage doesn't kill DNS
- Automatic failover
- Higher availability
2. Performance:
- Resolvers query fastest provider
- Geographic optimization
- Load distribution
3. Faster propagation:
- Changes sync to multiple networks
- Multiple entry points globally
- Reduced single point of failure
4. DDoS mitigation:
- Attack on one provider doesn't take down DNS
- Distributed infrastructure
Setup example:
Primary provider: Cloudflare
1. Sign up for Cloudflare
2. Add domain
3. Configure all DNS records
4. Note nameservers:
ns1.cloudflare.com
ns2.cloudflare.com
Secondary provider: AWS Route 53
1. Sign up for AWS Route 53
2. Create hosted zone
3. Copy same DNS records from Cloudflare
4. Note nameservers:
ns-123.awsdns-45.com
ns-678.awsdns-90.net
At registrar:
List ALL nameservers:
ns1.cloudflare.com
ns2.cloudflare.com
ns-123.awsdns-45.com
ns-678.awsdns-90.net
DNS resolvers will query any/all
Automatic failover if one doesn't respond
Keeping records synchronized:
Option 1: Manual sync
1. Make changes on Cloudflare (primary)
2. Copy same changes to Route 53 (secondary)
3. Verify both serve identical data
4. Both stay in sync manually
Option 2: Automated sync (recommended)
#!/bin/bash
# dns_sync.sh
# Sync DNS from Cloudflare to Route 53
# Export from Cloudflare via API
cloudflare_records=$(curl -X GET \
"https://api.cloudflare.com/client/v4/zones/$ZONE_ID/dns_records" \
-H "Authorization: Bearer $CF_API_TOKEN" \
| jq -r '.result[] | "\(.name) \(.type) \(.content)"')
# Import to Route 53 via API
# (Pseudo-code - actual implementation uses AWS CLI/SDK)
aws route53 change-resource-record-sets \
--hosted-zone-id $ROUTE53_ZONE_ID \
--change-batch file://changes.json
echo "DNS records synchronized"
Run sync after every DNS change:
# After making change on Cloudflare
./dns_sync.sh
# Both providers now have same records
Testing multi-provider setup:
# Test Cloudflare
dig @ns1.cloudflare.com example.com
# Test AWS
dig @ns-123.awsdns-45.com example.com
# Both should return IDENTICAL results
# If different, records not synced correctly
Propagation benefits:
Single provider:
- Change on Cloudflare
- Cloudflare's global network updates
- Propagation depends on Cloudflare's sync speed
Multi-provider:
- Change on Cloudflare → Cloudflare network updates
- Sync to Route 53 → AWS network updates
- Two global networks serving your DNS
- Faster average propagation globally
- More resolvers find updated records sooner
Cost consideration:
Cloudflare: Free
AWS Route 53: $0.50/zone/month + queries
Total: ~$1-5/month for most sites
Worth it for critical domains: Yes ✅
When to use multi-provider:
✅ Mission-critical domains
✅ High-traffic sites (>100k visits/day)
✅ E-commerce (downtime = revenue loss)
✅ SaaS applications
✅ Enterprise deployments
❌ Personal blogs (overkill)
❌ Low-traffic sites (single provider sufficient)
❌ Hobby projects (unnecessary complexity)
Strategy 5: Pre-populate Caches (Advanced)
Limited effectiveness, but can help in specific scenarios.
Concept:
Normal propagation:
- User queries DNS
- Resolver cache empty
- Resolver queries authoritative NS
- Gets old record (if TTL not expired)
- User sees old value
Pre-populating:
- YOU query DNS before users do
- Forces resolver to fetch from authoritative
- Resolver caches new value
- When real user queries, cache has new value
Method:
# Force major DNS resolvers to cache your new record
for server in 8.8.8.8 1.1.1.1 9.9.9.9 208.67.222.222; do
echo "Querying $server"
dig @$server example.com > /dev/null
sleep 1
done
# Major resolvers now have your record cached
# But only if TTL expired and they fetched new value
Effectiveness:
Pros:
✅ Helps for YOUR testing
✅ Pre-caches on servers you control
✅ Useful for staging/preview environments
Cons:
❌ Can't force user ISP resolvers
❌ Can't pre-populate thousands of resolvers
❌ Limited real-world impact
❌ Only works if TTL already expired
❌ Minimal improvement vs just waiting
Better approach: Staged rollout
Instead of pre-populating caches, gradually shift traffic:
Hour 0: Make DNS change
Hour 0.5: Route 10% traffic to new server (load balancer)
Hour 1: Check propagation - if 50%, route 25% traffic
Hour 2: Check propagation - if 80%, route 50% traffic
Hour 3: Check propagation - if 95%, route 100% traffic
Benefits:
- Gradual migration reduces risk
- Can rollback quickly if issues
- Users distributed across old/new naturally
- Matches actual propagation curve
Load balancer setup for staged rollout:
Nginx example:
upstream backend {
server 93.184.216.34 weight=90; # Old server
server 93.184.216.35 weight=10; # New server
}
# As propagation progresses:
# Hour 1: weight=75 (old) weight=25 (new)
# Hour 2: weight=50 (old) weight=50 (new)
# Hour 3: weight=25 (old) weight=75 (new)
# Hour 4: weight=0 (old) weight=100 (new)
When pre-populating actually helps:
Scenario: Product launch with known time
- Launch at 12:00 PM
- At 11:55 AM, query major DNS manually
- Forces resolvers to have fresh data
- At 12:00 PM launch, major DNS updated
- Early users get better experience
Scenario: Preview environment for clients
- Give client preview URL: preview.example.com
- Before sending link, query major DNS
- Client won't see "not found" errors
- Professional presentation
Verdict: Pre-populating is 5% of the solution. Lowering TTL is 95%.
Strategy 6: Plan Changes During Low-Traffic Periods
Timing matters: Fewer users affected = less risk.
Why timing matters:
Peak traffic (bad time):
- 10,000 users online
- 50% see old site, 50% see new site
- 5,000 confused users
- Support tickets flooding in
- Revenue impact during mixed state
Low traffic (good time):
- 500 users online
- 50% see old site, 50% see new site
- 250 confused users
- Manageable support load
- Minimal revenue impact
Best times for DNS changes by site type:
E-commerce sites:
✅ BEST: Tuesday-Thursday, 2-6 AM local time
Reason: Lowest traffic, mid-week recovery time
❌ AVOID: Friday-Sunday
Reason: Weekend shopping traffic
❌ AVOID: Monday mornings
Reason: Week start spike
❌ AVOID: Holidays, Black Friday, Cyber Monday
Reason: Peak sales periods
❌ AVOID: End of month
Reason: Budget-driven purchases
B2B/SaaS applications:
✅ BEST: Sunday 12 AM - 6 AM or Saturday evening
Reason: Businesses closed, minimal usage
❌ AVOID: Monday 8 AM - 12 PM
Reason: Week start, highest B2B activity
❌ AVOID: End of quarter/year
Reason: Deal closings, high activity
✅ OKAY: Wednesday evening
Reason: Mid-week, declining activity
Global audience:
✅ BEST: Find the timezone with least traffic
Use Google Analytics:
- Audience → Geo → Location
- Check traffic by hour
- Find global minimum (usually 4-8 AM in major markets)
Example: US-based site with Asian users
- 3 AM US time = 4 PM Asia (high traffic) ❌
- 8 PM US time = 9 AM Asia (high traffic) ❌
- 4 AM US time = 6 PM Asia (moderate) ✅
Emergency changes:
Site down? Security issue? Critical bug?
🚨 CHANGE IMMEDIATELY
- Don't wait for "low traffic"
- Fixing outage > perfect timing
- Communicate with users
- Accept temporary mixed state
Pre-change preparation for perfect timing:
Day -2: Lower TTL to 300s
Day -1: Verify low TTL propagated
Day 0, 3:00 AM: Make DNS change
Day 0, 3:30 AM: Verify propagation starting
Day 0, 4:00 AM: Monitor for issues
Day 0, 6:00 AM: 90%+ propagated, traffic increasing
Day 0, 8:00 AM: Business hours start, migration complete ✅
Communication strategy:
Before change:
Email to users (1 day before):
"We're performing infrastructure upgrades on [DATE] at [TIME].
You may experience brief inconsistencies.
Please clear your browser cache if you encounter issues."
During change:
Status page update:
"🔧 Maintenance in Progress
We're migrating to new servers.
Expected completion: 2 hours
You may see temporary inconsistencies."
After change:
"✅ Migration Complete
All systems operational.
If you experience issues, clear your browser cache."
Monitoring during low-traffic changes:
Even at 3 AM:
☐ Have engineer on call
☐ Monitor error logs
☐ Watch user reports (even if few)
☐ Ready to rollback if needed
☐ Track propagation progress
☐ Verify both old and new servers healthy
Don't schedule and sleep!
Strategy 7: Use DNS Prefetching (For Website Owners)
Browser DNS prefetching reduces user-perceived DNS delay.
What DNS prefetching does:
Normal page load:
1. User clicks link
2. Browser resolves DNS for destination
3. DNS lookup: 20-100ms
4. Connect to server
5. Page loads
With prefetching:
1. User on current page
2. Browser pre-resolves DNS in background (while user reads)
3. User clicks link
4. DNS already resolved (0ms!)
5. Connect to server immediately
6. Faster page load
How to implement:
<!-- Add to <head> section of your HTML -->
<link rel="dns-prefetch" href="//example.com">
<link rel="dns-prefetch" href="//api.example.com">
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//images.example.com">
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//www.google-analytics.com">
What to prefetch:
<!-- Your own domains -->
<link rel="dns-prefetch" href="//example.com">
<link rel="dns-prefetch" href="//www.example.com">
<!-- API endpoints -->
<link rel="dns-prefetch" href="//api.example.com">
<!-- CDN domains -->
<link rel="dns-prefetch" href="//cdn.example.com">
<link rel="dns-prefetch" href="//images.example.com">
<link rel="dns-prefetch" href="//static.example.com">
<!-- Third-party services -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//ajax.googleapis.com">
<link rel="dns-prefetch" href="//www.googletagmanager.com">
<link rel="dns-prefetch" href="//cdn.jsdelivr.net">
Effect on propagation:
Does NOT speed up actual propagation:
- DNS still cached based on TTL
- Propagation timeline unchanged
- Global distribution unaffected
DOES reduce user-perceived delay during propagation:
- Browser pre-fetches DNS
- Multiple domains resolved in parallel
- Faster page transitions
- Better user experience during mixed propagation
During migration:
Old site:
<link rel="dns-prefetch" href="//example.com">
<link rel="dns-prefetch" href="//old-server.example.com">
New site:
<link rel="dns-prefetch" href="//example.com">
<link rel="dns-prefetch" href="//new-server.example.com">
Users who land on new site:
- Browser prefetches new-server DNS
- Subsequent requests faster
- Better experience even during propagation
Advanced: Preconnect for even faster loading:
<!-- DNS prefetch: Only resolves DNS -->
<link rel="dns-prefetch" href="//api.example.com">
<!-- Preconnect: DNS + TCP + TLS handshake -->
<link rel="preconnect" href="//api.example.com">
<!-- Even faster for critical resources -->
Performance impact:
DNS prefetch savings:
- 20-100ms per domain
- Parallel lookups
- Negligible overhead
Example:
Without prefetch:
- User clicks link
- DNS lookup: 50ms
- Total: 50ms before connection
With prefetch:
- DNS already resolved
- DNS lookup: 0ms
- Total: 0ms before connection
50ms faster!
Best practices:
✅ Prefetch domains you know users will visit
✅ Include third-party domains (analytics, fonts, etc.)
✅ Limit to 10-15 domains (diminishing returns)
✅ Prioritize critical resources
❌ Don't prefetch every possible domain
❌ Don't prefetch rarely-used domains
❌ Don't rely on this to "fix" propagation
Browser support:
Chrome: ✅ Full support
Firefox: ✅ Full support
Safari: ✅ Full support
Edge: ✅ Full support
IE 11: ⚠️ Partial support
Widely supported, safe to use
Common DNS Propagation Problems and Solutions
Step-by-step troubleshooting for every propagation issue.
Problem 1: Propagation Taking Longer Than Expected
Symptoms:
- 48+ hours since DNS change
- Still seeing old records on some servers
- Mixed results globally
- Users report inconsistent experience
Common causes:
1. Original TTL was very high (86400s+)
Problem: Changed DNS with 24-hour TTL
Must wait 24-48 hours for all caches to expire
No way to speed up retroactively
Lesson: Always lower TTL BEFORE changing DNS
2. ISP ignoring TTL (caching longer than specified)
Problem: Some ISPs override TTL values
Cache for days regardless of your TTL setting
Against RFC spec but happens
Identification: Most DNS updated, but specific ISPs stuck
3. Corporate DNS with custom policies
Problem: Enterprise networks often have custom DNS
May cache for hours/days
Not controlled by your TTL
Identification: Users at companies report old records
Home users see new records
4. Typo in new DNS record
Problem: Entered wrong IP in new record
Propagating wrong value
Identification: Authoritative NS shows unexpected value
5. Secondary nameservers not synced
Problem: Primary NS updated, secondary NS not synced
Some users query secondary, get old data
Identification: Different NSes return different values
Diagnosis steps:
# Step 1: Verify change on authoritative NS
dig @ns1.cloudflare.com example.com
;; ANSWER SECTION:
example.com. 300 IN A 93.184.216.35
↑
Should show NEW value
If shows OLD value → Change didn't save correctly
If shows WRONG value → Typo in new record
If shows NEW value → Authoritative NS correct ✅
# Step 2: Check TTL value
dig example.com
;; ANSWER SECTION:
example.com. 86400 IN A 93.184.216.34
↑
TTL in response
High TTL (86400s) → Must wait 24h
Low TTL (300s) → Should be fast
# Step 3: Check multiple public DNS
dig @8.8.8.8 example.com
dig @1.1.1.1 example.com
dig @9.9.9.9 example.com
Compare results:
All same → Either all updated or all cached old
Mixed → Propagation in progress (normal)
All old → TTL not expired yet
# Step 4: Check all your nameservers
for ns in ns1.cloudflare.com ns2.cloudflare.com; do
echo "Checking $ns:"
dig @$ns example.com
echo ""
done
Should all return IDENTICAL values
If different → Secondary NS not synced
Solutions:
Solution 1: Wait for original TTL to fully expire
If TTL was 86400s (24 hours):
- Must wait minimum 24 hours
- More realistically 48 hours for full propagation
- No way to speed this up after the fact
Timeline:
Hour 0: Change made
Hour 24: First caches expiring
Hour 48: Most caches expired
Hour 72: Essentially complete
Action: Monitor, be patient, keep both servers online
Solution 2: Contact ISP if their DNS misbehaving
If specific ISP stuck:
1. Identify ISP:
dig example.com
# Note which resolver returning old value
2. Gather evidence:
dig @isp-dns.com example.com > old_result.txt
dig @8.8.8.8 example.com > good_result.txt
dig @ns1.cloudflare.com example.com > authoritative.txt
3. Contact ISP support:
"Your DNS (isp-dns.com) returning stale record for example.com
TTL: 300s (5 minutes)
Changed: 48 hours ago
Still returning old IP: 93.184.216.34
Should return: 93.184.216.35
Please flush DNS cache for example.com"
4. Provide evidence files
Most ISPs will manually flush if provided evidence
Solution 3: Fix typo if found
If authoritative NS shows wrong value:
1. Log into DNS provider
2. Check record carefully:
Typo: example.com A 93.184.216.53 (should be .35)
↑
Wrong digit
3. Correct immediately
4. Save
5. Wait for TTL to expire
(Unfortunate: Must wait AGAIN for propagation)
Lesson: Double-check changes before saving
Solution 4: Sync secondary nameservers
If primary and secondary NS return different values:
Check SOA serial number:
dig example.com SOA
;; ANSWER SECTION:
example.com. 3600 IN SOA ns1.example.com. admin.example.com. (
2025111601 ; Serial
↑
Should increment with each change
If secondary NS has old serial → Not synced
Force zone transfer:
1. Log into DNS provider
2. Look for "Force zone transfer" or "Sync secondary"
3. Click to force sync
4. Wait 5-15 minutes
5. Verify:
dig @ns1.example.com example.com
dig @ns2.example.com example.com
# Should match now ✅
Prevention for future:
☐ Always lower TTL 48h before changes
☐ Double-check new values before saving
☐ Verify on authoritative NS immediately after change
☐ Test from multiple DNS resolvers after 30min
☐ Monitor propagation with tools
☐ Keep both old and new infrastructure online during propagation
☐ Document timeline for postmortem
Problem 2: Some Users See New Site, Others See Old
This is NORMAL during propagation!
Why it happens:
DNS propagation is NOT instantaneous
Different users' DNS resolvers update at different times
Creates temporary split-brain state
User A:
└─ ISP: Comcast
└─ Comcast DNS cached old record
└─ Comcast DNS TTL not expired yet
└─ Connects to: 93.184.216.34 (old server)
└─ Sees: Old website ❌
User B:
└─ ISP: Verizon
└─ Verizon DNS TTL already expired
└─ Verizon DNS fetched new record
└─ Connects to: 93.184.216.35 (new server)
└─ Sees: New website ✅
User C:
└─ Uses Google DNS (8.8.8.8)
└─ Google DNS updated quickly
└─ Connects to: 93.184.216.35 (new server)
└─ Sees: New website ✅
Same website, same time, different experiences!
How long to expect mixed traffic:
TTL 300s (5 min):
Mixed traffic period: 30 min - 2 hours
Hour 0: 100% old server
Hour 0.5: 70% old, 30% new
Hour 1: 40% old, 60% new
Hour 2: 10% old, 90% new
Hour 4: 1% old, 99% new (essentially done)
Short mixed state ✅
TTL 3600s (1 hour):
Mixed traffic period: 2-6 hours
Hour 0: 100% old server
Hour 2: 60% old, 40% new
Hour 4: 30% old, 70% new
Hour 6: 15% old, 85% new
Hour 12: 5% old, 95% new
Hour 24: <1% old, 99% new
Moderate mixed state ⚠️
TTL 86400s (24 hours):
Mixed traffic period: 24-48 hours
Hour 12: 90% old, 10% new
Hour 24: 50% old, 50% new
Hour 36: 30% old, 70% new
Hour 48: 10% old, 90% new
Hour 72: <1% old, 99% new
Long mixed state ❌ (risky!)
Problems during mixed traffic:
Problem: Session loss
User logs in on old server (93.184.216.34)
Session stored on old server
30 minutes later:
User's DNS refreshed → New server (93.184.216.35)
New server doesn't have user's session
User appears logged out
Frustrating experience ❌
Problem: Shopping cart cleared
User adds items to cart on old server
Cart stored locally on old server
User continues shopping:
DNS refreshed → Connects to new server
New server has empty cart
Items disappeared
Lost sale ❌
Problem: Form resubmission
User submits form on old server
Form data saved in old server's database
User refreshes page:
DNS refreshed → New server
New server queries database
If databases not synced, form data missing
User must resubmit ❌
Problem: Inconsistent content
User sees old homepage (old server)
Clicks link to product page
DNS refreshed → New server
Product page shows new layout/pricing
Confusing inconsistent experience ❌
Solutions for developers:
Solution 1: Keep both servers running with identical content
Configuration:
Old server (93.184.216.34):
- Keep online for TTL × 2 period
- Serve identical content as new server
- Sync data with new server
- Don't decomission until zero traffic
New server (93.184.216.35):
- Fully operational
- Serve same content as old server
- Accept all traffic
- Ready for full load
Timeline:
TTL 300s → Keep old server 4-8 hours
TTL 3600s → Keep old server 24 hours
TTL 86400s → Keep old server 72 hours
Benefit: Users get consistent experience regardless of which server
Solution 2: Share session data between servers
// ❌ WRONG: File-based sessions (local to each server)
session.save_path = "/tmp"
// Old server sessions: /tmp/sess_abc123
// New server sessions: /tmp/sess_def456
// NOT shared!
// ✅ RIGHT: Redis/Memcached for sessions (shared)
const session = require('express-session');
const RedisStore = require('connect-redis')(session);
const redis = require('redis');
const redisClient = redis.createClient({
host: 'redis.example.com', // Shared Redis server
port: 6379
});
app.use(session({
store: new RedisStore({ client: redisClient }),
secret: 'your-secret',
resave: false,
saveUninitialized: false
}));
// Now sessions stored in shared Redis
// Both old and new server access same session data
// User maintains session across migration ✅
PHP example:
<?php
// Configure PHP to use Redis for sessions
ini_set('session.save_handler', 'redis');
ini_set('session.save_path', 'tcp://redis.example.com:6379');
session_start();
// Sessions now shared between all servers ✅
?>
Solution 3: Implement sticky sessions (load balancer)
# Nginx load balancer with sticky sessions
upstream backend {
# IP hash: Same user always goes to same server
ip_hash;
server 93.184.216.34; # Old server
server 93.184.216.35; # New server
}
server {
listen 80;
server_name example.com;
location / {
proxy_pass http://backend;
}
}
# Result: User lands on Server A → Always stays on Server A
# Prevents session jumping during propagation
Alternative: Cookie-based sticky sessions
upstream backend {
server 93.184.216.34;
server 93.184.216.35;
sticky cookie srv_id expires=1h domain=.example.com path=/;
}
# Sets cookie to remember which server user connected to
# Subsequent requests use same server
Solution 4: Display maintenance message during critical periods
<!-- Show during propagation window -->
<?php if (time() < strtotime('2025-11-17 06:00:00')) { ?>
<div style="background: #fff3cd; padding: 12px; text-align: center; border-bottom: 1px solid #ffc107;">
<strong>⚠️ Maintenance Notice:</strong>
We're migrating to new servers. You may see temporary inconsistencies.
If you experience issues, please <a href="#" onclick="clearCache()">clear your browser cache</a>.
</div>
<?php } ?>
<script>
function clearCache() {
// Instruct user how to clear cache
alert('Please press Ctrl+Shift+Delete and clear your browsing data, then reload this page.');
}
</script>
Solution 5: Communicate with users
Email notification (1 day before):
Subject: Infrastructure Upgrade Scheduled
Hi,
We're performing infrastructure upgrades on November 17, 2025, at 3:00 AM EST.
During this time (3:00 AM - 6:00 AM):
- The site remains accessible
- You may see temporary inconsistencies
- Sessions may be lost (please save your work)
If you experience issues:
1. Clear your browser cache (Ctrl+Shift+Delete)
2. Try incognito/private mode
3. Use mobile data instead of WiFi
4. Contact support if problems persist
Thank you for your patience!
Status page during migration:
🔧 Maintenance in Progress
Status: Migrating to new servers
Expected completion: 3 hours
Current status: 50% propagated
You may experience:
- Temporary session loss
- Inconsistent page layouts
- Brief loading delays
This is normal and will resolve within 3 hours.
After migration complete:
✅ Migration Complete
All systems operational on new infrastructure.
Performance improvements are now live.
If you experience any issues:
- Clear your browser cache
- Restart your browser
- Contact support if problems persist
Thank you for your patience!
When to worry vs when it’s normal:
NORMAL (don't worry):
✅ Mixed traffic for TTL × 2 period
✅ Different users see different servers
✅ Gradual shift from old to new
✅ Session loss if not using shared sessions
CONCERNING (investigate):
❌ No propagation after 2× TTL period
❌ Propagation stuck at 50% for >12 hours
❌ Authoritative NS shows wrong value
❌ Database corruption or data loss
❌ Severe performance degradation
Use our DNS Lookup tool to monitor which DNS servers have updated and track propagation progress in real-time.
Related Resources and Tools
Essential DNS tools for developers:
- DNS Lookup - Check DNS propagation across multiple servers instantly
- DNS Troubleshooting Guide - Complete DNS lookup and troubleshooting guide
- SSL Certificate Checker - Verify SSL after DNS changes
- HTTP Headers Analyzer - Check server headers and responses
- Subnet Calculator - Plan IP address ranges for migrations
- Hash Generator - Generate DNSSEC hashes and checksums
External authoritative resources:
- RFC 1035 - DNS Implementation Specification (ietf.org/rfc/rfc1035.txt)
- ICANN - Internet governance and DNS policy (icann.org)
- Cloudflare Learning Center - DNS propagation explained (cloudflare.com/learning/dns/what-is-dns-propagation/)
- WhatsMyDNS.net - Global DNS propagation checker (whatsmydns.net)
- Google Public DNS - Documentation and best practices (developers.google.com/speed/public-dns)
Conclusion
DNS propagation isn’t the mysterious 24-72 hour waiting game most developers think it is. It’s a predictable, controllable process governed entirely by TTL values and caching mechanics.
Key takeaways:
- “Propagation” is cache expiration - Nothing spreads; caches just expire based on TTL
- TTL controls everything - TTL 300s = 2h propagation; TTL 86400s = 48h propagation
- Lower TTL 48h before changes - This single step reduces migration time by 90%
- Email requires special care - Never delete old MX immediately; staged migration prevents email loss
- Mixed traffic is normal - Keep both servers running during transition period
- Nameserver changes are slowest - Registry-level propagation adds 24-48h minimum
- Modern DNS providers are faster - Anycast networks (Cloudflare, Route 53) propagate in minutes internally
Your action plan:
For next migration:
- Lower TTL to 300s at least 48 hours before
- Wait for old TTL to fully expire
- Make DNS changes
- Monitor with orbit2x.com/lookup
- Keep both infrastructures running
- After 95%+ propagation, route traffic fully to new
- Raise TTL back to 3600s
- Decommission old infrastructure after 7 days
Stop waiting 72 hours for DNS propagation. With proper TTL management, you can migrate websites in 2-4 hours instead of 2-4 days.
Start checking your DNS propagation now: orbit2x.com/lookup
