DNS Propagation Checker

Check DNS propagation across multiple global resolvers. See which locations have picked up your DNS changes.

What DNS "Propagation" Really Is (and Isn't)

"Propagation" is a slightly misleading name, because nothing is actually being pushed anywhere. DNS is a pull-based system: when you update a record, your authoritative nameservers start answering with the new value immediately. The delay you experience comes entirely from caching — every recursive resolver on the internet that looked up your domain before the change is still holding the old answer, and it will keep serving that answer until the record's TTL (Time To Live) counts down to zero. There is no mechanism to notify those resolvers early; the old data simply has to expire.

This is why the single most effective migration technique happens before the change, not after it. If your record carries a TTL of 86400 seconds, some resolver somewhere may serve the stale value for a full day. Lower the TTL to 300 seconds 24-48 hours in advance — long enough for the old, high TTL to expire everywhere — and the actual cutover completes in minutes for virtually all users. Once you have confirmed the new values are stable, raise the TTL back up so resolvers are not hammering your nameservers unnecessarily.

One less obvious wrinkle is negative caching. If a resolver looks up a record that does not exist yet — say, a subdomain you are about to create — it caches the "no such record" answer too, for a duration controlled by your zone's SOA record. So querying a brand-new hostname before you have created it can actually delay when that resolver picks it up. When staging a launch, create the records first and test second, and remember that each resolver's cache is independent: seeing the new value on Google's 8.8.8.8 tells you nothing about what your office ISP resolver is still holding.

The Factors That Decide How Fast You See Changes

TTL (Time To Live)
The number of seconds a resolver may cache a record. It is the only knob you control that directly determines propagation speed — set it low before changes, higher for stability.
Authoritative vs recursive
Authoritative servers hold the source-of-truth zone data; recursive resolvers (your ISP, 8.8.8.8) fetch and cache it for users. Only the recursive layer causes propagation delay.
NS changes at the registry
Switching nameservers updates the delegation at the TLD registry, and registries typically publish those NS records with 24-48 hour TTLs — much slower than editing records in an existing zone.
Testing with dig
dig example.com @8.8.8.8 and dig example.com @1.1.1.1 query specific resolvers directly, letting you compare cached answers against your authoritative servers without waiting.
Flushing local caches
Your OS, browser, and router each cache DNS too. ipconfig /flushdns (Windows) or resolvectl flush-caches (Linux) clears the local layer when your machine seems stuck on old data.
Why regions differ
Each resolver cached your record at a different moment, so their TTL countdowns expire at different times. Geographic inconsistency during a change window is normal, not a fault.

Frequently Asked Questions

What is DNS propagation?

DNS propagation is the process of updating DNS records across all resolvers worldwide after a change is made. When you update a DNS record, the change starts at authoritative nameservers and gradually spreads to cached resolvers globally. This can take anywhere from minutes to 48 hours depending on TTL values.

Why do some locations see different DNS results?

DNS resolvers cache records based on TTL (Time To Live) values. If a resolver has cached the old record, it will serve that until the TTL expires. Different ISPs and resolver networks have different update schedules, causing geographic inconsistency during propagation.

How long does DNS propagation take?

Propagation time depends on the TTL set on the old record. A TTL of 3600 seconds (1 hour) means resolvers may hold the old value for up to an hour. Lower TTLs (300s) speed up propagation. For urgent changes, lower your TTL 24-48 hours before making the change.

Why is my DNS change not propagating?

Common reasons: high TTL on old records, ISP-level caching (some ISPs ignore TTL), misconfigured authoritative nameservers, or propagation is still in progress. Check that your authoritative nameservers are serving the correct records first using nslookup or dig.

Can I speed up DNS propagation after making a change?

Not directly — DNS is pull-based, so there is no way to push a new record to resolvers that still hold a cached copy. The only reliable lever is lowering the TTL 24-48 hours before you make the change so caches expire quickly afterwards. After the fact, you can purge specific public resolvers (Google and Cloudflare both offer cache-flush pages) and flush your own OS and router caches, but the rest of the internet simply waits out the old TTL.

Why does my ISP still show the old record when Google DNS shows the new one?

Your ISP's recursive resolver cached the old record before your change and will keep serving it until its copy expires. Some ISP resolvers also enforce a minimum cache time and effectively ignore very low TTLs, which stretches this window further. Querying 8.8.8.8 or 1.1.1.1 directly is the standard way to confirm the authoritative data is correct while your ISP's cache catches up.

How long do nameserver (NS) changes take compared to normal record changes?

Changing A, CNAME, or MX records on your existing nameservers follows the TTL you set, so it can complete in minutes. Changing the nameservers themselves is slower because the delegation lives at the TLD registry, and registries commonly publish NS records with TTLs of 24-48 hours. During that window some resolvers query the old nameservers and some the new, so keep identical zone data on both until the transition is complete.

What TTL should I set on my DNS records?

For records that may need to change quickly — load balancer failover, migrations in progress — 300 seconds (5 minutes) is a sensible floor. For stable records like MX or verification TXT entries, 3600 to 86400 seconds reduces resolver load and lookup latency. A common operational pattern is to run comfortable TTLs day-to-day, drop to 300 a day or two before a planned change, then raise them again once you have verified the new values everywhere.

Get Notified When DNS Records Change

CertNotify monitors your DNS records around the clock and alerts you the moment something changes unexpectedly — before a bad propagation turns into an outage.

Related Free Tools