{{ summaryTitle }} {{ summaryValue }} {{ summaryLine }} {{ badge.label }} {{ badge.value }}
Use one public zone such as example.com. URLs are reduced to their hostname.
Pin a provider for repeatable evidence; resolver comparison can add the other public views.
Optional, comma or newline separated. Leave blank for a discovery-only check.
Evidence policy:

{{ workflowFeedback }}

Use 1-12 workers. The default six is suitable for ordinary NS sets.
workers
Use 1000-10000 milliseconds. The default 4000 milliseconds limits stalled provider paths.
ms
CheckStatusEvidenceReferenceCopy
{{ row.label }}{{ row.status }}{{ row.detail }}{{ row.reference }}
NameserverScopeStatusAddressesCNAMEActionCopy
{{ row.ns }}{{ row.scope_label }}{{ row.status }}{{ row.addresses }}{{ row.cname }}{{ row.action }}
PriorityAreaActionEvidence anchorCopy
{{ row.priority }}{{ row.area }}{{ row.action }}{{ row.anchor }}
ResolverStatusResponseTTLNS snapshotCopy
{{ row.resolver }}{{ row.status }}{{ row.response }}{{ row.ttl }}{{ row.ns_snapshot }}
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.
SRV / NAPTR Service Discovery Check Trace SIP/SIPS, XMPP, or LDAP discovery through NAPTR and SRV to terminal addresses with optional public resolver comparison.
DNS Delegation Trace Analyzer Trace a public hostname through DNS delegation and aliases, compare resolver views, and inspect DNSSEC or negative-cache clues.
Resolver Policy Difference Comparator Compare public DNS answers across open and filtered profiles to separate policy splits from cache or DNSSEC drift with repeatable evidence.

A DNS delegation is a handoff between two administrative zones. The parent publishes the child zone's nameserver (NS) records, and resolvers follow that referral to the authoritative servers that hold the child's records. A zone can be configured correctly on its own servers and still be unreachable when the parent lists the wrong hosts or provides unusable address information.

Glue records solve a circular dependency. If example.com is delegated to ns1.example.com, a resolver needs the nameserver's address before it can ask that nameserver about example.com. The parent therefore supplies an A or AAAA address with the referral. This address is glue rather than authoritative child-zone data, so the parent and child copies should agree.

In-domain host
A nameserver at or below the delegated zone. Missing address data is a critical glue failure because resolution can become circular.
Sibling host
A nameserver elsewhere below the same parent. Its address may still depend on parent-side sibling glue and deserves review when unresolved.
External host
A nameserver outside the delegated zone's parent branch. Its authoritative address normally comes from another DNS provider.

Nameserver targets must also be canonical hostnames rather than aliases. A CNAME at an NS target adds ambiguity to the authority path and conflicts with DNS rules for names used as nameservers. For signed zones, the delegation includes another parent-side object: the Delegation Signer (DS) record that links the parent trust chain to a child DNSKEY.

Delegation checks matter most during registrar changes, provider migrations, nameserver renames, and DNSSEC rollovers. Compare the published NS set with the intended cutover set, then inspect every authority host rather than accepting one successful website lookup. Cached recursive answers can hide a stale or partial change, and an unsigned zone is valid without a DS record.

A public recursive resolver view is useful triage evidence, not a direct capture of the parent referral. Before changing production delegation, confirm important findings with an iterative trace or a non-recursive query to the relevant parent and child authorities.

How to Use This Tool:

Check one public child zone and use the policy switches only for evidence your migration or operations runbook actually requires.

  1. Enter the Delegated zone. A full URL is reduced to its hostname, but the target must still be a valid public zone name.
  2. Choose a primary Resolver view. Add Expected nameservers during a cutover so a missing intended host fails and an unexpected observed host warns.
  3. Select the evidence policy. Compare public resolvers adds Cloudflare, Google, and Quad9 NS snapshots; Reject NS aliases checks CNAME answers; Inspect DS visibility checks parent-side DNSSEC evidence; and Require IPv6 for in-domain NS applies a local dual-stack requirement.
  4. Run the check and start with failures in Delegation evidence and Authority hosts. Use the Repair queue to separate registrar, child-zone, sibling, external-provider, and DNSSEC work.
  5. Confirm every high-impact result with a direct parent referral trace. Resolver disagreement is a reason to inspect TTLs and authoritative data, not to choose the most convenient answer.

Interpreting Results:

At risk means at least one evaluated rule failed. Typical failures are missing address data for an in-domain nameserver, a CNAME answer at an NS target, a missing required AAAA record, or an intended nameserver absent from the observed set. Review needed means no failure was found but at least one warning remains. Consistent means all evaluated pass-or-warn rules passed for the captured recursive view.

  • Missing in-domain addresses can prevent a resolver from reaching the child zone and should be checked at both the registrar or parent and the child authority.
  • A missing DS record is only a warning because it is normal for an unsigned zone. For a zone intended to be signed, verify the parent DS against the child DNSKEY before publishing or removing anything.
  • Extra observed nameservers warn when an expected set was supplied; missing expected nameservers fail.
  • Resolver agreement shows that the compared caches currently expose the same NS set. It does not prove that the parent referral or every authoritative server agrees.
  • The informational parent-certainty row always reminds you that recursive DNS-over-HTTPS evidence cannot replace an authoritative referral trace.

Technical Details:

Delegation review combines public DNS lookups with an ordered rule set. The selected resolver supplies the primary NS RRset, A and AAAA addresses for each authority host, optional CNAME answers, and optional DS evidence. Resolver comparison adds independent NS snapshots but does not change the primary host analysis.

Lookup Core

ObjectWhat is examinedWhy it matters
Child NS setAuthority hostnames returned for the delegated zone.Defines the observed delegation and the hosts that need address checks.
Authority addressesA and AAAA answers for every NS target.Shows whether a resolver can reach each authority host and whether selected IPv6 policy is met.
NS canonicalityCNAME answers at authority hostnames when alias rejection is enabled.An NS target should be a canonical name, not an alias.
DS visibilityDS records visible for the child name when DNSSEC inspection is enabled.Indicates a parent-side trust anchor, but absence alone cannot distinguish an unsigned zone from a broken signed delegation.
Resolver snapshotsNormalized NS sets from the selected public resolvers.Exposes cache or propagation disagreement without claiming authoritative certainty.

Rule Core

CheckPassWarnFail
NS set sizeAt least two authority hostnames.Exactly one hostname.No NS answer.
In-domain glueNo in-domain hosts, or every in-domain host has at least one A or AAAA answer.Not used.Any in-domain host has neither A nor AAAA.
Sibling dependencyNo sibling hosts, or every sibling host has an address.Any sibling host lacks both A and AAAA.Not used.
All authority addressesEvery authority hostname has an address.Any authority hostname lacks both A and AAAA.In-domain severity is raised separately by the glue rule.
CNAME at NS targetNo CNAME answer.Not used.One or more aliases when the check is enabled.
Required IPv6Every in-domain host has AAAA data.Not used.Any in-domain host lacks AAAA when the policy is enabled.
DS visibilityAt least one DS record.No DS record when inspection is enabled.Not inferred from visibility alone.
Expected NS alignmentObserved and expected sets match.No expected host is missing, but an extra observed host exists.Any expected host is missing.
Resolver agreementAt least two complete snapshots are identical.Snapshots are incomplete or differ.Not used.

The overall label uses the strongest result across the check rows: any failure produces At risk; otherwise any warning produces Review needed; otherwise the run is Consistent. The exposure chart uses transparent diagnostic points rather than a protocol score: in-domain scope contributes 2 points, sibling scope 1, a missing address contributes 3 for an in-domain host or 2 otherwise, a CNAME contributes 3, and glue exposure contributes 3 for missing in-domain address data, 1 for visible in-domain glue, or 1 for a sibling dependency.

Host scope is derived from the submitted zone name. A host at or below that zone is in-domain; a host under the remaining parent suffix is sibling; everything else is external. The check does not consult a public-suffix list, so delegated names at unusual hierarchy boundaries still need an authoritative trace.

Privacy and Accuracy Notes:

The public zone and generated authority-host queries are sent from the browser to the selected public DNS-over-HTTPS providers. Resolver comparison sends the NS question to Cloudflare, Google, and Quad9. Expected nameservers and the policy choices are used for local comparison, but resolver operators may apply their own logging and retention policies to DNS queries.

Results reflect recursive caches at one moment. A timeout, filtered response, stale TTL, split-horizon policy, or provider-specific behavior can change what appears without changing the parent delegation. Direct parent and child queries remain the decisive verification before a registrar, DNSSEC, or production nameserver change.

References: