DNS Propagation

What is DNS Propagation?

DNS propagation refers to the time it takes for changes made to DNS records to be recognized across the entire internet. When you update DNS records (changing nameservers, updating A records, modifying MX records), the changes don't take effect instantly—they must propagate through the hierarchical DNS system as caches expire and refresh.

Understanding "Propagation"

The term "propagation" is somewhat misleading—DNS changes don't actively "propagate" or spread. Instead:

1. You update records at your authoritative nameserver

2. Cached copies expire based on TTL (Time To Live)

3. New queries fetch updated records from authoritative servers

4. Old cached copies continue serving until TTL expires

It's more accurate to say "DNS cache expiration" than "propagation," but the term propagation is widely used.

How DNS Changes Work

The Update Process

Step 1: Update DNS records
        example.com A record: 203.0.113.50 → 203.0.113.51

Step 2: Authoritative nameserver immediately serves new record

Step 3: Existing cached copies remain valid until TTL expires

Step 4: New queries after TTL expiration receive updated record

Step 5: All caches eventually expire and refresh
        → "Propagation complete"

Timeline Example

Time: 10:00 - DNS updated (TTL: 300s / 5 minutes)

Resolver A (cached at 09:58):
  09:58 - Cached old IP, expires 10:03
  10:03 - Cache expires, queries again, gets new IP

Resolver B (cached at 10:01):
  10:01 - Cached old IP, expires 10:06
  10:06 - Cache expires, queries again, gets new IP

Resolver C (queries at 10:05):
  10:05 - No cache, queries immediately, gets new IP

All resolvers have new IP by: 10:06
Propagation time: 6 minutes (worst case based on TTL)

Factors Affecting Propagation Time

TTL (Time To Live)

The single most important factor:

Nameserver Changes

Changing nameservers takes longer than other DNS changes:

Registry Level: 24-48 hours (TLD nameserver cache)
Resolver Level: Based on NS record TTL
Total Time: Up to 48 hours worst case

ISP and Resolver Behavior

Not all DNS resolvers respect TTL values:

• Strictly respect TTL
• Fast propagation

• May ignore low TTLs
• Cache longer than specified
• Can delay propagation by hours

Geographic Distribution

Different regions update at different times based on local resolver cache:

North America: 10:05 - Updated
Europe: 10:08 - Updated
Asia: 10:12 - Updated

Client-Side Caching

Even after DNS servers update, local caches may retain old values:

• Browser cache: 60 seconds typically
• OS cache: Minutes to hours
• Application cache: Varies by app

Checking DNS Propagation

Online Propagation Checkers

curl "https://domscan.net/v1/health?domain=example.com"
# Shows current DNS configuration

Command Line Checks

# Google DNS
dig @8.8.8.8 example.com

# Cloudflare DNS
dig @1.1.1.1 example.com

# Your ISP (no @ server specified)
dig example.com

# Compare results

# Find nameservers
dig example.com NS

# Query authoritative NS directly
dig @ns1.example.com example.com

This shows the "truth" immediately—no cache involved.

Check from Multiple Locations

# Using curl with DNS over HTTPS
curl -H 'accept: application/dns-json'   'https://cloudflare-dns.com/dns-query?name=example.com&type=A'

Minimizing Propagation Time

Before Making Changes

Old: example.com.    3600    IN    A    203.0.113.50
New: example.com.    300     IN    A    203.0.113.50
                     ^^^
                     Reduced to 5 minutes

Wait full duration of old TTL (3600s = 1 hour)

example.com.    300    IN    A    203.0.113.51

Check resolvers globally

example.com.    3600    IN    A    203.0.113.51

During Changes

Common Propagation Scenarios

Changing A Record

# Before
example.com → 203.0.113.50

# After
example.com → 203.0.113.51

# Propagation: 1x TTL duration

Changing MX Record

Changing Nameservers

Why so long?
TLD registry caches NS records
Registry TTL often 24-48 hours
No control over registry cache

Adding New Subdomain

If subdomain was queried and didn't exist:
→ NXDOMAIN cached (SOA minimum TTL)
→ New subdomain won't resolve until cache expires

Troubleshooting Propagation Issues

Change Not Propagating

dig @ns1.example.com example.com
# Should show new value

dig example.com | grep -i ttl

dig example.com SOA
# Look at minimum TTL field

Clear browser, OS, and application caches

Partial Propagation

Propagation Stuck

1. Verify authoritative nameserver is correct

2. Contact ISP if persistent

3. Users can switch to public DNS (8.8.8.8, 1.1.1.1)

DNS Propagation vs Cache TTL

Best Practices

1. Lower TTL before changes: Reduce TTL 24-48 hours before DNS updates

2. Use appropriate TTLs: Balance performance (high TTL) vs flexibility (low TTL)

3. Monitor globally: Check DNS from multiple geographic regions

4. Keep old services running: Maintain previous servers until propagation complete

5. Document changes: Track what changed and when for troubleshooting

6. Test thoroughly: Verify new DNS records work before switching

7. Communicate with users: Warn of potential brief disruptions

8. Use managed DNS: Providers with anycast networks minimize propagation time

9. Automate monitoring: Set up alerts for DNS changes and propagation status

10. Have rollback plan: Know how to revert changes if issues arise

Propagation Checklist

☐ Lower TTL 24-48 hours before change
☐ Wait for old TTL to expire
☐ Make DNS change
☐ Verify on authoritative nameservers
☐ Check multiple public resolvers
☐ Test from multiple geographic locations
☐ Monitor for 2x TTL duration
☐ Verify no errors reported
☐ Restore higher TTL if desired
☐ Document change completion

DNS propagation is a natural consequence of DNS caching—understanding TTL behavior and planning changes accordingly ensures smooth, predictable updates with minimal disruption.