Delegation Triage Brief
{{ normalizedDomain }}
{{ summaryHeadline }}
{{ finalOutcome.shortLabel }} {{ delegationSummary.badge }} {{ dnssecBadgeText }} {{ resolverDriftBadgeText }} {{ finalRecordType }} target Retry {{ formatDuration(negativeCacheTtlSeconds) }}
{{ normalizedInputHint }}
{{ max_cname_hops }}
{{ primaryFinding.title }}
{{ primaryFinding.detail }}
Next check: {{ primaryFinding.command }}
{{ item.label }}
{{ item.hint }}
{{ item.badge }}
{{ item.detail }}
Recommended next checks
  1. {{ item }}
Zone Delegation NS set Address coverage DNSSEC Note
{{ row.zoneLabel }}
Parent: {{ row.parentZoneLabel }}
{{ row.delegationLabel }}
{{ row.rcodeLabel }}
{{ row.nsCount }} NS
{{ row.nsPreview }}
{{ row.addressCoverageLabel }}
{{ row.addressCoverageDetail }}
{{ row.dnssecLabel }}
{{ row.dnssecDetail }}
{{ row.note }}
# Type Node Evidence TTL / Note Copy
{{ idx + 1 }} {{ row.typeLabel }} {{ row.node }} {{ row.evidence }} {{ row.note }}
Resolver Apex NS view Final outcome Final values TTL / Note
{{ row.resolverLabel }}
{{ row.resolverUrl }}
{{ row.apexNsCount }} NS
{{ row.apexPreview }}
{{ row.finalOutcomeLabel }}
{{ row.finalRcode }}
{{ row.finalValuesPreview }} {{ row.note }}

                    
:

Introduction

DNS delegation tracing follows how a hostname becomes answerable, from the parent zone that points authority downward to the record set a recursive resolver finally returns. Looking only at the last answer often hides the real break, because the failure may start one or two authority handoffs earlier.

That matters during registrar moves, nameserver changes, DNSSEC rollout, CDN cutovers, and mail-routing incidents. An empty AAAA answer, a missing MX RRset, an NXDOMAIN response, and a stale recursive cache can all look like the same outage until the zone cuts, alias hops, and final answer are separated.

DNS delegation trace path from input host through SOA discovery, zone ladder checks, DNSSEC and nameserver evidence, CNAME chase, final lookup, and resolver comparison.

Delegation traces are also useful when the queried hostname is not itself a zone apex. The meaningful question is then where authority begins for the containing zone, not whether the hostname has nameserver records of its own. Separating host endpoints from true zone cuts prevents a normal host lookup from being mistaken for a broken delegation.

The main limit is viewpoint. Recursive resolvers do not all refresh at the same time, and they can disagree temporarily because of cache age, policy, or transport failure. A good trace therefore reads the path, the final outcome, and the retry timing together instead of trusting a single badge in isolation.

Technical Details

A practical trace begins by finding the nearest ancestor that returns an SOA record. That name acts as the working zone apex, which keeps a hostname such as www or mail from being mistaken for a delegation point of its own. From there the path can be read from the root downward through each parent-to-child handoff.

Each zone cut is evaluated through its visible NS set. When nameserver expansion is enabled, those hostnames are queried for A records and, optionally, AAAA records as well. That does not prove full authoritative reachability, but it does separate “nameservers are listed” from “nameserver host addresses are visible from this resolver view.”

The final answer stage is independent of the delegation walk. After the apex path is mapped, the queried hostname can follow a CNAME chain up to the configured hop limit, then the selected RR type is requested from the final target. Changing the final type from A to AAAA, MX, TXT, or CAA does not change the delegation path, but it can completely change whether the lookup ends as answer present, no data, or NXDOMAIN.

DNSSEC continuity is read with two resolver-side questions at each non-root zone cut: is there a parent-visible DS record, and is there child-visible DNSKEY material. Seeing both supports a secured path for that cut. Seeing neither is treated as unsigned. Seeing a DS without a returned DNSKEY is the more serious continuity-gap pattern because the parent view suggests the child should be signed.

Rule Core

DNS delegation trace result surfaces
Surface How it is derived How to read it
Trace scope The input is classified as a zone apex or a host beneath the nearest SOA-bearing zone. Prevents a host endpoint from being misread as if it were its own delegated zone.
Delegation continuity Each zone cut is checked for an NS answer and a clean resolver status. The first warning or failure row in the ladder is the best clue about where the handoff starts to break.
Address coverage Listed nameserver hosts are expanded to A and optional AAAA evidence. Helps distinguish a visible delegation from a nameserver set with weak address evidence.
DNSSEC continuity DS and DNSKEY responses are compared at each non-root zone cut. Unsigned and continuity gap are different outcomes and should not be conflated.
Final lookup outcome The chosen final RR type is resolved after optional alias chasing. This is where Answer present, No data, NXDOMAIN, SERVFAIL, and transport failures diverge.
Resolver drift The apex NS view and final-answer fingerprint are compared across Cloudflare, Google Public DNS, and Quad9. A mismatch signals differing recursive views, not automatic proof that one side is authoritative truth.

Negative-Cache Rule

The retry window is estimated from SOA evidence. The first choice is the authority section of the negative response. If that does not expose a usable SOA, ancestor SOA lookups are tried until a defensible retry value appears.

TTLnegative = min ( TTLSOA answer , SOAminimum )
Negative cache TTL terms
Term Meaning in the trace
TTL SOA answer The SOA record TTL returned in authority or ancestor evidence.
SOA minimum The minimum value carried inside the SOA record itself.
TTL negative The shorter of those two values, used here as the safest retry cue for a cached negative response.

Queries are made from the browser to the selected public DNS-over-HTTPS resolver. If resolver comparison is enabled, the apex NS lookup and the final RR lookup are repeated through the other built-in resolvers as well. There is no trace-specific backend in the middle, but the queried name still leaves the browser for those upstream DNS services.

Everyday Use & Decision Guide

Use the final record type that matches the incident you are actually debugging. A and AAAA are the natural first pass for web reachability, MX is the right question for mail routing, TXT is useful for policy or verification records, and CAA is about certificate issuance rules. A clean result for one type says nothing about the others.

Let Trace scope set your expectations early. When the summary says host endpoint, the walk stops at the nearest zone apex and then continues with the hostname lookup beneath it. That is exactly what you want for www, API names, CDN aliases, and mail hosts. It prevents a normal endpoint from being judged as if it should publish delegation records directly.

  • Keep Follow CNAME chain on when a hostname may front through aliases or a CDN edge. Turn it off only when you need to inspect the queried label without following the alias target.
  • Turn on Compare built-in resolvers during recent DNS changes or when some users report a different answer than others. That is the fastest path to a cache-divergence clue.
  • Use Resolve NS addresses when the delegation looks present but still feels weak. It can expose nameserver hosts that are listed yet have poor address evidence.
  • Leave Inspect negative-cache TTL enabled while chasing freshly published or freshly repaired records. The retry badge often explains why a fix is not visible yet.

Do not overread unsigned, AD not set, or a single resolver’s clean answer as final proof. Before escalating or editing the zone again, line up Final lookup outcome, Delegation continuity, and Resolver drift. If those three surfaces point in different directions, the next step is authoritative verification, not another blind change.

Step-by-Step Guide

One careful pass is usually enough to separate a delegation problem from a final-answer problem.

  1. Enter the target in Domain. The field accepts a domain, host, or URL, but if you see Enter a valid domain or host name, strip the input back to a real hostname and make sure it contains at least one dot.
  2. Choose Final record type. That choice controls what counts as success in Final lookup outcome.
  3. Open Advanced only when you need to change Resolver profile, the alias policy, nameserver address expansion, resolver comparison, DNSSEC continuity checks, or negative-cache inspection.
  4. Click Trace. When the run completes, Delegation Triage Brief should show the normalized host, summary badges, and a primary Next check command.
  5. Read Trace scope and Final lookup outcome first. That tells you whether you are looking at a host endpoint or apex trace and whether the requested RR type actually resolved.
  6. Open Zone Ladder and look for the first row that moves from green to warning or danger. That row is usually the best starting point for a manual follow-up.
  7. Open Evidence Trail to confirm alias hops, the final row, and any NX Cache note. If the target hits a loop or the hop cap, the warning rows appear here.
  8. Use Resolver Delta, Copy brief, CSV, DOCX, or JSON only after the trace matches the exact hostname and RR type you meant to test.

Interpreting Results

Final lookup outcome is the best starting point, but it is not the whole story. It tells you what the selected resolver returned for the chosen RR type. It does not tell you whether the delegation path was clean or whether other recursive resolvers agree with that view.

  • Answer present means the chosen RR type exists from that resolver view. Check Resolver drift before assuming every user sees the same result.
  • No data means the name likely exists, but not for the RR type you asked for. That is a type-selection or publishing question, not automatically a broken name.
  • NXDOMAIN means the resolver says the name does not exist. If Negative-cache retry window is populated, another immediate test may only repeat the same cached miss.
  • continuity gap under DNSSEC continuity is more serious than unsigned. The first suggests missing key material in a path that appears delegated for signing; the second only says no trust anchor was seen.

Resolver validation bit is supporting evidence, not a universal verdict. AD set helps, but it does not prove every zone cut is healthy. When confidence matters, confirm the first failing Zone Ladder row with authoritative checks outside this page.

Worked Examples

A hostname that resolves cleanly beneath a parent zone

Start with https://www.example.com/docs and keep Final record type on A. A healthy run will usually show Trace scope as host endpoint, Delegation continuity as delegation intact, and Final lookup outcome as Answer present. That combination says the resolver could walk the containing zone and return an address for the host, so the next question probably belongs to HTTP delivery rather than DNS delegation.

A name that exists but has no data for the chosen type

Now trace api.example.com with Final record type set to AAAA. If Delegation continuity stays clean but Final lookup outcome lands on No data, the name is probably present while the specific IPv6 record set is missing. The corrective path is to confirm whether the service should publish AAAA at all, or whether A is the intended record family.

A just-fixed host that is still inside a negative cache window

Trace new-api.example.com after a fresh publish and keep Inspect negative-cache TTL on. A tricky run might show Final lookup outcome as NXDOMAIN, Negative-cache retry window as 30m, and Resolver drift as 1 resolver mismatch. When Evidence Trail also includes an NX Cache row, the best reading is cache skew, not automatic publication failure. Wait out the retry window, then compare authoritative state before changing the zone again.

FAQ

Can I paste a full URL instead of just a hostname?

Yes. The input parser extracts the hostname from a URL and traces that host instead of the full string.

Why were extra pasted lines ignored?

The trace works on one hostname at a time. If several hostname-like lines are pasted, only the first one is used and the rest are reported as ignored.

Why did the form reject my input?

The parser expects a host-style name with valid labels and at least one dot. Empty labels, obviously malformed names, or plain prose will trigger the validation error instead of a partial guess.

Does AD set prove DNSSEC is correct all the way down?

No. It only means the resolver marked the final response as authentic data. You still need the per-zone DNSSEC continuity rows and, when it matters, authoritative verification outside the recursive view.

What happens if there is an alias loop or a very long CNAME chain?

The trace stops, records a warning in Evidence Trail, and keeps the last reachable target. It does not chase aliases forever.

Does Resolver Delta tell me which resolver is right?

No. It only shows that Cloudflare, Google Public DNS, and Quad9 do not currently agree on the apex nameserver view or final answer fingerprint.

Glossary

Zone apex
The nearest name treated as the working start of authority because it returned an SOA record.
Zone cut
A parent-to-child delegation boundary where authority shifts to another zone.
No data
A response state where the name appears to exist but the requested RR type is absent.
Negative caching
Temporary storage of a negative response such as NXDOMAIN or a no-data answer by a recursive resolver.
AD flag
A response flag showing that the resolver marked the returned data as authentic after its own validation.

References