This tool vs. running dig by hand
Run dig before, make the change, run it again, eyeball the two outputs. That catches the record you already expect to have moved. It is a much harder way to notice a resolver that timed out, to keep three resolvers straight at once, or to still have a dated copy of either run next week.
What running dig by hand is
Most DNS changes get checked this way, and there is nothing wrong with the
habit: open a terminal, run dig example.com A or
nslookup example.com, read the answer section, make the
change, run the same command again, and compare the two outputs by eye.
This page names no product and no company — it is describing a
manual workflow nearly every operator already has, not a competing tool.
What this tool is
This page keeps no account and sends nothing to a server of ours. You pick a customer-authorized domain, the record names and types to watch, and which of three public resolvers (Cloudflare, Google, Quad9) to query. It captures what each one answers now, lets you make the change, captures again, and reports each name/type/resolver combination as changed, unchanged, or inconclusive — never folding a failed lookup into "no change" — as a Markdown or JSON record you can keep.
| Situation | Running dig by hand | This tool |
|---|---|---|
| The record you expect to see move | Catches it reliably — a human eye is good at spotting one obviously different value in an otherwise-identical block | Catches it the same way, and states it as changed with both answers recorded |
| A resolver timeout or refusal | Prints a short error or an empty answer section that reads, next to routine output, as "nothing here, must be unchanged" | Recorded with an explicit status (timeout, refused, error) and reported as inconclusive, never unchanged |
| Checking more than one resolver | Means running the same command again with @1.1.1.1, @8.8.8.8, and so on, and holding three separate outputs in your head at once | Queries Cloudflare, Google, and Quad9 in the same capture and reports each resolver's own before/after result on its own row |
| A record that has propagated to one resolver but not another | Only visible if you happen to run the command against both and remember which was which | Shows as changed on one resolver's row and unchanged on another's, in the same report |
| Having something to keep or hand a customer | A terminal scrollback that is gone once the window closes, with no timestamp attached | A snapshot JSON with an observed_at timestamp per query, and a Markdown report built from it |
The gap that matters most is not the record you already expect to change
— a careful read catches that one fine. It is the resolver that did
not answer at all. dig and a quiet terminal make a timeout
look exactly like nothing changing; this tool's report cannot, because
every observation carries its own status and an unanswered query is
recorded as inconclusive rather than quietly rounded down to
unchanged.
Common questions
What does running dig by hand actually catch?
An operator who already knows what changed catches it reliably: run dig before, run dig again after, and see that the A record now shows a different IP. That comparison works well precisely when you already expect a specific line to move, because a human eye is good at spotting one obviously different value next to an otherwise-identical block of text.
Why is a resolver timeout easy to mistake for no change?
dig reports a timeout as a short error, or as an answer section with nothing in it, and next to a wall of routine, unremarkable output both read the same as "nothing here, must be unchanged". This tool tracks every observation's status explicitly and reports a timeout, a refusal, or a transport error as inconclusive, never as unchanged, because a resolver that did not answer is not evidence the record stayed the same.
Why does checking from one machine hide propagation?
A single dig run queries whatever resolver your machine is already configured to use, so it shows one view. This tool queries Cloudflare, Google, and Quad9 separately and reports each one's own before/after result, so a change that has reached one resolver and not another shows up as changed on one row and unchanged on the next -- the actual state of a propagating change, not a single average of it that hides the disagreement.
What is lost without a saved, dated file?
Two dig outputs compared by eye in a terminal scroll back leave nothing behind once the window closes -- no timestamp, no record of which resolver answered, nothing to attach to a ticket or hand a customer questioning what happened. This tool's snapshot is a JSON file with an observed_at timestamp per query and a resolver identity per answer, and the comparison report it builds is a Markdown table you can keep, attach, or send, not a memory of what a terminal once showed you.
Does this replace reading DNS records yourself?
No. It is an observation record, not a DNS authority -- it has no connection to your zone file or registrar, cannot tell you why a record is wrong, and only reports what named public resolvers answered at the moments you asked. Deciding whether a difference matters, and understanding a domain's zone well enough to plan the change in the first place, is still a job for reading and knowing DNS yourself.
Nothing here says or implies that checking DNS with dig or nslookup is a mistake — it is a fast, honest habit that works well for the case it was built for. This page describes where a plain eyeball comparison runs out, not a fault in anyone who uses one.