DNS Delegation Trace Analyzer
Trace DNS delegation online from zone cut to final answer, compare resolver views, and flag DNSSEC or negative-cache clues before rechecking.Delegation Triage Brief
| Topic | Status | Detail | Evidence / next check | Copy |
|---|---|---|---|---|
| Primary finding | {{ primaryFinding.title }} | {{ primaryFinding.detail }} | {{ primaryFinding.command }} |
|
| {{ item.label }} | {{ item.badge }} | {{ item.hint }} | {{ item.detail || 'No additional evidence' }} | |
| Recommended next check | Step {{ idx + 1 }} | {{ item }} | Use with the zone ladder and evidence trail tabs. |
| Zone | Delegation | NS set | Address coverage | DNSSEC | Note | Copy |
|---|---|---|---|---|---|---|
|
{{ 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 | Copy |
|---|---|---|---|---|---|
|
{{ 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.
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
| 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.
| 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 chainon 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 resolversduring 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 addresseswhen 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 TTLenabled 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.
- Enter the target in
Domain. The field accepts a domain, host, or URL, but if you seeEnter a valid domain or host name, strip the input back to a real hostname and make sure it contains at least one dot. - Choose
Final record type. That choice controls what counts as success inFinal lookup outcome. - Open
Advancedonly when you need to changeResolver profile, the alias policy, nameserver address expansion, resolver comparison, DNSSEC continuity checks, or negative-cache inspection. - Click
Trace. When the run completes,Delegation Triage Briefshould show the normalized host, summary badges, and a primaryNext checkcommand. - Read
Trace scopeandFinal lookup outcomefirst. That tells you whether you are looking at a host endpoint or apex trace and whether the requested RR type actually resolved. - Open
Zone Ladderand 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. - Open
Evidence Trailto confirm alias hops, the final row, and anyNX Cachenote. If the target hits a loop or the hop cap, the warning rows appear here. - Use
Resolver Delta,Copy brief, CSV, DOCX, orJSONonly 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 driftbefore 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 windowis populated, another immediate test may only repeat the same cached miss. - continuity gap under
DNSSEC continuityis 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 www.example.com 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
SOArecord. - 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
NXDOMAINor 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:
- RFC 1034: Domain Names - Concepts and Facilities, IETF, November 1987.
- RFC 2308: Negative Caching of DNS Queries, IETF, March 1998.
- RFC 4035: Protocol Modifications for the DNS Security Extensions, IETF, March 2005.
- RFC 8484: DNS Queries over HTTPS (DoH), IETF, October 2018.