{{ summaryTitle }}
{{ summaryValue }}
{{ summaryLine }}

DNS route visual unavailable.

Loading DNS route visual…

Enter one public domain or host, such as www.example.com.
Use A/AAAA for addresses, MX for mail, TXT for policy, or CAA for certificate authority rules.
Choose the public resolver vantage point used for the main evidence trail.
Keep this on for hosted platforms and CDNs; turn it off to inspect only the original label.
{{ followCnameEnabled ? 'On' : 'Off' }}
Only the first usable hostname was traced; {{ ignoredExtraLines }} additional lines were was ignored.
Use 1–20 hops; eight covers ordinary CDN and hosted-service chains.
hops
{{ option.help }}
{{ option.enabled ? 'On' : 'Off' }}
FindingStateEvidenceNext checkCopy
{{ row.finding }}{{ row.state }}{{ row.evidence }}{{ row.nextCheck }}
ZoneDelegationNS addressesDNSSECObservationCopy
{{ row.zone }}{{ row.delegation }}{{ row.addresses }}{{ row.dnssec }}{{ row.observation }}
{{ healthChartState === 'loading' ? 'Loading delegation health chart…' : 'Delegation health chart unavailable. Check your connection, then retry. CSV remains available.' }}
StepTypeNodeEvidenceStatus / TTLCopy
{{ row.step }}{{ row.type }}{{ row.node }}{{ row.evidence }}{{ row.note }}
ResolverApex NSFinal outcomeFinal valuesObservationCopy
{{ row.resolver }}{{ row.apex }}{{ row.outcome }}{{ row.values }}{{ row.note }}
DNS Propagation Checker Check DNS propagation across public resolvers, compare the intended record set, and identify cache holdouts with TTL and failure evidence.
DNSSEC Validator Validate a domain's DNSSEC trust evidence from parent DS through DNSKEY signatures and resolver AD signals with a focused 15-check report.
EDNS Options Inspector Inspect EDNS OPT responses from public DNS-over-HTTPS resolvers, compare requested and returned options, and keep replay evidence.
Trace CNAME Alias Chain Trace every visible CNAME hop for a public hostname and compare resolver views before verifying the terminal DNS answer and provider suffix.

A missing web page, mail failure, or certificate error may begin several DNS steps before the affected service. A recursive resolver must find the delegated zone, obtain the requested record, follow aliases when necessary, and apply its own cache and validation policy. A gap at any of those stages can produce an empty answer or an error.

Delegation is the parent zone's instruction about which nameservers serve a child zone. The child then publishes its own records, such as addresses, mail exchangers, policy text, and aliases. When parent and child information drift, some resolvers may keep serving cached data while others expose the change immediately.

EvidenceWhat it tells youImportant limit
NS recordsWhich nameserver names a resolver sees for each zone checkpointPresence alone does not prove every authoritative server is reachable or consistent.
CNAME chainWhere an alias redirects the final record lookupA loop or hop limit can stop the chain before the intended target.
DS and DNSKEYWhether parent and child signing material is visibleRecord presence is not a cryptographic validation of the chain.
Resolver comparisonWhether three public recursive resolvers currently return different fingerprintsAgreement is not proof of worldwide propagation.
Negative TTLHow long an NXDOMAIN or no-data answer may remain cachedResolver caps, elapsed cache time, and policy can shorten the observed wait.

A resolver-visible trace differs from an iterative authoritative trace such as dig +trace. It asks a chosen public recursive resolver for the checkpoints, so cache contents, filtering, DNSSEC validation, and resolver policy remain part of the evidence. That view is useful for reproducing a client's experience, but a suspected delegation break still deserves direct queries to parent and child authoritative servers.

Time to live (TTL) also shapes diagnosis. A correct record can coexist with an older cached answer until its TTL expires, and negative answers have their own cache lifetime. Repeating the same query from several resolver viewpoints helps separate a local cache issue from a broader publication problem.

How to Use This Tool:

Choose the public resolver viewpoint and final record that match the failing client or service.

  1. Enter one public hostname. A URL, wildcard name, or email-style value is reduced to its hostname; additional pasted lines are ignored.
  2. Select A or AAAA for addresses, MX for mail, TXT for policy data, or CAA for certificate-authority rules. Keep Follow aliases on for hosted services and content delivery networks.
  3. Choose Cloudflare, Google Public DNS, or Quad9, then run the trace. If it times out or fails, try another resolver and confirm that browser DNS-over-HTTPS traffic is allowed.
  4. Enable nameserver-address expansion, resolver comparison, DNSSEC continuity, or negative-cache estimation only when that evidence answers the current incident question.
  5. Read the Incident brief first, then inspect zone checkpoints and the evidence ledger. Use direct authoritative queries before changing delegation or signing records.

Interpreting Results:

Clear means no checkpoint or final-answer rule reached warning severity. Review means the evidence includes a warning, unsigned DNSSEC view, no-data outcome, or resolver mismatch. Break means a failed checkpoint, broken DNSSEC continuity, NXDOMAIN, SERVFAIL, REFUSED, or transport failure was observed.

A clear result is limited to the selected resolver's current view and the enabled checks. An unexpanded nameserver address or unchecked DNSSEC state is skipped rather than treated as healthy. A resolver mismatch is a prompt to compare caches and authoritative data, not proof that one resolver is wrong.

Treat No data differently from NXDOMAIN. No data means the name exists but the requested record type was not returned; NXDOMAIN says the queried name does not exist in that resolver's view. Confirm the intended record type before escalating either result.

Technical Details:

DNS evidence is collected through encrypted DNS-over-HTTPS requests to a public recursive resolver. The hostname's nearest visible SOA identifies a working zone apex, and zone checkpoints run from the root label through that apex. The final requested record is looked up after the optional CNAME chase.

Lookup Core

  1. Normalize one hostname and search its ancestors for the first SOA answer.
  2. Request NS records for the root and each zone down to the detected apex.
  3. Optionally resolve nameserver A and AAAA records and request DS plus DNSKEY records for non-root zones.
  4. Follow the first CNAME answer at each hop until no alias remains, a loop is found, or the 1 to 20 hop limit is reached.
  5. Request the selected final record. Optional comparison repeats apex NS and final-record lookups through all three built-in resolvers.

Resolver comparison lowercases and sorts returned values before building fingerprints. A mismatch is counted when another resolver differs from the baseline in apex NS values, final values, or the classified final outcome. At most two mismatches are possible because three resolver views are compared.

Rule Core

ScoreCheckpoint or outcome statesOverall result
0OK, secured, or final answer presentClear unless another check scores higher
1Skipped or not checkedClear, but the evidence was not collected
2Warning, unsigned, no data, or any resolver mismatchReview
3Failed, broken, NXDOMAIN, SERVFAIL, REFUSED, or transport errorBreak

Each zone's checkpoint score is the maximum of delegation, nameserver-address, and DNSSEC scores. The overall severity is the maximum checkpoint score, final-outcome score, and resolver-mismatch score. Counts of gaps remain diagnostic evidence; they are not added into the severity.

DNSSEC continuity is classified as secured when both DS and DNSKEY records are visible, broken when lookup transport fails or DS exists without DNSKEY, and unsigned otherwise. This presence rule does not verify signatures or prove that the DS digest matches a child key.

Formula Core

For an empty final answer, the negative-cache estimate uses the smaller usable value from the SOA record's TTL and MINIMUM field.

TTLnegative=min(TTLSOA,MINIMUMSOA)

The authority section of the empty response is checked first. If it has no usable SOA value, ancestor SOA answers are tried. A result of “not estimated” means no non-negative value was available, not that negative caching is disabled.

Privacy and Accuracy Notes:

Running a trace sends the hostname and requested DNS record types to the selected public resolver over HTTPS. Resolver comparison sends apex NS and final-record questions to Cloudflare, Google Public DNS, and Quad9. Each provider's own logging and privacy terms apply.

  • No DNS request is made until the trace is run.
  • The trace is not a direct authoritative-server walk and does not test every anycast site, resolver, or client network.
  • DNS answers, TTLs, caches, and signing records can change between runs. Save the time, resolver, and evidence needed for an incident handoff.
  • DS and DNSKEY presence is only a continuity clue. Use a validating resolver and direct parent/child checks for a DNSSEC incident.

References: