DNS Propagation Checker

How DNS propagation works

DNS propagation refers to the period between when you update a DNS record on your authoritative name server and when all recursive resolvers worldwide have fetched and cached the new value. This delay exists because recursive resolvers cache DNS records for the duration specified by the TTL (Time to Live) value. Until the cache expires, the resolver continues to serve the old record to its users. DNS propagation is not a single event but rather a gradual process as millions of resolvers around the world expire their caches at different times.

When you update a DNS record, the change is immediately visible on your authoritative name server. However, recursive resolvers do not poll for changes — they only query the authoritative server when the cached TTL expires. Each resolver has its own cache state depending on when it last queried the record. Some resolvers may have just cached the old record seconds before you made the change, while others may be close to TTL expiration and will fetch the new record shortly. This explains why propagation appears inconsistent across different resolvers.

The three resolvers checked by this tool — Cloudflare (1.1.1.1), Google Public DNS (8.8.8.8), and AdGuard DNS — are independently operated public DNS services. Cloudflare's resolver handles millions of queries per second and uses anycast routing so that users connect to the nearest data centre. Google Public DNS is the most widely used public resolver, with infrastructure distributed across Google's global network. AdGuard DNS filters queries against known ad and tracking domains by default, giving it a different cache/refresh pattern than Cloudflare or Google. Comparing results across these three providers gives a reliable picture of global propagation status.

Best practices for DNS changes

Making smooth DNS changes requires planning. The single most important step is lowering the TTL on your records before making any changes. If your current TTL is 86400 seconds (24 hours), reduce it to 300 seconds (5 minutes) at least 24 hours before the planned change. This gives resolvers worldwide time to pick up the lower TTL, ensuring that when you make the actual change, old records will expire quickly from all caches. After the change has propagated, increase the TTL back to a longer duration to benefit from caching performance.

When migrating a website to a new host, update the TTL first, then make the DNS change, then use this propagation checker to verify that all three resolvers return the new IP. Keep the old server running and configured to serve the website for at least one full TTL period after the change to handle visitors still hitting the old IP. Monitor traffic to both old and new servers to confirm the transition is complete before decommissioning the old infrastructure.

Some DNS providers offer features that accelerate propagation. Cloudflare's proxied DNS (orange cloud mode) hides the origin IP and provides instant propagation within Cloudflare's network since they act as a reverse proxy. Amazon Route 53 offers alias records that integrate with other AWS services and propagate quickly through AWS's global infrastructure. Regardless of the provider, the fundamental constraint remains the TTL set on the records — lower TTL equals faster propagation.

Common propagation scenarios

Why propagation checking is important

Checking DNS propagation is essential whenever you make changes that affect how users reach your services. Without verification, you risk a situation where some visitors see the new site while others see the old one. This can cause confusion, data integrity issues during form submissions, and lost revenue for e-commerce sites. Systematic propagation checking ensures that your changes are complete and helps identify issues like stale resolver caches, misconfigured authoritative servers, or TTL values that are longer than expected.

This tool checks from three geographically and organisationally distinct resolvers to give you a representative view of global propagation. If all three show the new record, propagation is well underway and likely complete for most users around the world. If results are inconsistent, you can identify where propagation is lagging and whether the issue is isolated to a specific resolver network.

Frequently asked questions