{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Root Leaf Deep Boundary
Use a public root such as example.com. Generated labels become real public DNS queries.
Choose A, AAAA, CNAME, TXT, or MX for the behavior you need to verify.
Leaf + deep is the broad first pass; pin one lane when you are isolating a known discrepancy.
Four probes per lane is a balanced default; use eight for a stronger repeat sample.
The default compares Cloudflare and Google; All public resolvers adds DNS.SB.
Accepted range: 1000–15000 milliseconds.
ms
{{ workflowFeedback }}
Blank is neutral. Do not enter an asterisk.
Leave off unless DNSSEC authority evidence is part of the diagnosis.
{{ dnssecDoBool ? 'Request DNSSEC records' : 'Standard DNS reply' }}
Leave off for ordinary checks.
{{ dnssecCdBool ? 'Bypass resolver validation' : 'Resolver validation enabled' }}
EvidenceObserved readOperational meaningCopy
{{ row.label }}{{ row.value }}{{ row.meaning }}
ResolverLaneQNameOutcomeAnswer or authorityTTLCache hintADTimeCopy
{{ row.resolver }}{{ row.lane }}{{ row.qname }}{{ row.outcome }}{{ row.evidence }}{{ row.ttl }}{{ row.cache }}{{ row.ad }}{{ row.latency }}
  1. {{ row.title }}{{ row.action }}{{ row.verify }}
MX Record Lookup Inspect a domain's MX route and compare public DNS answers while catching Null MX conflicts, unresolved exchanges, and alias targets.
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
Nameserver Health Check Check a domain’s resolver-visible nameserver set and verify address coverage, SOA presence, and cross-resolver drift before a DNS cutover.
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.

A DNS wildcard can answer for names that were never created individually. A record at *.example.com may synthesize an answer for random.example.com, which is useful for catch-all hosting, tenant routing, and controlled fallback behavior. It can also hide typos, make abandoned subdomains appear live, or produce different results below an existing branch.

The asterisk is not a general pattern matcher. DNS first finds the closest existing ancestor of the queried name, often called the closest encloser, and only then considers a wildcard immediately below that point. An explicit name, an empty non-terminal created by records farther down the tree, or a delegated child zone can stop a parent wildcard from applying.

Wildcard-like answer
An invented name returns an RRset for the selected record type. Repeated matching answers strengthen the evidence but do not prove the authoritative configuration.
NXDOMAIN
The queried name does not exist in the resolver's current view.
NOERROR with no data
The name can exist while lacking the requested record type. Wildcard behavior is type-specific, so an A result says nothing by itself about TXT or MX.
Inconclusive reply
A timeout, transport error, SERVFAIL, or REFUSED response cannot be counted as negative wildcard proof.

Depth matters. A wildcard that answers direct labels below a zone may not answer two labels deep because an intermediate name exists. Testing a known branch such as api is especially useful when the parent wildcard appears to work but names below api.example.com do not.

Caches make timing part of the diagnosis. Negative answers can be retained according to the Start of Authority (SOA) data returned with them, while positive RRsets have their own time to live. After a zone change, repeating the same probes too soon may reproduce cached history rather than the new authority state.

Random-name probes reduce the chance of accidentally testing a real record, but they remain observations through public recursive resolvers. Confirm a production conclusion against the authoritative DNS provider or directly queried authoritative servers.

How to Use This Tool:

Choose the record type and name depth that match the behavior you need to verify, then keep those choices fixed when comparing runs.

  1. Enter the Zone or host root. The check creates real random public DNS names below it, so use only a domain you are authorized to test.
  2. Choose A, AAAA, CNAME, TXT, or MX and select a Probe topology. Leaf + deep is the broad first pass; a single lane is better when isolating a known discrepancy.
  3. Set three, four, six, or eight probes per lane and choose one or more public resolvers. More probes strengthen the sample but also send more DNS queries.
  4. Add a Known boundary branch such as api when behavior below an existing name matters. Do not enter an asterisk. Enable DNSSEC records or checking-disabled behavior only when those flags are part of the diagnosis.
  5. Run the check, then compare the verdict with the Probe ledger. If inputs change afterward, run again before relying on the displayed artifacts.

Interpreting Results:

The verdict summarizes only decisive invented-name replies. Wildcard-like answers observed means positive answers were captured without a stronger branch, depth, or resolver-split warning. No wildcard answers observed means all decisive probes were NXDOMAIN or NOERROR with no data for the selected type. Neither verdict proves how every possible name will behave.

  • Known branch blocks the parent wildcard requires direct leaf answers at 60% or more and known-branch answers at 25% or less.
  • Deep names break from leaf behavior uses the same 60% direct and 25% deep boundary.
  • Mixed public resolver view means both positive and negative decisive replies exist while the primary lane is below 80% positive.
  • No decisive DNS evidence means every random probe ended in a transport error, SERVFAIL, REFUSED, or another unclassified outcome.
  • A high leading-answer cluster means many positive probes returned the same normalized RRset. It supports a shared wildcard origin but can also reflect a catch-all service or resolver cache.

Technical Details:

Wildcard diagnosis samples several name positions because DNS synthesis depends on the nearest existing ancestor. Leaf probes add one random label below the submitted root; deep probes add two levels; boundary probes add a random label below the supplied known branch. Apex and boundary controls provide context but do not enter the wildcard answer rate.

Lookup Core

Resolver outcomeTreatmentRecorded evidence
Answer RRsetDecisive positive.Normalized record-type and data signature, minimum answer TTL, DNSSEC authenticated-data flag when present, and latency.
NXDOMAINDecisive negative.Authority note and SOA-derived negative-cache hint when available.
NOERROR without answer dataDecisive negative for the selected record type.Authority note and negative-cache hint when available.
SERVFAIL, REFUSED, transport error, or unexpected replyInconclusive and excluded from the answer-rate denominator.Error, authority, DNSSEC, and latency details that may explain the failed observation.

Formula Core

Each lane's answer rate divides positive decisive replies by all decisive replies in that lane. Rates are rounded to one decimal place.

R=NanswerNdecisive×100%

The primary lane is leaf when decisive leaf replies exist, otherwise deep, otherwise boundary. The leading-cluster rate uses the most common normalized RRset signature divided by all positive decisive probes, so it measures agreement among answers rather than the chance of receiving an answer.

Rule Core

OrderVerdictExact condition
1No decisive DNS evidenceNo decisive random-name reply exists.
2No wildcard answers observedDecisive replies exist, but none contains an answer RRset.
3Known branch blocks the parent wildcardLeaf and boundary lanes both have decisive replies, leaf answer rate is at least 60%, and boundary answer rate is at most 25%.
4Deep names break from leaf behaviorLeaf and deep lanes both have decisive replies, leaf answer rate is at least 60%, and deep answer rate is at most 25%.
5Mixed public resolver viewAt least one positive and one negative decisive reply exist, and the primary lane is below 80% positive.
6Wildcard-like answers observedAt least one positive decisive reply exists and none of the earlier rules applies.

Negative-cache time is taken from an SOA record in the authority section. When both the SOA TTL and MINIMUM field are numeric, the smaller value is used; otherwise the available value is used. This is a repeat-timing hint, not a guarantee that every recursive resolver will expose the same cache lifetime.

Privacy and Accuracy Notes:

Every generated probe name, the selected record type, and optional DNSSEC flags are sent from the browser to the chosen public DNS-over-HTTPS resolvers. The default compares Cloudflare and Google; the larger set adds DNS.SB. Resolver operators may log queries according to their own policies, so do not test private or sensitive internal names through the public path.

Recursive answers can differ because of cache age, geographic routing, filtering, DNSSEC policy, or transport failure. Checking Disabled asks a resolver to return data without normal DNSSEC validation and can expose otherwise rejected answers; it does not make those answers trustworthy. Use authoritative queries and provider configuration as the final evidence for a production change.

References: