{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Use one public hostname such as example.com. The sample remains local until you run the check.
A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, and CAA are supported.
{{ expectedAnswerHelp }}
This setting is ignored when Expected answer is blank and the tool uses the leading answer group.
{{ resolverProfileHelp }}

{{ workflowFeedback }}

Leave off for an ordinary propagation snapshot.
{{ dnssec_do ? 'DNSSEC data requested' : 'Standard query' }}
This troubleshooting flag is neutral when off.
{{ dnssec_cd ? 'Checking disabled' : 'Resolver checking enabled' }}
Optional CIDR such as 203.0.113.0/24. Leave blank for the normal resolver view.
Use 500-10000 milliseconds. The default is 3500 ms.
ms
Zero is fastest; up to two extra attempts are available.
ResolverStateAnswerTTLADLatencyCopy
{{ row.resolver }}{{ row.status }}{{ row.answer || 'No usable answer' }}{{ row.ttl === null ? '—' : `${row.ttl} s` }}{{ row.ad }}{{ row.latency === null ? '—' : `${row.latency} ms` }}

{{ values.verdict }}

{{ briefLead }}

{{ values.agreement_percent }}% agreement
Comparison basis
{{ values.comparison_basis }}
Leading answer
{{ values.lead_answer || 'No usable answer' }}
Holdout window
{{ holdoutWindow }}

Recommended next checks

  1. {{ step }}
EDNS Client Subnet (ECS) Tester Compare DNS answers with and without an EDNS Client Subnet hint, then inspect answer steering, echoed scope, TTL drift, and privacy clues.
DNS Delegation Trace Analyzer Trace a public hostname through DNS delegation and aliases, compare resolver views, and inspect DNSSEC or negative-cache clues.
Reverse DNS (PTR) Checker Check PTR records for an IP or hostname, verify forward-confirmed reverse DNS, and compare expected names or public resolver views.
DNS Cache Capacity Calculator Estimate DNS resolver cache memory from insert churn and TTL, then compare budget headroom with upstream QPS and hit-versus-miss latency.

A DNS change is complete at the authoritative nameservers before it is complete for everyone who uses the name. Recursive resolvers keep earlier answers in cache, then replace them on their own schedules. During that interval, two people can ask the same DNS question and receive different, valid snapshots of the change.

This matters during website moves, mail routing changes, certificate validation, and edits to TXT or CAA records. A stale address can send traffic to the old server. An old MX answer can keep mail on the former route. A missing validation token can delay a certificate even while another resolver already returns it.

Authoritative answer
The record set published by the nameservers responsible for the zone.
Recursive answer
The cached or newly fetched answer a resolver returns to its clients.
RRset
All records for one owner name and type, such as every A record for a hostname.
TTL
Time to live, expressed in seconds, which limits how long a DNS record may remain cached.

Propagation is therefore a convergence problem, not a file transfer. The useful question is not merely whether a resolver returned an answer, but whether it returned the complete intended RRset for the exact record type. Record order is not significant. Missing, extra, or older values are significant, and a failed lookup provides no evidence that the change is visible.

TTL helps explain a holdout, but it is not a universal countdown. Resolvers may have cached the old answer at different times, and negative answers such as NXDOMAIN can also be cached. Browser, operating-system, office, and ISP caches can outlast the public resolver snapshot being inspected.

Agreement across several public resolvers is strong supporting evidence, not proof for every client. Split-horizon DNS, private resolvers, regional policy, DNSSEC failures, and location-aware answers can produce a different view. For a production cutover, verify the authoritative data first and then compare recursive answers with the exact result you intended to publish.

How to Use This Tool:

Frame one precise DNS question and decide whether you know the intended answer before running the resolver check.

  1. Enter a public Hostname and select the record type that actually changed. A, AAAA, CNAME, MX, NS, TXT, SOA, SRV, and CAA are supported.
  2. Enter the complete Expected answer for a cutover or validation check. Leave it blank only when you want to discover the largest answer group rather than test a known target.
  3. Choose an exact comparison for a whole normalized answer, contains for a required fragment such as one TXT token, or a regular expression for a carefully reviewed pattern.
  4. Select a resolver profile. Increase the timeout or add attempts only when failures look like request timing rather than an invalid name or missing record.
  5. Request DNSSEC data or add an EDNS Client Subnet (ECS) prefix only when those behaviors are part of the investigation. They can change the evidence and its privacy implications.
  6. Run the check, read the propagation verdict, then inspect every alternate or failed resolver row before treating the percentage as a release decision.

Interpreting Results:

When an expected answer is supplied, agreement means the selected resolver returned that target under the chosen comparison rule. Without a target, agreement only means that the resolver belongs to the largest observed answer group. A dominant answer can still be the old answer.

  • Expected or Leading rows contribute to agreement. Confirm the answer text, not only the label.
  • Alternate rows are usable but different. Their TTL can suggest when to retry, while the record content reveals whether they are true cache holdouts.
  • Failed rows stay in the denominator. They lower confidence rather than disappearing from the result.
  • A 100% public-resolver result describes only the selected snapshot. Verify from an affected network when private DNS, regional routing, or split views matter.

Technical Details:

Resolver comparison begins by reducing presentation-only differences. Hostnames are lowercased and lose a final dot, wrapping quotes are removed from TXT data, and multi-value answers are sorted and deduplicated. That makes RRsets with a different display order compare equally without hiding a missing or extra value.

Formula Core:

Agreement keeps every selected resolver in the denominator, including a timeout or response with no usable answer.

A=round(MS×100)

A is agreement percent, S is the number of selected resolvers, and M is either the number matching the expected answer or the size of the largest normalized answer group. Four matches among five selected resolvers produce 80%. A fifth row that fails remains part of S.

Rule Core:

ConditionClassificationConsequence
No usable answersNo usable resolver answersStop and correct the query or request conditions.
Expected target matches every selected row with no failuresExpected value visible everywhereThe selected public view is fully aligned.
Expected target matches every successful row, with one or more failuresExpected value visible on every successful resolverAnswer evidence agrees, but failed rows leave coverage incomplete.
Expected target matches noneExpected value not yet visibleCheck authority data and the expected value before waiting on caches.
Expected-target agreement is at least 80% but below full coverageMostly propagated to expected valueInspect the remaining holdouts and their TTLs.
No target; the leading group is below 80%Resolver answers are splitNo answer group dominates the selected snapshot.

The holdout wait is the largest TTL among alternate answers, in seconds. It is a conservative clue for this resolver set, not a guarantee that every downstream cache will refresh by then. Latency is rounded to milliseconds and describes request time only; it does not measure record correctness.

The DNSSEC Authenticated Data flag is resolver evidence that depends on validation policy. ECS can also change an answer by supplying a client-network prefix to an ECS-aware path. Neither signal should override the actual record set or substitute for an authoritative query.

Privacy and Accuracy Notes:

Running a check sends the hostname, record type, and selected DNS options to public DNS providers. An ECS value deliberately reveals a network prefix to the ECS-capable resolution path. Do not submit private names or a client prefix when that disclosure is inappropriate.

A resolver snapshot cannot prove that the authoritative zone is correct, that an application is reachable, or that every client sees the same answer. Confirm the authoritative RRset and test the affected network before completing a high-impact cutover.

Worked Example:

A-record cutover with one holdout

Suppose the intended A record is 203.0.113.20. Four of five selected resolvers return that address and one returns 192.0.2.44 with a TTL of 780 seconds. Agreement is 80%, the alternate row is the holdout, and 780 seconds is the largest visible wait clue. First confirm every authoritative nameserver publishes 203.0.113.20; then rerun after the holdout TTL rather than assuming the percentage alone proves convergence.

References: