DNS Propagation Checker

DNS propagation, honestly

"DNS propagation" is a slightly misleading term that everyone uses anyway. What actually happens when you change a DNS record isn't propagation in the pushed-out sense — nobody is pushing anything to global resolvers. Instead, resolvers around the world hold cached copies of DNS records for the TTL duration specified by the authoritative server. When their cached copy expires, they query the authoritative server and get the current value. The "propagation" people talk about is really "resolvers all over the world separately noticing the change as their caches expire."

This tool queries eight public resolvers positioned in different geographic regions and networks. If a record's authoritative value has changed and you want to know how many resolvers have picked up the change, you look at what each returns. Agreement across all eight means the change has propagated to at least those eight; disagreement tells you which resolvers still have stale caches.

Why so many resolvers?

Any single resolver is only one data point. Cloudflare's resolver might refresh its cache before Google's. Google's might refresh before Quad9's. Quad9's might refresh before regional resolvers in Asia or Europe. Querying just one resolver gives you one perspective; querying eight gives you eight independent perspectives from different networks in different regions.

The eight I chose for this tool cover major public resolvers used by hundreds of millions of users worldwide:

• Cloudflare (1.1.1.1): US-based, one of the largest public resolvers. Fast and generally accurate.
• Google (8.8.8.8): US-based, the largest public resolver by user count. Highly reliable.
• AdGuard (94.140.14.14): European-based, ad-blocking resolver.
• NextDNS (45.90.28.0): European-based, privacy-focused with custom filtering.
• DNS.SB (185.222.222.222): European operator running open resolvers.
• Alibaba (223.5.5.5): Chinese resolver, useful for checking propagation to Asia.
• Tencent (119.29.29.29): Another major Chinese resolver.
• FlatusLifir (91.239.100.100): Icelandic operator, checks European-Nordic propagation.

Different resolvers use different upstream authoritative queries and different cache-management strategies. This is why they don't all update at the same time even for the same record — each is independently deciding when to refresh based on TTL and its own cache management.

What TTL actually means for propagation timing

The TTL (Time To Live) on a DNS record tells resolvers how long they can cache the value before checking again. TTL is set by the authoritative server and included in every response.

Short TTLs (300 seconds or less)

Changes propagate within about the TTL duration. Resolvers refresh often. Fast propagation but high load on authoritative servers.

Standard TTLs (3600 seconds = 1 hour)

Changes take up to an hour to fully propagate. Reasonable balance between authoritative load and propagation speed. Most production domains use this range.

Long TTLs (86400 seconds = 1 day)

Changes take up to a day to fully propagate. Very low authoritative load but slow propagation. Used for records that essentially never change.

TTL prep: the professional pattern

Before a planned DNS change, professional operators drop the TTL to something small (300 seconds) at least 24 hours before the change. This lets resolvers observe the lower TTL and start honoring it. Then the actual change is made, and propagation completes quickly (within minutes rather than hours). After propagation is complete, the TTL can be raised back to a normal value.

This is the sequence:

1. T-24h or more: reduce TTL to 300 seconds
2. T-1h: verify that resolvers are now returning the 300-second TTL (they should be, since 24 hours is much longer than any pre-change TTL)
3. T=0: make the actual change
4. T+30m: verify propagation using a tool like this one
5. T+24h: raise TTL back to normal value

Following this pattern minimizes the propagation window around changes and lets you plan cutover activities with confidence about when the change will be seen globally.

How I use this in real work

Verifying a completed DNS change

After making a DNS change through my registrar or DNS host, I run this tool to confirm the change has propagated. If all eight resolvers return the new value, I'm confident the change is complete globally. If some still return the old value, I wait and check again.

Debugging "it works for me but not for a user"

A customer reports that a website they run doesn't work for a specific user in another country. Running the propagation check often shows that the resolver in that user's region has an old cached value while other regions have the new value. The user's problem will resolve itself as the cache expires, but I can explain the timeline while it does.

Confirming NS record changes

When a domain moves from one DNS provider to another, the NS records change at the registry level. Waiting for propagation of NS changes is often the slowest part of a DNS migration because NS records typically have long TTLs. This tool lets me see which resolvers have picked up the new NS records and are now querying the new authoritative servers.

Detecting DNS injection or redirection

If two resolvers in different jurisdictions return radically different answers for the same domain, and the difference isn't explained by propagation timing, that might indicate DNS injection — a middleman is manipulating the response for one user population. Rare but happens, especially with government censorship or network operator interference. This tool would show the disagreement clearly.

Confirming a new subdomain is live

After creating a new subdomain, verify it resolves everywhere before pointing users at it. Nothing worse than announcing a new service and having half your customer base see NXDOMAIN because their resolver hadn't updated.

What the different record types show

A records

The IPv4 address for a hostname. Most common query. Every browser needs to resolve A records to reach any website.

AAAA records

The IPv6 address. If a hostname has both A and AAAA, dual-stack clients typically prefer IPv6. Missing AAAA on a site that should support IPv6 breaks connectivity for IPv6-only clients (a growing minority).

MX records

Where to send email for the domain. Multiple MX records with priorities allow failover. Wrong or missing MX means email delivery breaks. See the Email Health Check for deeper email-focused analysis.

TXT records

Free-form text used for many purposes: SPF, DMARC, domain verification for various services (Google Workspace, Microsoft 365, GitHub, etc.). A single domain might have a dozen TXT records for various purposes.

CNAME records

An alias from one name to another. When a resolver looks up a CNAME, it follows the alias to get the actual A or AAAA. Common for CDN configurations where a customer's domain points to the CDN's endpoint via CNAME.

NS records

Which name servers are authoritative for the domain. Querying NS records tells you where the "official" copy of the domain's DNS lives. NS records are usually consistent globally because they come from the parent zone (the registry) rather than from the domain itself.

Common propagation patterns

All resolvers return the same value

Fully propagated. What you see is what the world sees.

US resolvers updated, non-US resolvers still show old value

Common pattern. US-based Cloudflare and Google often update first because they aggressively refresh popular domains. International resolvers follow within their own TTL cycles.

Same resolver returns different values on repeated queries

Load-balanced anycast resolvers can hit different back-end caches. Repeating the query a few times reveals whether the difference is transient (some backends have new value, others have old) or persistent.

All resolvers return NXDOMAIN

The domain doesn't exist, or the record doesn't exist. Check with WHOIS to verify the domain is registered and hasn't expired. Check the authoritative NS records to see if the domain's DNS is pointed correctly.

Some resolvers timeout while others answer

Individual resolvers can have transient outages. Not usually a persistent problem, but if a resolver consistently doesn't answer for your queries, something is wrong on that resolver's side or the network path to it.

Related tools

For a broader view of a domain's full DNS record set (not just one record type across resolvers), use the DNS Lookup tool. For domain registration data (registrar, expiry, nameservers), use the WHOIS Lookup.

For a complete "who runs the infrastructure for this domain" picture combining DNS records with IP ownership, use the Domain Infrastructure Lookup.

Privacy

Queries are made from our Cloudflare Worker to the eight public resolvers. Each resolver sees a query originating from Cloudflare's network, not from your device. Results are shown to you only. Nothing beyond the standard analytics is retained about queries you make.