Records
Resolve any record across Cloudflare, Google, Quad9, OpenDNS, AdGuard, and SecDNS in parallel. Spot caching mismatches and EDNS Client Subnet geo-routing in one view.
Why parallel resolvers matter
A single resolver can mislead you: if it has a cached answer it will keep returning it for the entire TTL window. Querying multiple public resolvers in parallel surfaces stale caches and reveals split answers from CDN edge logic.
Enter a value above to run a lookup.
Propagation is the time it takes for a DNS change to become visible across recursive resolvers worldwide. Because every resolver caches answers up to the TTL you set on the record, an update at the authoritative server may take seconds — or hours — to reach every device.
We pin a normal DNS query to each resolver in parallel using node:dns Resolver.setServers([ip]). The page reports per-resolver answers and round-trip times so you can spot cache mismatches at a glance.
Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9, OpenDNS 208.67.222.222, AdGuard DNS 94.140.14.14, and SecDNS’ own anycast resolver. You can override the list by passing ?servers=1.1.1.1,8.8.8.8,… to the API.
Either your record has not propagated everywhere yet (some resolvers still serve cached answers) or your authoritative server is using EDNS Client Subnet to return geo-targeted answers (common for CDNs). Either way, the propagation tool surfaces the divergence.
Yes. The first time most resolvers see a name, the answer is fetched live from your authoritative servers and not cached for very long. So new records usually appear in seconds, not hours.