What did that DNS change actually do?
Capture what public resolvers answer for a customer domain now, make your change, then capture again. You get a dated, source-linked record of what changed, what did not, and what could not be observed at all.
After using this, you can now hand a customer evidence that a nameserver move or a mail cutover did what you said it would — instead of a screenshot of a control panel, which shows what you asked for rather than what the internet answers.
Free, no account, no server of ours. The lookups are made by your own browser over DNS-over-HTTPS.
Capture a snapshot
Run this once before your change, and again after it.
Every name queried must sit inside this domain. That scope is the tool’s authorization boundary.
Supported types: A, AAAA, CNAME, MX, NS, TXT, SOA, CAA, SRV, PTR.
Latest capture
| Name | Type | Resolver | Answer |
|---|
Compare before and after
The “after” is your latest capture above. Give it a “before” to compare against.
Nothing loaded yet.
Nothing captured yet.
Evidence report
| Name | Type | Resolver | Result | Before | After |
|---|
What this does not do
It does not write DNS records, send mail, test uptime, monitor continuously, or judge whether a configuration is correct, secure, or deliverable. It records what named resolvers answered at two moments and states the difference between them. Whether a difference matters is your call.
Inconclusive is not “no change”. A timeout, a refusal, or a query asked in only one of the two captures is reported as inconclusive and counted separately. It is never folded into the unchanged total.
Questions
What problem does this solve?
After a nameserver move, a mail provider switch, or a TXT record edit, somebody has to be able to say what actually changed. Screenshots of a DNS panel show intent, not effect, and a green tick from a monitoring tool shows the current state without the state it replaced. This captures what named public resolvers answered before the change and again after it, and reports the difference as a record you can keep or hand to a customer.
Does my domain list leave my browser?
There is no account, no server of ours, and no analytics vendor. The DNS lookups are made by your own browser directly to the public DNS-over-HTTPS endpoints you tick — Cloudflare, Google and Quad9 — exactly as any web request from your machine would be. Those resolvers see the query, as they would if you simply visited the domain. Nothing is sent to us, because there is nothing of ours in the path. Snapshots stay in your browser until you download them.
Why does it report 'inconclusive' instead of 'no change'?
Because they are different claims, and conflating them is how an evidence tool becomes worthless. If a resolver timed out, refused the query, or was not asked the same question in both captures, the honest statement is that nothing was observed — not that nothing changed. Inconclusive findings are counted and listed separately, and they are never folded into the unchanged total.
Is this a DNS monitoring or security tool?
No. It does not write records, send mail, test uptime, watch continuously, or judge whether a configuration is correct or secure. It records what specific resolvers answered at two moments and states the difference. Deciding whether a difference matters is the operator's job.
Why query three resolvers instead of one?
Propagation is the usual reason a DNS change looks done to one person and not to another. Recording each resolver separately makes that visible: a change that has landed at Cloudflare and not yet at Google shows as changed on one row and unchanged on another, which is the actual situation rather than an average of it.
Can I use this with the command-line version?
Yes. The snapshot JSON this page downloads is the same schema the Python package in the repository reads, so a baseline captured here can be compared with python3 -m dns_evidence compare, and a snapshot captured by the CLI can be loaded here as the 'before'. The two produce the same report.
Why does a CNAME'd name show no A record?
Only the record type you asked for is recorded, so a CNAME in the resolution chain is never written down as if it were the A record. Query CNAME on that name to see the chain itself.
Still waiting on a change to land? How long does DNS propagation take? covers what actually sets the wait, and how to plan a cutover around it.
Wondering how this compares to a global propagation checker like whatsmydns.net? See this tool vs. whatsmydns.net.
Wondering why not just run dig before and after and compare by eye? See this tool vs. running dig by hand.
One caveat when mixing the browser and the CLI
The CLI queries resolvers directly over the DNS protocol; this page goes through DNS-over-HTTPS, and those endpoints present record text with small cosmetic differences (trailing dots, TXT quoting). This page normalises what it receives, so two captures made here always compare cleanly. Mixing a CLI capture with a browser capture can show a cosmetic “changed” on a record that did not really move. Capture both halves the same way and the question does not arise.