How to Check DNS Propagation

You just updated your domain's A record to point to a new server. You hit refresh in your browser — and you're still seeing the old site. This is DNS propagation delay: the time it takes for your DNS change to spread across the internet's resolver network. This guide explains why propagation isn't instant, how to check if your changes have propagated, and how to troubleshoot when they haven't.

What Is DNS Propagation?

DNS propagation is the process by which updated DNS records spread from your authoritative nameserver to recursive resolvers worldwide. When you change a DNS record at your registrar or DNS host, you're updating the authoritative nameserver. But the internet doesn't query the authoritative nameserver for every single request — that would be impossibly slow. Instead, recursive resolvers (run by ISPs, Google, Cloudflare, etc.) cache DNS records and serve them to users. Your change only becomes "live" for a user when their resolver's cached copy expires and it fetches the new record.

Key insight: DNS changes don't "propagate" from your nameserver outward. They sit on the authoritative nameserver, and resolvers pick them up when their cached copy (the TTL) expires. This is why some users see the new IP immediately (their resolver didn't have it cached) while others wait hours.

How DNS Propagation Actually Works

Understanding TTL (Time to Live)

TTL is the single most important factor in DNS propagation speed. It tells every resolver "cache this record for X seconds before checking for updates." A record with TTL 3600 (1 hour) means a resolver that queried it 10 minutes ago will keep serving the old value for another 50 minutes — no matter what you do.

Method 1: Check Propagation With Our DNS Lookup Tool

Method 2: Command-Line Multi-Resolver Check

The gold standard for checking propagation: query the same record against multiple public DNS resolvers and compare results. If all return your new value, propagation is complete. If some return the old value, those resolvers' caches haven't expired yet.

# Check your domain against 5 major public resolvers
dig example.com A @8.8.8.8 +short       # Google
dig example.com A @1.1.1.1 +short       # Cloudflare
dig example.com A @9.9.9.9 +short       # Quad9
dig example.com A @208.67.222.222 +short # OpenDNS
dig example.com A @94.140.14.14 +short   # AdGuard DNS

# Check the SOA serial number — should increment with each zone change
dig example.com SOA +short

nslookup example.com 8.8.8.8
nslookup example.com 1.1.1.1
nslookup example.com 9.9.9.9

Method 3: Online Propagation Checkers

Several free online tools check your domain against 20–100+ DNS servers worldwide and show a map or table of results. These are useful for a visual overview but have limitations: they typically only check A records, may be rate-limited, and some are ad-heavy. Use them as a supplement to direct lookups, not a replacement.

How Long Does DNS Propagation Actually Take?

The honest answer: it depends on your TTL and the resolver. But here are realistic estimates based on real-world experience:

The 24–48 hour warning that registrars give is a conservative worst-case number. In practice, for standard A/CNAME changes with reasonable TTLs, most of the world sees the update within 30–60 minutes. NS and registry-level changes (DNSSEC, glue records) genuinely can take 24+ hours.

Factors That Affect Propagation Speed

1. TTL value — The #1 factor. A TTL of 300 means resolvers cache for 5 minutes; 86400 means 24 hours.
2. TTL before the change — If you didn't pre-lower TTL, existing cached entries must expire naturally. The resolver that cached your record 55 minutes ago with a 3600 TTL will wait another 5 minutes before re-querying.
3. Resolver cache-warming — Popular domains may be "pinned" in resolver caches beyond TTL (some ISPs ignore TTL). This is rare but happens with major ISPs in certain regions.
4. Negative caching — NXDOMAIN (domain doesn't exist) responses can be cached based on the SOA minimum TTL. If someone queries before your domain exists, they may get an NXDOMAIN cached for hours.
5. DNSSEC chain — Signed zones have additional caching layers (RRSIG records have their own expiry). DNSSEC validation can add propagation latency.
6. Registry-level delays — NS record changes at the TLD registry level (.com, .org, .io) are batched and can take 20 minutes to 6 hours to be published to the root zone.

Common Propagation Scenarios & Solutions

Scenario 1: "I changed my A record but I still see the old site"

Most likely: local DNS cache, not propagation. Before blaming propagation, follow this checklist in order:

1. Clear your DNS cache (OS + browser)
2. Open a private/incognito browser window and try again (bypasses browser DNS cache)
3. Use our DNS Record Lookup to check what Google DNS sees
4. If Google DNS shows the new IP, propagation is working — the issue is your local cache or ISP resolver
5. If Google DNS still shows the old IP, check the SOA serial to confirm the update was actually applied at your DNS host

Scenario 2: "Some users see the new site, others see the old one"

This is classic mid-propagation behavior. Some ISPs' resolvers have fetched the new record; others are still serving cached old data. Solution: wait. Verify with a multi-resolver check (Method 2 above) to track which resolvers have updated. Most stragglers catch up within 2× TTL.

Scenario 3: "I changed nameservers and nothing works"

Nameserver changes are the slowest DNS operation. The TLD registry must update the NS glue records, then every resolver must discover the new delegation path. Timeline:

• 0–2 hours: Registry publishes the new NS records
• 2–24 hours: Major resolvers pick up the new delegation
• 24–72 hours: Full global convergence

During this window, it's normal for some queries to hit old nameservers and others to hit new ones. Never delete your old DNS hosting until propagation is confirmed complete — keep both old and new zones identical during the transition.

How to Speed Up DNS Propagation

You can't force the world's resolvers to update faster, but you can minimize the impact of propagation delay:

1. Pre-lower TTL before changes. Days before a planned migration, set TTL to 300. Wait for the old TTL to expire, then make the record change. Propagation completes in 5 minutes instead of hours.
2. Use the lowest practical TTL during transition. 60 seconds is fine for short maintenance windows. Most DNS hosts support TTL as low as 30 seconds (Cloudflare's lowest is 30s on paid plans, 120s on Free).
3. Set up both old and new IPs during cutover. If possible, run both servers simultaneously and switch traffic via a load balancer or reverse proxy. Then switch DNS after the infrastructure is confirmed working.
4. Use a CDN with instant purging. Cloudflare, Fastly, and other CDNs can route traffic to new origins instantly via their control panel — no DNS propagation wait. After confirming the new origin works, update DNS at your leisure.
5. Flush your cache aggressively. You can't flush ISP caches, but you can clear your own DNS cache at every layer (OS + browser + router) so at least you see the new results.

FAQ