You changed an A record an hour ago. Your laptop shows the new server, a colleague still reaches the old one, and the registrar's help page says "allow up to 48 hours for propagation". What is actually happening is caching: every resolver keeps the answer it last fetched until the TTL runs out, and they all fetched it at different times.
The DNS Propagation Checker sends the same query to a list of public resolvers and puts the answers side by side, with TTLs and response times. Use it after changing records, moving DNS providers or adding verification and email records, to see which resolvers already return the new value and which still serve the old one.
What is DNS propagation?
In simple terms
Nothing is pushed around the internet when you change DNS. Your DNS provider's name servers answer with the new value immediately. The lag comes from the thousands of resolvers (your ISP's, Google's, Cloudflare's, your company's) that cached the old answer and will keep it for as long as its TTL allows. "Propagation" is simply those caches expiring one by one.
Technical background
A recursive resolver that receives a query and has no cached answer asks the authoritative name servers, then stores the result for the TTL the record carries (RFC 1035). While the entry is cached, the resolver answers from memory and counts the TTL down. So the worst case after a change is the old TTL, measured from the moment each resolver cached the record.
Three details explain most surprises:
- Negative caching. "This name does not exist" (NXDOMAIN) and "no record of this type" (NODATA) answers are cached too, for the negative TTL: the lower of the SOA record's minimum field and the SOA TTL (RFC 2308). A record created just after someone looked it up can stay invisible for that period.
- Delegation changes. When you switch DNS provider, the NS records in the parent zone (the TLD) change. Those carry the TLD's TTL, often one to two days, and resolvers keep asking the old provider until they expire. Keep the old zone running and correct during that time.
- Anycast. Large public resolvers announce one IP address from many sites. Each site has its own cache, so the same resolver IP can return different cached ages depending on where you ask from.
Why use the DNS Propagation Checker?
- Know when a change is safe to rely on. Before you shut down an old server, see whether resolvers still hand out its address.
- Explain inconsistent reports. "Works for me, broken for them" is often two resolvers with different cached answers.
- Catch mistakes early. If every resolver returns the old value long after the TTL, the change probably was not made at the provider that is actually authoritative.
- Verify email and verification records. New MX, SPF or SaaS verification TXT records can be confirmed across many resolvers before you click "verify".
- See filtering and geo answers. Filtering resolvers and CDN-backed names show up as deliberate differences, not errors.
Who should use it?
- Administrators and DevOps engineers migrating servers, load balancers or DNS providers.
- Email administrators rolling out MX, SPF, DKIM or DMARC changes.
- Web developers launching or moving a site.
- Support teams handling "the site is down for some users" tickets.
- Anyone who just lowered a TTL and wants to see it take effect.
How the DNS Propagation Checker works
When you press Check DNS, your browser sends the name, the record type and the list of selected resolver IDs to the NetTools.tech server in Latvia. The server validates the request and then queries every selected resolver in parallel:
- One query per resolver (one per type for ALL), with a 3-second timeout and no retry. A resolver that does not answer in time is shown as an error, not retried.
- Fixed resolver list. Only resolvers from the built-in list can be chosen, up to 60 per check; you cannot enter your own resolver IP.
- Validated names. Only public domain names are accepted. Internal TLDs such as
.local,.lanor.internalare rejected. For PTR you enter an IP address and the tool converts it to itsin-addr.arpaorip6.arpaname. - ALL queries A, AAAA, CNAME, MX, TXT, NS, SOA and CAA one after another on each resolver and stops early on a timeout, refusal, SERVFAIL or NXDOMAIN.
- IPv6 resolvers are only queried when the server has IPv6 connectivity; otherwise their rows report that IPv6 resolvers cannot be reached.
The answers come back to your browser, which compares them. Values are normalized before comparing (case, trailing dots, TXT quoting and chunking, record order), so MAIL.example.com. and mail.example.com count as the same. Then each resolver gets a status:
- With an expected value, a resolver is Matching when its answer contains every value you listed.
- Without one, the tool finds the most common answer among resolvers that returned records, and marks those with that exact answer as Matching and the rest as Different.
- NXDOMAIN, NODATA and empty answers are No records. Timeouts, SERVFAIL, REFUSED and other failures are Error and never count as Matching.
The resolver list
The list holds 54 resolver addresses from 19 operators, compiled from two public resolver lists that the page links to. They are grouped as global networks (Google, Cloudflare, Quad9, OpenDNS, AdGuard, Control D, CleanBrowsing, DNS.SB, G-Core, Hurricane Electric, NTT), national and regional operators (DNS4EU, TREX, Yandex, MSK-IX, Quad101, AliDNS, 114DNS), and Hurricane Electric servers with a region listed by the source. Locations are deliberately conservative: anycast networks show "Anycast · many locations", servers whose region the source lists show it with "(listed region)", and everything else shows "Location not verified". Resolvers that filter domains are tagged Filtering.
How to use the NetTools.tech DNS Propagation Checker
- Open the DNS Propagation Checker.
- Enter the name in Domain or hostname, for example
example.com,www.example.comor_dmarc.example.com. A pastedhttps://URL is reduced to its hostname. - Pick a Record type. The hint under the field explains it; SRV needs the form
_service._protocol.name, PTR needs an IP address. - Optional: open Expected value and enter the value you expect, one per line (for example the new IP
192.0.2.10). This is disabled for ALL. - Choose resolvers. Defaults selects 18 resolvers spread over operators and listed regions; All, IPv4 only and None change the selection; the search box filters by name, IP, operator or region; the checkbox next to an operator toggles all its addresses.
- Press Check DNS. Rows show "Checking…" until the answers arrive.
- Use the status filters to focus on Different, No records or Errors, copy single values with Copy, or download everything with Export CSV.
Preview with sample data fills the table with made-up results that use documentation addresses (192.0.2.x, 198.51.100.x, 2001:db8::). It exists only to show the layout, is labeled as sample data, and the CSV export marks it as sample too.
Understanding the results
| Result | Meaning | What to look for |
|---|---|---|
| Total / Matching / Different / No records / Errors | Count of resolvers per status | Errors and Different falling to zero over time |
| Basis line | How Matching was decided (expected value or most common answer) | Use an expected value when you know the correct record |
| Resolver | Operator name and the IP that was queried | Several IPs of one operator can disagree (separate caches) |
| Location | Anycast, listed region or "Location not verified" | Never read it as a verified server location |
| Status: Matching | Answer equals the expected value(s) or the majority answer | Majority can be the old value early in a change |
| Status: Different | A different answer | Old cached value, geo-DNS, CDN or a filtering resolver |
| Status: No records | NXDOMAIN, no records of this type, or empty answer | Negative caching of a newly created record, or a typo |
| Status: Error | Timed out (3 s), SERVFAIL, refused, unreachable IPv6, other failure | SERVFAIL on many resolvers points to DNSSEC or name server problems |
| Records | Every returned value with its type | Compare the exact values, not just the status |
| TTL | Lowest remaining TTL of the returned records, in seconds (A and AAAA only) | On an old value, roughly how long until that resolver refreshes |
| Time | Response time of that resolver in ms | Slow or missing answers from one operator only |
The TTL column is especially useful on Different rows: an old A record with TTL 2214 means that resolver will keep it for about 37 more minutes, unless its cache is flushed.
Example: moving www.example.com to a new server
www.example.com used to point at 198.51.100.20. It was changed to 192.0.2.10 thirty minutes ago; the old TTL was 3600 seconds.
- Name
www.example.com, type A, expected value192.0.2.10, Defaults selected. - The summary reads, for example, 18 total: 14 Matching, 3 Different, 0 No records, 1 Error.
- The three Different rows return
198.51.100.20with TTLs between roughly 1,500 and 2,200 seconds. Those resolvers cached the old record shortly before the change and will refresh within the next 40 minutes. - The Error row is a resolver that did not answer within 3 seconds; running the check again shows whether it was a one-off.
Conclusion: the change is correct at the authoritative servers, and the old server should keep serving traffic for at least one more full TTL (another hour is a safe margin). If instead all 18 rows showed 198.51.100.20 an hour after the TTL had passed, the next step would be to check NS with Nslookup and Whois: the record was probably edited at a provider that is not authoritative for the domain.
Common use cases
- Following an A, AAAA or CNAME change during a site migration.
- Confirming NS records after moving to a new DNS provider.
- Comparing SOA serial numbers to see whether resolvers have the latest zone version.
- Checking new MX records and SPF or verification TXT records before enabling a service.
- Spotting resolvers that block a domain (filtering) or answer differently (geo-DNS).
- Checking a PTR record change for a mail server's IP.
Troubleshooting
Every resolver still shows the old value
Wait at least the old TTL. If it has clearly passed, check that you changed the zone at the authoritative provider: look up NS for the domain and compare it with the provider whose panel you used. Also check the exact record name; many panels append the zone automatically.
Some resolvers show "No records" for a new record
They cached a negative answer before the record existed. The negative TTL comes from the zone's SOA record (look up SOA with Nslookup and check the min value). The rows switch to Matching once it expires.
One operator disagrees with the rest
If it is tagged Filtering, it may be blocking the domain on purpose. If it is a CDN-backed name, geo-DNS can return a different but correct address. If it is simply an older value with a TTL, it is a cache that has not expired yet.
Many resolvers return SERVFAIL
Resolvers that validate DNSSEC return SERVFAIL when signatures do not match the DS record at the registry, typically after a DNS provider change without updating DS. Fix or remove the DS record at the registrar.
IPv6 rows all show errors
The server cannot reach IPv6 resolvers when it has no IPv6 connectivity. Press IPv4 only to leave them out.
The record type you need is not in the menu
DS, DNSKEY, TLSA, HTTPS and SVCB are not supported by the server yet, so the menu does not offer them. Use dig from a terminal for those.
Common mistakes
- Calling a change "propagated" because your own computer sees it. Your resolver may simply not have had it cached.
- Treating the majority answer as the correct one early in a change. Enter the expected value instead.
- Reading Different on a CDN or geo-DNS name as a failure.
- Forgetting the negative TTL when a record is created right after a failed lookup.
- Raising the TTL again before the change has settled, or lowering it only at the moment of the change, which does not shorten the old cached TTL.
- Shutting down the old server or old DNS provider before one full TTL (or the parent NS TTL) has passed.
Limitations
- One vantage point. All queries leave from the NetTools.tech server in Latvia. Anycast resolvers answer from their nearest site to that server, so this compares resolver networks, not your users' locations, and another site of the same anycast service can hold a different cache.
- Resolver caches only. The tool asks recursive resolvers; it does not query your authoritative name servers or the ISP resolvers your users actually use.
- Locations are not verified. Only regions stated by the source lists are shown.
- TTL only for A and AAAA answers.
- Single attempt. A resolver that drops one packet is shown as an error for that run.
- Some types not supported by the server yet (DS, DNSKEY, TLSA, HTTPS, SVCB), and IPv6 resolvers depend on the server's IPv6 connectivity.
- A snapshot. Each run shows the state at that moment; there is no monitoring or history.
Security & privacy
The name, record type and selected resolver IDs are sent to the NetTools.tech server, which queries the selected public resolvers from its own address. The resolver operators, including those outside the EU such as Yandex, AliDNS or 114DNS if you select them, see a query for that name from the NetTools.tech server, not from you. Comparison and CSV export happen in your browser. Only public domain names are accepted, so internal names never leave your network through this tool. Requests are rate limited per visitor. No credentials are needed or asked for.
Related tools
- Nslookup – a single lookup through 1.1.1.1 and 8.8.8.8, with all common types; guide: DNS lookup.
- Email DNS Propagation – the same idea for MX, SPF, DMARC, MTA-STS and TLS-RPT records; guide: Email DNS propagation.
- Whois – which name servers the registry has delegated the domain to; guide: Whois lookup.
- MX Lookup – mail servers with addresses and reverse DNS; guide: MX lookup.
- Reverse DNS – PTR lookup for an IP address.
- Category overview: DNS & domain tools.
Summary
DNS propagation is cache expiry: each resolver keeps the old answer until its TTL runs out. The NetTools.tech DNS Propagation Checker queries up to 60 resolvers from a curated public list, from one server in Latvia, and marks each answer as Matching, Different, No records or Error against your expected value or the majority answer. Use the TTL column to estimate how long old answers will remain, and plan TTL reductions before changes rather than after.
Frequently asked questions
How long does DNS propagation take?
As long as the old record's TTL, counted from the moment each resolver last cached it. A resolver with no cached copy sees the new value on its next lookup; one that cached the old value just before the change keeps it for up to the full TTL. Name server changes also depend on the NS TTL in the parent zone, which is often one to two days.
Why do some resolvers show the old value and others the new one?
Every resolver caches independently, so each one picked up the old record at a different time and will drop it at a different time. Large anycast services also run many sites with separate caches, so even the same resolver IP can disagree with itself from different places.
Can I speed up DNS propagation?
You cannot flush other people's caches, but you can plan: lower the record's TTL, for example to 300 seconds, at least one old-TTL period before the change, make the change, then raise the TTL again. Some public resolvers offer a manual cache purge page for their own service.
Why does a resolver show "No records" for a record I just created?
If the name was looked up before the record existed, the resolver cached the negative answer (NXDOMAIN or NODATA) for the zone's negative TTL, which comes from the SOA record. It keeps answering "does not exist" until that time expires.
Are the resolvers really queried from all over the world?
No. Every query is sent from the NetTools.tech server in Latvia. Anycast resolvers such as 1.1.1.1 or 8.8.8.8 answer from their site nearest to that server, so the check compares different resolver networks and caches, not different user locations.
Why does a resolver show Different even though my record is correct?
Without an expected value, Different only means the answer differs from the most common answer. CDNs and geo-DNS return different addresses on purpose, and filtering resolvers such as Quad9 or CleanBrowsing may block some domains. Enter the value you expect to get a check against your own record instead.
Why do IPv6 resolvers show an error?
IPv6 resolvers can only be reached when the NetTools.tech server has IPv6 connectivity. Without it, those rows show an error saying so, and no query is sent; use the IPv4 only button to leave them out.
Which record types can be compared?
The server answers A, AAAA, CNAME, MX, TXT, NS, SOA, CAA, SRV and PTR, plus ALL, which queries A, AAAA, CNAME, MX, TXT, NS, SOA and CAA in turn. DS, DNSKEY, TLSA, HTTPS and SVCB are not supported yet and are not offered in the menu.