DNS Propagation Checker
Check DNS propagation across five public resolvers, queried from our server in one region. See which resolvers 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
How to Read These Results
The checker sends the same query to five public resolver networks at once and compares each answer with the current value of the record. By default that is what your domain's own authoritative nameserver says — it holds the new value from the moment you save it — or, if you enter one, the value you expect. A resolver shows Current value when everything it returns matches and No record when it has nothing. When you entered the value you expect, a resolver serving anything else shows Old value — the definitive check after a change. Compared only with your nameserver, a mismatch shows as Differs from nameserver instead, because CDN and geo DNS records legitimately answer differently depending on who asks. A resolver returning only some of a set of addresses still counts as current: CDNs hand out rotating subsets.
Second, all five are anycast networks, queried from our server. Each answer comes from whichever node of that network is nearest to us, so this is a comparison of five independent caches rather than a reading from five countries. That is usually what you need — if Google, Cloudflare and Quad9 all serve the new value, the authoritative data is right and the remaining delay is other caches running down their TTL — but it cannot tell you what a particular ISP in a particular city still holds.
When a resolver shows No record or Query failed, the result column says why:
| Result | What it means |
|---|---|
| ENOTFOUND | NXDOMAIN: the resolver was told this name does not exist. For a record you just created, it may be a cached "does not exist" from an earlier lookup, which lasts as long as the zone's SOA negative-caching time. |
| ENODATA | The name exists but has no record of this type. Common when checking CNAME on a name that holds A records, or AAAA on a site with no IPv6. |
| ESERVFAIL | The resolver could not get a usable answer. Usually the authoritative servers are unreachable or misconfigured, or the zone's DNSSEC signatures fail to validate. |
| ETIMEOUT | No reply within four seconds. Try again before reading anything into it; one timeout from one network is not a DNS fault. |
| EREFUSED | The server declined to answer the query. Rare from public resolvers, and usually temporary. |
How to Check DNS Propagation Yourself
The reliable method has three steps, and the first is the one most people skip: confirm the change is actually live at the source before waiting on anyone's cache.
1. Ask your authoritative nameserver
Find the nameservers the domain delegates to, then ask one of them directly. +norecurse makes sure you get its own data rather than a cached copy.
dig NS example.com +short dig www.example.com A @ns1.your-dns-host.net +norecurse
If this still shows the old value, no amount of waiting will help — the change was never published, or was made somewhere that is not authoritative. The classic case is editing records at a registrar whose DNS the domain no longer uses, because the nameservers point at Cloudflare or a hosting provider instead.
2. Ask the public resolvers what they have cached
dig www.example.com A @8.8.8.8 +noall +answer dig www.example.com A @1.1.1.1 +noall +answer # Windows nslookup -type=A www.example.com 8.8.8.8 Resolve-DnsName www.example.com -Type A -Server 1.1.1.1
The second column of the dig output, and the TTL column of Resolve-DnsName, is the time in seconds before that resolver will ask again. If it shows the old value with 40 seconds left, you know when it will change. Large anycast networks run many separate caches, so two queries in a row can report different remaining times.
3. For nameserver changes, ask the registry
A nameserver change is published by the TLD registry, not by your DNS host. Asking a registry server shows the delegation it hands out, and +trace follows the whole path from the root:
# .com and .net delegations dig NS example.com @a.gtld-servers.net +norecurse # Every step from the root down dig +trace www.example.com
A registry server refers you onward rather than answering, so the nameservers appear under the AUTHORITY SECTION of the reply rather than the answer. If the registry already lists the new nameservers, the switch is done at the source, and the remaining delay is resolvers holding the old NS set for its TTL. If it still lists the old ones, the change has not been accepted at the registrar yet. Moving a domain that is DNSSEC-signed needs extra care at this point: a DS record left over from the old provider makes validating resolvers reject every answer from the new one, which you can confirm with the DNSSEC checker.
When a Change Will Not Propagate
If the TTL has long since expired and some answers are still wrong, it is almost never propagation. Work through these instead:
- The change was made at the wrong provider. Compare the nameservers from dig NS with the dashboard you edited; they must belong to the same company.
- The record is proxied. Cloudflare and similar services answer with their own edge addresses, so a proxied A record will never show your origin IP to anyone, at any resolver.
- Another record is still answering. An old AAAA record keeps sending IPv6 visitors to the previous server after the A record has moved, and a wildcard record answers for any name you delete, so the name never actually disappears.
- The old TTL was longer than you think. What resolvers honour is the TTL the record had when they cached it, not the lower value you set afterwards. If it was 86400, a day of stale answers is expected.
- Only your machine is stale. If public resolvers show the new value, flush your own cache: ipconfig /flushdns on Windows, sudo dscacheutil -flushcache followed by sudo killall -HUP mDNSResponder on macOS, or resolvectl flush-caches on Linux with systemd-resolved. Browsers keep their own cache too.
- A public resolver is still serving an old answer. Google and Cloudflare both offer a public page to purge a single name from their cache; other resolvers have to be waited out.
For the background on why caches behave this way, including negative caching and how to plan TTLs before a migration, see how long DNS propagation really takes. To look up a single record type on its own, the MX lookup and CNAME lookup explain what each answer means for that type.
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.
Does this checker test DNS from different countries?
No. It queries five public resolver networks — Google, Cloudflare, OpenDNS, Quad9 and Level3 — from our server, and each answers from its nearest node. That compares five independent caches, which is usually enough to confirm a change is live at the source, but it does not show what a specific ISP in a specific country is still serving.
How does the checker know which value is the new one?
It asks your domain's own authoritative nameserver, which serves the new value from the moment you save it, and compares every public resolver with that. You can also enter the value you expect, such as your new IP address, and it compares against that instead. A resolver still serving anything else is shown as Old value.
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
On paid plans CertNotify re-checks your DNS records once a day and alerts you when an A, AAAA, MX or NS record changes, so a bad change is caught within a day rather than when users report it. TXT and CNAME changes are recorded on your dashboard without an alert.