Souus Tools
Sponsor

Network

DNS Propagation Comparator — Compare dig Output Across Resolvers

Paste dig output from several resolvers and compare answers, TTLs, and response codes to see whether a DNS change has propagated. No query is sent from this page.

Free to use No sign-up Runs in your browser

Tool workspace

This tool performs no DNS query itself, so nothing you type is sent anywhere. Run the queries yourself with dig, then paste each resolver's output below to compare them.

Run these commands, then paste each result
dig @1.1.1.1 example.com A
dig @8.8.8.8 example.com A
dig @9.9.9.9 example.com A

Resolver output

Paste output from at least two resolvers to compare propagation.

Why Compare Resolver Answers Instead of Querying From a Page

After a DNS change, different recursive resolvers serve the old record until their cached TTL expires, so a record can look correct from one network and stale from another. Comparing several resolvers is the only reliable way to judge propagation. A browser cannot send DNS queries — it has no UDP or raw TCP access — so any web page claiming to query DNS is really forwarding your domain to a third-party DNS-over-HTTPS service. This tool takes the opposite approach: you run dig yourself, and it parses and diffs the output locally so no lookup, domain, or resolver choice ever leaves your machine.

How to Check DNS Propagation

  1. 1Enter the domain and record type you changed, so the tool can build the matching dig commands.
  2. 2Copy the generated commands and run them in your terminal against each resolver you care about.
  3. 3Paste each resolver's output into its own box. Full dig output, dig +short output, and plain resource records are all accepted.
  4. 4Read the status banner: identical answers across all resolvers mean propagation is complete.
  5. 5If answers differ, check the missing-value list and the TTL range to estimate how long the stale caches will persist.

DNS Change Verification Tasks

Confirm a migration has propagated

After repointing an A or CNAME record, verify that every resolver you sampled now returns the new target.

Explain why one office still sees the old site

Compare a corporate resolver against public ones to show that a stale cache, not the zone, is serving the old address.

Verify mail and verification records

Diff MX and TXT answers, including SPF or domain-verification strings split into multiple quoted chunks.

Capture evidence for an incident review

Keep the raw resolver output alongside a parsed diff and TTL range as part of a change or outage write-up.

Frequently asked questions

Why does this tool not look up DNS for me?

Browsers cannot perform DNS queries directly, so an in-page lookup necessarily sends your domain to a third-party DNS-over-HTTPS resolver. We removed that dependency rather than route your queries through someone else's service. Running dig locally also gives a more accurate view, because it tests the network you actually care about.

How do I run these queries on Windows?

Install BIND tools to get dig, or use nslookup with a resolver argument, for example: nslookup example.com 1.1.1.1. Paste the resulting records into a box; plain record lines are parsed too. PowerShell's Resolve-DnsName -Server 1.1.1.1 also works if you paste the name, type, and value columns.

What do the different answer statuses mean?

Agreement means every snapshot returned an identical set of records. Disagreement means at least two resolvers returned different sets, which usually indicates an in-flight change or a stale cache. Partial means some snapshots returned no records, for example because of SERVFAIL or NXDOMAIN.

How long until a stale answer disappears?

At most the record's TTL, counted from when that resolver cached it. The reported TTL range is an upper bound on the remaining wait. Lowering the TTL before a planned change is what makes future cutovers fast.