DNS Propagation Checker

Looks up a DNS record for a hostname against several independent public resolvers (Cloudflare, Google, AdGuard) in parallel from your browser, and flags whether they're all returning the same answer. A free online tool from Staaarter, right in your browser.

Runs locallyUpdated 2026-07-25

Overview

Introduction

After changing a DNS record, different resolvers around the internet pick up the new value at different times because each one caches the old answer until its TTL expires.

This tool queries several independent public resolvers for the same record at once, straight from your browser, so you can see whether they already agree or are still serving different answers.

What Is DNS Propagation Checker?

A parallel DNS lookup tool that sends the same query to Cloudflare's, Google's, and AdGuard's public DNS-over-HTTPS resolvers and lines up their answers side by side.

It's part of this site's DNS & Domain Tools collection; the DNS queries genuinely leave your browser to reach each resolver.

How DNS Propagation Checker Works

Your hostname and record type are sent as three parallel HTTPS requests, one to each resolver's JSON API, using the DNS-over-HTTPS protocol.

The answers are normalized and compared; if every resolver that responded successfully returned the exact same set of values, the result is marked consistent.

When To Use DNS Propagation Checker

Use it right after changing an A, MX, or TXT record to see whether the new value has reached multiple independent resolvers yet.

It's also useful for debugging a report of 'it works for me but not for my coworker', since the two of you may be hitting resolvers that cached the record at different times.

Often used alongside MX Record Lookup and DKIM Record Checker.

Features

Advantages

  • Queries multiple independent, well-known public resolvers in parallel instead of just your local DNS.
  • Clearly flags disagreement between resolvers rather than just showing one answer.

Limitations

  • Only reflects three specific public resolvers, not your ISP's resolver or a truly global set of vantage points.
  • A resolver agreeing here doesn't guarantee every recursive resolver on the internet has picked up the change yet.

Examples

A newly changed A record still propagating

Input

example.com, type A

Output

Cloudflare: 203.0.113.10
Google: 203.0.113.10
AdGuard: 198.51.100.5 (Resolvers disagree)

AdGuard is still serving a cached answer from before the change; the others have already picked up the new IP.

Best Practices & Notes

Best Practices

  • Lower a record's TTL a day or two before a planned change, then raise it back afterward, to shrink the propagation window.
  • Re-run the check a few minutes apart rather than repeatedly within seconds; caches won't clear any faster from re-querying.

Developer Notes

Each resolver is queried with its own fetch() call so one resolver timing out or blocking CORS doesn't prevent the others from reporting; results are compared as sorted JSON strings so answer ordering differences don't cause a false 'disagree'.

DNS Propagation Checker Use Cases

  • Confirming a DNS change has propagated before telling a client or teammate it's live
  • Diagnosing inconsistent behavior that turns out to be resolver-level caching
  • Spot-checking a record across a few well-known resolvers without installing a CLI tool

Common Mistakes

  • Assuming a single 'it looks right' lookup means the record has fully propagated everywhere.
  • Not accounting for TTL when deciding how long to wait before re-checking.

Tips

  • Check MX or TXT records the same way you'd check A records here; the record type buttons cover the common types.

References

Frequently Asked Questions