What is DNS propagation?
DNS propagation is the time it takes for a changed record to be seen everywhere. Nothing is pushed: each resolver keeps its cached copy until the record's TTL (or, for a "does not exist" answer, the zone's negative TTL) runs out and only then asks the authoritative servers again, so the old TTL sets how long the change can take.
How to use DNS Propagation Checker
- Enter the domain name you changed (for example www.example.com) and the record type you edited.
- Press Check propagation; the eight resolvers are asked at the same time from the Cloudflare edge.
- Read the summary: one distinct answer means every resolver serves the same data.
- If answers differ, compare each resolver's TTL with the highest TTL to see how long the old answer can survive, and check the authoritative servers with the Nameserver Checker.
DNS Propagation Checker features
- Eight public resolvers in one run: Cloudflare 1.1.1.1, Google Public DNS, Quad9, Cisco OpenDNS, AdGuard DNS, Control D, CleanBrowsing and NextDNS
- Answers grouped into distinct sets, with the most common answer and every resolver that differs named — a tie is shown as a tie, not as a majority
- Remaining TTL per resolver and the highest TTL, so you know how long an old cached answer can last
- Timeouts, SERVFAIL and REFUSED reported as failures — never mistaken for a different answer
- Extended DNS Errors (RFC 8914) shown when a filtering resolver explains why it blocked a name
- All sixteen record types of the DNS Lookup, including MX, TXT, CAA and HTTPS
Inputs and outputs
Inputs
- Domain name — the name whose record you changed; underscore names such as _dmarc.example.com work too.
- Record type — A by default; any of the sixteen types of the DNS Lookup.
Outputs
- Summary — resolvers that answered, number of distinct answers, how many share the most common answer when one answer leads, the highest TTL and the median response time from the edge.
- Answers by resolver — status (response code, failure or Extended DNS Error), the answer, its lowest TTL and the response time of each of the eight resolvers.
- Findings — the answer sets and who returns them, failures, filtering decisions and how long cached answers can last.
- How this was measured — the server's notes on vantage point, concurrency and the resolvers that are not included.
DNS Propagation Checker example
A record of iana.org
Input:
iana.org · type AOutput:
Resolvers that answered: 8/8 · Distinct answers: 1 — all resolvers agree · Highest TTL: 3600 s
Google Public DNS NOERROR 192.0.43.8 TTL 471
Quad9 NOERROR 192.0.43.8 TTL 1110
AdGuard DNS NOERROR 192.0.43.8 TTL 3600
… and five more resolvers with the same answer
Findings: All 8 resolvers return the same answer: 192.0.43.8.How to read the DNS Propagation Checker results
One distinct answer and 8/8 answered: every listed resolver serves the same data now. Caches elsewhere (your ISP, your laptop) may still hold the old record until their own TTL ends.
Two or more answers: some caches still hold the previous data. They refresh within the highest TTL shown; if the difference persists beyond that, look at the zone — geo-DNS, load balancing or nameservers that disagree.
A resolver marked with an Extended DNS Error such as "Blocked" or "Filtered" applied its own policy; that answer says nothing about your zone.
NXDOMAIN on some resolvers right after you created a name usually means they cached the earlier "does not exist" answer; it expires after the SOA minimum TTL of the zone.
When to use DNS Propagation Checker
- Watching a website move to a new server or CDN after changing its A, AAAA or CNAME records.
- Confirming that a new MX or SPF TXT record is visible on the big public resolvers before switching mail providers.
- Checking that a domain-verification TXT record is visible on the major public resolvers before pressing "Verify" in a SaaS console.
- Explaining to a colleague why some users still reach the old server: the table shows which resolvers still hold the old answer and for how long.
Troubleshooting
- One resolver times out every time: it may be unreachable from that edge at the moment; a single failure does not mean your record is wrong. Run the check again in a minute.
- Every resolver returns the old answer long after the change: confirm the change is saved at your DNS provider and that the domain's nameservers are the ones you edited (Nameserver Checker).
- Answers keep differing between runs: the zone may use geo-DNS or round-robin records; compare the record sets with the DNS Record Comparison tool to see what exactly differs.
- The tool refuses the name: private names (.local, .internal), single labels and IP addresses are not sent to public resolvers.
Frequently asked questions about DNS Propagation Checker
Does this check DNS propagation around the whole world?
No tool can see every cache. This one asks eight large public resolvers, all from the Cloudflare edge location that served your request, over DNS-over-HTTPS. Each of those services is anycast, so the answer comes from its site nearest to that edge. Your ISP's resolver, company DNS and devices keep their own caches.
How long does DNS propagation take?
There is no propagation in the sense of a push: each resolver keeps a cached record until its TTL runs out and then asks the authoritative servers again. The highest TTL in the results is the longest a listed resolver may keep serving its current copy. Lower the TTL a day before a planned change to make the switch quicker.
Why does one resolver give a different answer when the record has not changed?
Filtering resolvers (Quad9, AdGuard, CleanBrowsing) block domains on their lists and may say why with an Extended DNS Error. Geo-DNS and CDN load balancing also answer by location on purpose. A timeout or SERVFAIL is reported as a failure, not as a different answer.
Why do all resolvers agree but my browser still shows the old site?
Your computer, browser and local network have their own caches, and the browser may keep an open connection to the old server. Flush the local DNS cache or wait for its TTL, and check that you are not testing through a VPN or a company resolver.
Can I see what the authoritative nameservers hold?
Yes — the Nameserver Checker asks each authoritative server of the zone directly, which shows whether every one of them already serves the change. Propagation can only finish once every authoritative server serves the new data.
Technical notes
Each resolver receives a binary DNS query over DNS-over-HTTPS (RFC 8484), with EDNS(0) so it can attach Extended DNS Errors (RFC 8914). The Worker asks four resolvers at a time and times each one separately; the time includes the HTTPS connection setup when the Worker had to open a new connection.
Answers are compared as the server does: the response code plus every record's type and data, case-folded and sorted, signatures left out. NXDOMAIN, an empty NOERROR (NODATA) and a positive answer are three different results. TTLs are not compared — they are cache ages (RFC 2181 §8, RFC 2308 for negative answers).
Limitations and methodology
All resolvers are asked from the single Cloudflare edge that serves your request, so this is a comparison of public resolvers as seen from that location — not a test from many countries. Anycast resolvers answer from their site nearest that edge.
Your ISP's resolver, corporate resolvers and device caches are not included. DNS4EU (offered only to individual citizens) and Mullvad DNS (endpoint not verified) are deliberately left out.
Response times are measured from the edge to each resolver and include connection setup; they do not describe your own connection.
Security and privacy
The name and record type you enter are sent from the Mutqan server to the eight resolvers listed in the results; each of them sees a query from Mutqan, not from you. Nothing is stored and no result is kept after the page shows it.
References
- RFC 2308: Negative Caching of DNS Queries (DNS NCACHE)How resolvers cache NXDOMAIN and NODATA answers, and that the negative TTL is the smaller of the SOA record's TTL and its minimum field.
- RFC 2181: Clarifications to the DNS SpecificationRules the original DNS RFCs left open: an RRset shares one TTL, TTL limits, and that MX and NS targets must not be aliases (CNAME).
- RFC 8484: DNS Queries over HTTPS (DoH)Defines DNS over HTTPS: a DNS message sent in an HTTPS GET or POST with the application/dns-message media type, and how caching and HTTP/2 apply to it.