How long does DNS propagation take?

Understanding DNS Propagation

DNS propagation is the time it takes for DNS changes to distribute across internet nameservers worldwide. When you update a DNS record, the change doesn't instantly appear globally—it takes time for nameservers to receive, cache, and serve the updated information.

Understanding DNS propagation helps you plan maintenance, set realistic expectations for domain changes, and troubleshoot issues where some locations see old data while others see new data.

The DNS Propagation Process

Timeline of DNS Propagation

Time 0: Change Made

• DNS record updated at authoritative nameserver
• Old DNS information still cached elsewhere

Time 0-5 minutes: Authoritative Update

• Authoritative nameserver has new record
• Only systems querying authoritative nameserver get new data

Time 5-30 minutes: ISP Resolver Updates

• Major ISP resolvers refresh their caches
• Larger percentage of users see new data
• Some ISPs still serving old cached data

Time 30 minutes - 12 hours: Regional Distribution

• Smaller ISPs and regional resolvers update
• Most users see new data
• Some edge cases still see old data

Time 12-48 hours: Global Distribution

• All nameservers have updated
• Caches expire worldwide
• Consistent results globally

Standard guidance: DNS propagation takes 24-48 hours for complete global distribution.

Factors Affecting Propagation Speed

1. TTL (Time To Live)

TTL is the most significant factor:

example.com    3600    A    192.0.2.1
                ^^^^
                TTL in seconds

• 3600 (1 hour): Cache expires after 1 hour; faster propagation
• 86400 (1 day): Cache expires after 24 hours; slower propagation
• 300 (5 minutes): Very fast propagation, more DNS traffic

During change:

• Old TTL value controls cache duration
• High TTL (86400) means old data cached for 24 hours
• Low TTL (300) means old data flushed after 5 minutes

Strategy:

1. Reduce TTL to 300 (one day before change)
2. Wait 24 hours for old TTL to expire
3. Make DNS change
4. Propagation happens quickly (5 minutes to hours)
5. Wait 24 hours, increase TTL back to 3600

2. Caching at Multiple Levels

DNS is cached at multiple layers:

1. Browser cache: Minutes to hours
2. Operating system cache: Minutes to hours
3. ISP resolver cache: Honors TTL
4. Authoritative nameserver: No cache, authoritative
5. Root/TLD nameservers: Cache for efficiency

Each level must refresh independently.

3. ISP Behavior

Different ISPs handle TTL differently:

• Strict compliance: Honor TTL exactly
• Longer caching: Cache longer than TTL specifies
• Shorter caching: Override TTL with lower values
• Inconsistent: Different behavior at different times

Can't control ISP behavior, only plan for variation.

4. Resolver Configuration

Public resolvers vs. ISP resolvers:

• Google DNS (8.8.8.8): Fast refresh, good compliance
• Cloudflare (1.1.1.1): Balanced refresh and efficiency
• ISP resolvers: Varies widely

Users experiencing slow propagation might be using ISP resolver with aggressive caching.

5. Type of Change

Different record changes propagate at different speeds:

• A record changes: Propagate quickly, widely distributed
• CNAME changes: Similar speed to A records
• MX/TXT changes: Propagate as quickly as A records
• Nameserver changes: May take 24-48 hours (registrar level)

Nameserver changes are slowest because registrar propagation is involved.

Monitoring Propagation

Online Propagation Checkers

Real-time tools showing propagation status:

• What's My DNS: DNS changes from 200+ locations
• WhatsMyDNS: Visual propagation maps
• DNS Propagation Checker: Check multiple record types
• Google Public DNS: dns.google propagation checker

These tools check your DNS from servers worldwide, showing how propagation progresses.

Command-Line Monitoring

# Check propagation over time
watch -n 60 'dig example.com A +short'

# Check from different nameservers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @ns1.example.com example.com A

# Monitor specific record
while true; do
  echo "$(date): $(dig example.com MX +short)"
  sleep 300  # Every 5 minutes
done

# Check all record types
for type in A AAAA MX TXT NS; do
  echo "$type records:"
  dig example.com $type +short
done

Interpreting Propagation Data

What you're looking for:

100% of checkers:        NEW RECORD (fully propagated)
75-99% of checkers:      NEW RECORD (almost there)
50-74% of checkers:      NEW RECORD (in progress)
25-49% of checkers:      NEW RECORD (early stages)
1-24% of checkers:       NEW RECORD (just started)
0% of checkers:          OLD RECORD (not propagated)

Typical Propagation Times by Scenario

Scenario 1: A Record Change (IP Update)

Timeline:

• Immediate: Authoritative server has new data
• 5-15 minutes: Major resolvers see new data
• 15-60 minutes: Most users see new data
• 1-4 hours: Significant majority (95%+) see new data
• 4-24 hours: Practically complete

Example:

Changed: example.com A record from 192.0.2.1 to 192.0.2.2
Time:
- 0 min: Change made
- 5 min: You can see new IP with your nameserver
- 15 min: Major ISP resolvers see new IP
- 60 min: 90% of population sees new IP
- 4 hours: 99%+ of population sees new IP

Scenario 2: MX Record Change (Email Server Update)

Timeline:

• Similar to A record changes
• Mail servers may have cached old MX records
• Some emails might deliver to old mail server for 24 hours
• Recommends: Keep both old and new mail servers running during migration

Scenario 3: Nameserver Change

Timeline:

• Slower than typical DNS record changes
• Involves registrar-level changes
• Registrars notify root nameservers
• Can take 24-72 hours for global distribution
• Some edge cases may take longer

Example:

Changed: Nameservers from old-ns.example.com to new-ns.example.com
Timeline:
- 0-30 min: Change registered at registrar
- 30 min-4 hours: Root nameservers updated
- 4-24 hours: Significant propagation
- 24-72 hours: Near-complete propagation

Scenario 4: CNAME Change

Timeline:

• Similar to A records
• Systems may cache CNAME resolution
• Propagation usually within 4 hours

Preparing for DNS Changes

Pre-Change Preparation

1 day before change:

# Lower TTL to speed propagation
# Change from 3600 to 300 seconds
# This ensures old data clears quickly

# Update your DNS record TTL first
# Wait 24 hours for old TTL to expire

# Example:
# Day 1: Reduce TTL from 3600 to 300
# Day 2: Make the actual change
# Day 3: Optional - increase TTL back to 3600

Communicate changes:

• Notify users of expected propagation time
• Set expectations: "Changes may take up to 24 hours globally"
• Provide status updates via social media

During Propagation

Monitor consistently:

# Check propagation every 15-30 minutes
# Use online tools to see global status
# Document when different locations update

Keep old resources running:

• If migrating to new IP, keep old IP responding briefly
• If changing mail servers, keep old server accepting mail
• Prevents service disruption during propagation

Post-Propagation

Verify completion:

# Check major resolvers
dig @8.8.8.8 example.com A
dig @1.1.1.1 example.com A
dig @208.67.222.222 example.com A

# Check from various geographic locations
# Use online propagation checkers

Common Propagation Issues

Issue 1: Slow Propagation (Stuck at 50%)

Possible causes:

• High TTL value still being honored
• Some resolvers caching beyond TTL
• Nameserver issues
• Registrar not updating properly

Solutions:

# Verify change at authoritative nameserver
dig @authoritative.nameserver.com example.com A

# Check if registrar properly updated
# Wait for old TTL to expire
# Try changing from different location

Issue 2: Inconsistent Results (Some See New, Some See Old)

Expected during propagation: This is normal intermediate state

Solutions:

• Use different DNS resolvers for different purposes
• Wait for complete propagation before declaring change complete
• Don't assume change is broken—it's likely still propagating

Issue 3: Propagation Doesn't Seem to Complete

Check:

# Is your change actually saved?
# Check with authoritative nameserver
dig @ns1.yourdns.example.com example.com A

# If authoritative has old data, change didn't save
# If authoritative has new data, it's a caching issue

Speeding Up Propagation

1. Lower TTL Before Change

Reduces old data cache duration:

24 hours before change:
- Set TTL to 300 (5 minutes)
- Wait 24 hours
- Make change
- New data propagates within hours
- After propagation complete, restore TTL to 3600

2. Use Multiple Record Types

Support both old and new simultaneously:

# During MX server migration
example.com    MX    10    old-mail.example.com
example.com    MX    20    new-mail.example.com

# Phase 1: Both servers running
# Phase 2: When propagated, increase priority of new server
example.com    MX    5     new-mail.example.com
example.com    MX    20    old-mail.example.com

# Phase 3: When certain all propagated, remove old
example.com    MX    10    new-mail.example.com

3. Use Global DNS Services

CDN/DNS services often propagate faster:

• Cloudflare DNS (can have hundreds of servers)
• Route53 (AWS global infrastructure)
• Google Cloud DNS (Google's infrastructure)

4. Pre-create Records

Add new records with low TTL before removing old:

# Pre-creation (few days before)
example.com    A    300    192.0.2.2  # New IP, low TTL

# Later
example.com    A    300    192.0.2.1  # Old IP still active

# When ready to switch
# Remove old, keep new

# New IP already cached in many resolvers
# Results in faster actual switch

Propagation and Business Impact

Planned Maintenance

When planning DNS changes:

• Schedule changes early in day
• Allow 4-8 hours for primary propagation
• Expect some users on old data for 24 hours
• Monitor for issues during propagation
• Keep old resources available during propagation window

Email Server Migration

Email is particularly sensitive:

• Emails to old MX still deliver for 24 hours
• Set up mail forwarding on old servers
• Run old and new mail servers in parallel
• Don't disconnect old server until certain propagation complete

Service Migration

When migrating services:

• Create temporary DNS records with low TTL
• Run new service in parallel
• Monitor both simultaneously
• Keep old service available 24 hours after DNS change
• Document which users are seeing which service

Best Practices

1. Lower TTL 24 hours before change
2. Monitor propagation globally
3. Keep old resources running during propagation
4. Document changes and propagation time
5. Notify affected users proactively
6. Verify propagation completion before decommissioning old systems
7. Test critical functionality during propagation

Conclusion

DNS propagation takes 24-48 hours for complete global distribution, but most users see changes within 4 hours. By understanding propagation mechanics, preparing properly, and monitoring progress, you can minimize service disruption and ensure smooth transitions.

The key to successful DNS changes is planning ahead, lowering TTL values before changes, running old and new systems in parallel during propagation, and maintaining realistic expectations about distribution timing.

Whether managing a simple A record change or complex infrastructure migration, proper propagation management is essential to preventing service disruptions and maintaining customer trust.