Delegation Triage Brief
{{ normalizedDomain }}
{{ summaryHeadline }}
{{ finalOutcome.shortLabel }} {{ delegationSummary.badge }} {{ dnssecBadgeText }} {{ resolverDriftBadgeText }} {{ finalRecordType }} target Retry {{ formatDuration(negativeCacheTtlSeconds) }}
{{ dnsTraceHeroResolverLabel }} Root {{ dnsTraceHeroZoneLabel }} {{ finalRecordType }}
DNS delegation trace inputs
Examples: example.com, www.example.com, or https://www.example.com/path.
Use A/AAAA for web addresses, MX for mail, TXT for policy, or CAA for certificate rules.
Choose the public resolver used for the main trace before comparing other views.
{{ normalizedInputHint }}
Leave on for CDN or hosted names; turn off to test only the original label.
{{ follow_cname ? 'On' : 'Off' }}
{{ max_cname_hops }} hops
Range: 1-20 hops; 8 catches normal alias chains without hiding loops.
Queries A records for every NS hostname when enabled.
{{ show_ns_ips ? 'On' : 'Off' }}
Requires Resolve NS addresses; off keeps the expansion IPv4-only.
{{ resolve_ns_ipv6 ? 'On' : 'Off' }}
Compares apex NS and final-answer fingerprints across the three built-in resolvers.
{{ compare_resolvers ? 'On' : 'Off' }}
Keep on when diagnosing DNSSEC rollout, DS changes, or validating-resolver SERVFAIL.
{{ check_dnssec ? 'On' : 'Off' }}
Uses SOA authority data first, then ancestor SOA records when needed.
{{ inspect_negative_ttl ? 'On' : 'Off' }}
Topic Status Detail Evidence / next check Copy
Primary finding {{ primaryFinding.badge || 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 }}

                
Customize
Advanced
:

Introduction

A domain can fail long before a web server, mail host, certificate authority, or application ever sees the request. DNS is a distributed chain of referrals, caches, aliases, and signed or unsigned records. A change at a registrar, a parent zone, a child zone, or a public resolver can produce the same user-facing symptom: the name does not resolve as expected.

Delegation is the handoff that tells the DNS hierarchy which nameservers are responsible for a zone. A resolver normally starts with cached knowledge, follows referrals from the root toward the relevant zone, asks for the requested record type, and may follow a CNAME alias before it reaches the final answer. When any part of that path is stale, missing, refused, or validated differently, a simple record lookup can hide the real problem.

DNS trace concepts and why they matter
Concept Plain meaning Why it changes troubleshooting
Recursive resolver The DNS service a client asks for an answer. Its cache, validation policy, and filtering can differ from another resolver's view.
Authoritative zone The zone that publishes records for a domain name. A final answer is only meaningful after the correct delegated zone is found.
Zone apex The top name of an authoritative zone, usually visible through SOA evidence. A host below the apex is not expected to publish its own NS records.
CNAME alias A DNS name that points to another DNS name. Hosted platforms and CDNs often put the real final answer behind one or more aliases.
Negative response A response such as NXDOMAIN or NOERROR with no answer. Resolvers can cache missing-name and missing-type answers, delaying visible recovery.
DNS delegation path from resolver to root, parent zone, child zone, and final answer

Most DNS incidents fall into a small set of situations: a newly registered name has not delegated cleanly, a nameserver set changed at the parent, a CDN CNAME now points somewhere unexpected, mail records exist at the wrong label, DNSSEC data is out of sync, or a resolver is still serving an older cached view. The visible response code gives an important clue, but it is not the whole diagnosis.

NXDOMAIN means the resolver believes the name itself does not exist. NOERROR with no answer means the name exists, but not for the requested record type. SERVFAIL and REFUSED often point to resolver policy, validation failure, upstream trouble, or refusal rather than a missing application record. A reliable trace sorts those cases before the next check targets the right owner: registrar, DNS operator, CDN, mail provider, or validating resolver.

Resolver comparison is useful because public resolvers do not update or validate in perfect lockstep. Matching answers from several resolvers are stronger than one resolver's answer, but they still do not replace direct authoritative checks for high-risk cutovers, DNSSEC changes, or incident response.

How to Use This Tool:

Use one hostname per run. The input accepts a bare domain, a URL, or an email-style string, then traces the first usable hostname so the result maps to one DNS path.

  1. Enter the production name you want to inspect in Domain. If pasted text contains more than one hostname, only the first hostname is traced and the rest are reported as ignored.
  2. Choose Final record type. Use A or AAAA for web addresses, MX for mail routing, TXT for policy records, and CAA for certificate authority rules.
  3. Select the main Resolver profile. Cloudflare, Google Public DNS, and Quad9 are available for the primary public DNS-over-HTTPS view.
  4. Open Advanced when the case needs more evidence. You can follow or stop CNAME chasing, set the alias hop limit, expand nameserver addresses, include nameserver IPv6 checks, compare built-in resolvers, check DNSSEC continuity, and estimate negative-cache retry timing.
  5. Click Trace. The summary badges show the normalized domain, final lookup outcome, delegation health, DNSSEC continuity, resolver drift, selected record type, and retry timing when a negative response can be estimated.
  6. Read Executive Brief first, then use Zone Ladder, Delegation Health Map, Evidence Trail, Resolver Delta, and JSON when you need the supporting rows or exportable evidence.

If validation reports an invalid domain, remove paths, spaces, wildcards, pasted commentary, ports, and private resolver-only names before retrying.

Interpreting Results:

Start with the primary finding, but do not stop there. A final answer is trustworthy only after the zone ladder makes sense. A clean final record with resolver drift still deserves a TTL and authoritative follow-up before a migration is treated as finished.

The health map groups each discovered zone by delegation, nameserver address coverage, and DNSSEC continuity. A warning near the top of the ladder usually points to a parent or registrar problem. A warning only at the final lookup often points to the requested record type, alias target, or cache timing.

DNS trace result cues and likely follow-up checks
Cue Best reading Good next check
Answer present The selected resolver returned one or more records for the requested type after any alias handling. Compare values, TTLs, and resolver delta against the expected production state.
No data The name exists from the resolver's view, but the requested record type was not returned. Check whether the record was published at the correct label and whether the correct type was selected.
NXDOMAIN The resolver believes the queried name does not exist. Verify spelling, zone publication, wildcard expectations, and negative-cache retry timing.
SERVFAIL or REFUSED The resolver could not or would not return a normal answer. Check DNSSEC, authoritative reachability, resolver policy, and another resolver view.
DNSSEC continuity gap DS evidence and DNSKEY evidence do not line up in the resolver-visible data. Confirm parent DS state and child signer publication before assuming application records are wrong.
Resolver mismatch Built-in public resolvers disagree on the apex NS set, final outcome, or final-answer fingerprint. Wait through relevant TTLs, then compare authoritative answers directly.
AD bit shown The selected resolver marked the final response as authenticated. Treat the bit as resolver-visible evidence, not as proof that every public resolver will validate the same way.

Technical Details:

DNS resolution is hierarchical, but normal application lookups hide most of the hierarchy. A recursive resolver may answer from cache, follow referrals, or return a validation failure before the client sees any authoritative data. The same hostname can therefore have several relevant truths at once: the parent delegation, the child zone content, the resolver's cached response, and the final record requested by the application.

A DNS-over-HTTPS query uses HTTPS as the transport for DNS messages. The record types, response codes, TTLs, CNAME rules, DNSSEC records, and negative-caching behavior remain DNS concepts. The main interpretation limit is vantage point: the result is what the selected public resolver can see at that moment.

Transformation Core

The trace follows the name from a normalized hostname to the nearest SOA-bearing zone, then checks delegation and final-answer evidence.

DNS trace technical stages
Stage DNS evidence What it separates
Hostname normalization The first usable hostname from a domain, URL, or email-style input. One trace is tied to one DNS name instead of a pasted batch.
SOA discovery SOA lookups from the full hostname toward parent labels. The nearest resolver-visible zone apex is identified before delegation is judged.
Zone ladder NS records for the root-to-apex chain. Parent delegation problems are separated from final record problems.
Nameserver address expansion A records, and optionally AAAA records, for each listed nameserver host. A visible NS set is separated from nameserver host address coverage.
CNAME walk CNAME records repeated until no alias remains, a loop is seen, or the hop limit is reached. Alias indirection is separated from the requested final record type.
Final lookup The selected A, AAAA, MX, TXT, or CAA record type. Answer present, no data, not found, refusal, server failure, and transport failure are classified separately.
DNSSEC continuity DS and DNSKEY evidence at non-root zone cuts. Signed, unsigned, and broken parent-child signing evidence are kept distinct.
Resolver comparison Apex NS fingerprints and final-answer fingerprints across Cloudflare, Google Public DNS, and Quad9. Propagation timing, cache skew, validation differences, and resolver policy differences can surface.

Formula Core

Negative caching is estimated from SOA evidence when a missing or empty answer can be cached. The retry cue uses the smaller usable value from the SOA record TTL and the SOA minimum field, matching the practical DNS rule that the shorter negative-cache limit controls the next meaningful retry.

negative cache seconds = min ( SOA TTL , SOA minimum )

Rule Core

DNS trace classification rules
Area Clear condition Review or break condition
Delegation NS records are visible for the zone cut. No NS records, resolver transport failure, SERVFAIL, or REFUSED.
Nameserver addresses Every expanded nameserver host returns address data for the enabled address-family checks. One or more expanded nameserver hosts return no address data, or there are no NS records to expand.
DNSSEC continuity DS and DNSKEY records are both visible for a signed zone cut. DS without DNSKEY is a continuity gap. DNSKEY without DS, or neither record, is treated as unsigned in this resolver view.
Final answer The requested final record type returns at least one answer. NOERROR with no answer, NXDOMAIN, refusal, server failure, or resolver transport failure.
Resolver delta The compared resolvers agree on the apex NS fingerprint and final-answer state. Any compared resolver returns a different apex NS view, final outcome, or final-answer fingerprint.

A hostname under a zone apex should not be judged as a failed delegation just because the hostname itself has no NS records. The delegated cut is the nearest SOA-bearing ancestor, while the endpoint host is judged by the requested final record type and any aliases that lead to it.

Limitations and Privacy Notes:

  • DNS queries are sent to the selected public DNS-over-HTTPS resolver. When resolver comparison is enabled, Cloudflare, Google Public DNS, and Quad9 can all receive the queried public hostname. Do not enter private hostnames unless those resolvers are allowed and expected to see them.
  • The trace reports one public resolver view, plus optional public resolver comparisons. It does not query every authoritative nameserver from every network.
  • Split-horizon, internal, private, or VPN-only DNS names usually need testing from the internal resolver that serves those names.
  • DNSSEC continuity checks are based on visible DS and DNSKEY evidence plus resolver response flags. They are troubleshooting clues, not a full cryptographic audit of every authoritative response.
  • Negative-cache timing is an estimate from SOA evidence. Resolver behavior can still differ because of cache age, resolver policy, stale-answer handling, or temporary upstream failures.

Advanced Tips:

  • Switch Final record type before tracing when the symptom belongs to mail, certificate issuance, or policy records. An intact A answer does not prove that MX, CAA, or TXT data is published at the same label.
  • Keep Follow CNAME chain enabled for CDN, SaaS, and hosted-platform names. If the chain reaches the CNAME chase limit, raise the limit only long enough to inspect the path, then audit the alias design for loops or excessive hops.
  • Use Resolve NS addresses when the zone ladder shows nameservers but users still cannot resolve the name. Missing address data for nameserver hosts can make a delegation look present while the servers remain hard to reach.
  • Turn on Include NS IPv6 when dual-stack reachability is part of the incident. A clean IPv4 nameserver address set does not prove that IPv6-only clients or validators have the same route.
  • Use Compare built-in resolvers during migrations and DNSSEC work. Matching Cloudflare, Google Public DNS, and Quad9 results reduce the chance that one cache is misleading you, but authoritative checks still decide production state.
  • Export the Evidence Trail or Zone Ladder before handing off an incident. The CSV and DOCX outputs preserve the resolver, record type, TTL notes, DNSSEC observations, and recommended next checks in a format that another operator can repeat.

Worked Examples:

New website record is missing. A team expects app.example.com to return an A record after launch. The zone ladder is intact and nameserver addresses are visible, but the final lookup reports No data. That points to a missing A record at the host label, not a broken registration.

CDN cutover is still uneven. The selected resolver returns the new CNAME target, but the resolver comparison shows another public resolver with the old final answer. The safer reading is cache or propagation drift until authoritative data and TTL windows confirm the change.

DNSSEC breaks after registrar work. A parent zone returns DS evidence while the child zone does not return DNSKEY evidence in the same public view. Validating resolvers may return SERVFAIL, so signer publication and registrar DS state should be checked before application records are changed.

Repeated not-found checks do not change. A typo or unpublished host returns NXDOMAIN with SOA evidence. Retrying before the negative-cache window expires can repeat the cached failure even after the zone is fixed.

FAQ:

Why does a trace show no data instead of not found?

No data means the name exists from the resolver's view, but the requested record type was not returned. NXDOMAIN means the resolver believes the name itself does not exist.

Does resolver agreement prove DNS propagation is complete?

No. Agreement across the built-in public resolvers is useful evidence, but direct authoritative checks and TTL timing still matter for critical migrations.

What does a CNAME limit warning mean?

The alias walk reached the configured hop limit or detected a loop. Audit the alias chain before relying on the final answer because excessive indirection can hide the real target.

Why inspect negative-cache TTL?

Resolvers can cache missing-name and no-data responses. The retry cue helps avoid repeating a lookup while the same cached negative answer is still likely to be served.

Does the AD bit mean every resolver will validate the answer?

No. The AD bit means the selected resolver marked that response as authenticated. Other resolvers may validate differently, lack the same cached data, or omit the bit for their own policy reasons.

Can public resolver tracing diagnose split-horizon DNS?

Only when the public resolver can see the same zone data. Internal DNS should be checked from the internal resolver, VPN, or authoritative server that serves the private view.

Glossary:

Delegation
A parent-to-child DNS handoff that points a zone toward its authoritative nameservers.
Recursive resolver
A DNS service that answers client lookups by using cache and upstream DNS queries.
Zone apex
The top name of an authoritative zone, usually identified through SOA evidence.
SOA
Start of Authority, the record that identifies authority and timing values for a DNS zone.
CNAME
An alias record that maps one DNS name to another DNS name.
NXDOMAIN
A DNS response code meaning the queried name does not exist in the resolver's view.
DNSSEC
DNS Security Extensions, the signing and validation system that uses records such as DS and DNSKEY.
Negative caching
Caching of failed DNS answers such as not-found or no-data responses.