Checking DNS Propagation

When you change a DNS record, nothing pushes that change out to the Internet. There's no propagation mechanism, no broadcast, no update signal. Your authoritative nameserver simply starts answering differently when asked.

The rest of the Internet finds out gradually, as cached copies of your old record expire and get replaced. This process—cached records dying and being reborn with new values—is what we call DNS propagation. Understanding it means understanding that you're not waiting for something to happen. You're waiting for thousands of independent caches to forget what they knew.

The Mechanics of Forgetting

Every DNS record has a TTL (Time To Live) measured in seconds. When a DNS server caches your record, it sets a timer. When the timer hits zero, the cached record dies. The next query triggers a fresh lookup from your authoritative nameserver.

This means propagation time is determined by your old TTL, not your new one. If your A record had TTL=86400 (24 hours) and you change it, some server somewhere cached that record 23 hours and 59 minutes ago. It won't check for updates for another minute. Another server cached it 5 minutes ago—it won't check for 23 hours and 55 minutes.

There's no way to reach into those caches and update them. You wait.

Planning for Fast Changes

If you know a DNS change is coming, lower your TTL first:

# Current state: TTL is 86400 (24 hours)
# One week before migration, change TTL to 300 (5 minutes)
# Wait 24 hours for old cached records to expire
# Now every cache has the 5-minute TTL
# Make your actual change—it propagates in minutes

This is why DNS migrations happen in two phases: lower the TTL and wait, then make the change. Skip the first phase and you're at the mercy of whatever TTL was set before.

Checking Propagation: Interrogating Witnesses

Checking propagation is detective work. You're asking DNS servers around the world what they know, and each one last checked at a different time. Some have current information. Some are remembering yesterday.

The Authoritative Truth

First, establish what the truth actually is. Find your authoritative nameservers:

dig NS example.com +short

Then ask one directly:

dig @ns1.example.com example.com

This is the official answer. If your change doesn't appear here, it wasn't saved correctly. Everything else is downstream.

Sampling the World

Query public DNS servers to see what users see:

# Google's view of truth
dig @8.8.8.8 example.com

# Cloudflare's view
dig @1.1.1.1 example.com

# OpenDNS's view
dig @208.67.222.222 example.com

If they disagree, propagation is in progress. If they all show the new value, you're mostly done—though edge cases always exist.

Visual Tools

DNS Checker and What's My DNS query from dozens of global locations and show results on a map. Green means updated, red means stale. You see propagation spreading like weather patterns across continents.

Watching the Clock

The TTL in a response tells you when that cache will expire:

example.com.            247   IN      A       93.184.216.34

That 247 means this cache has 247 seconds left to live. Query again in a minute—the number shrinks. When it hits zero, the next query fetches fresh data.

Clearing Your Own Cache

Your machine caches DNS too. Before testing, flush it:

macOS:

sudo dscacheutil -flushcache; sudo killall -HUP mDNSResponder

Linux:

sudo systemd-resolve --flush-caches

Windows:

ipconfig /flushdns

Otherwise you're interrogating your own memory, not the Internet.

When Propagation Stalls

If hours pass and some servers still show old values:

Verify the change exists. Query your authoritative nameserver. If it shows the old value, the change wasn't saved.

Check you're querying the right thing. The A record for example.com is different from the A record for www.example.com. AAAA is different from A.

Wait for the old TTL. If the previous TTL was 86400, you might wait 24 hours. There's no shortcut.

Check nameserver changes separately. If you changed nameservers (not just records), propagation goes through TLD servers, which have their own TTLs—often 24-48 hours.

Look for DNSSEC issues. If signatures don't match the new records, some resolvers reject the response entirely.

Why Some Caches Misbehave

Not every DNS server respects TTL:

• Some ISPs cache aggressively regardless of what you specify
• Layered caching means your query passes through multiple caches, each with its own timer
• Negative caching remembers "doesn't exist" responses—if someone queried before your record existed, that absence might be cached
• Misconfigured servers serve stale data past expiration

These edge cases are why "propagation complete" is probabilistic, not absolute. For 99% of users, it's done. For that one person on a misbehaving ISP, it might take longer.

During the Transition

Keep old services running. Until propagation completes, some users hit old DNS records. If the old server is down, they get errors.

Test before switching. Access your new service by IP or hosts file before changing DNS. Verify it works before users arrive.

Save old records. If something breaks, you need to know what to roll back to.

Change one record at a time. If multiple things break simultaneously, you can't isolate the cause.

The "48-72 Hours" Myth

You'll hear that DNS propagation takes 48-72 hours. This was true when TTLs were commonly set to 24 hours and nameserver changes were more frequent. For modern DNS with reasonable TTLs:

• Record changes with 5-minute TTL: 5-15 minutes
• Record changes with 1-hour TTL: 1-2 hours
• Record changes with 24-hour TTL: Up to 24 hours
• Nameserver changes: 24-48 hours (TLD cache TTLs)

The 48-72 hour figure is a worst-case buffer, not a technical requirement.

Monitoring Script

while true; do
  echo "=== $(date) ==="
  for dns in 8.8.8.8 1.1.1.1 208.67.222.222; do
    echo "$dns: $(dig @$dns +short example.com)"
  done
  echo
  sleep 300
done

Run this during a migration. Watch the values converge.