DNS Propagation Checker

What this tool does

DNS Propagation Checker queries a domain’s A records against Cloudflare and Google’s public DNS-over-HTTPS resolvers in parallel and flags whether their answers agree, useful right after a DNS change to see if it’s visible yet. This checks agreement from your own location across two major resolvers, not a true distributed, worldwide propagation check.

Right after changing a DNS record, different resolvers around the internet can briefly show different answers, some have already picked up the change, others are still serving a cached, older value until their cached copy’s TTL expires, a process informally called "propagation".

This tool queries a domain’s A records from two major public resolvers, Cloudflare and Google, in parallel and flags whether they currently agree, giving a quick signal about whether a recent change has started taking effect.

How to use DNS Propagation Checker

1. Enter the Domain to check.
2. Press Check A records.
3. Review whether the resolvers agree or show different values.
4. Re-check later if they disagree, propagation usually resolves within the old record’s TTL.

Tips for better results

• This checks agreement between resolvers reachable from your own location, not a true geographically distributed check; a proper worldwide propagation check queries from many vantage points around the globe, which requires server infrastructure a browser-only tool doesn’t have.
• Disagreement between resolvers right after a DNS change is completely normal and expected, it typically resolves on its own as each resolver’s cached TTL expires and it re-queries.
• A long previous TTL (time to live) on the old record means propagation naturally takes longer; a short TTL set in advance of a planned change speeds this process up considerably.
• If results still disagree well beyond the old record’s TTL, double-check the change was actually saved correctly at your DNS provider, rather than assuming it’s still "propagating".

Common use cases

• Checking whether a DNS change you just made is visible yet from a couple of major resolvers.
• Diagnosing why some visitors see a new server while others still see the old one after a migration.
• Confirming agreement between two major resolvers before troubleshooting further down a different path.
• Understanding, with a live example, why "propagation" isn’t instantaneous.

Common mistakes to avoid

• Treating this as a definitive, global propagation check; it reflects only two resolvers from one location, not the dozens of geographically distributed checkpoints a dedicated propagation-checking service uses.
• Panicking over temporary disagreement immediately after a change; some delay is completely normal and expected, driven by each resolver’s own caching behaviour.
• Forgetting to set a short TTL in advance of a planned DNS change, which would have sped up propagation; this is only useful to know for next time; the current change’s speed is bound by whatever TTL was already in effect.