DNS Glue & Delegation Check
Check DNS glue and delegation for a domain, flag in-domain or sibling nameserver gaps, compare resolver views, and build a repair queue.{{ summaryHeading }}
| Check | Status | What it means | Reference | Copy |
|---|---|---|---|---|
| {{ check.label }} | {{ check.status }} | {{ check.note }} | {{ check.reference || '-' }} |
| # | Nameserver | Scope | Status | Address state | Glue stance | A | AAAA | CNAME | Action | Copy |
|---|---|---|---|---|---|---|---|---|---|---|
| {{ idx + 1 }} | {{ row.ns }} | {{ row.scopeLabel }} | {{ row.status }} | {{ row.addressState }} | {{ row.glueStance }} | {{ row.a.join(', ') || '-' }} | {{ row.aaaa.join(', ') || '-' }} | {{ row.cname.join(', ') || '-' }} | {{ row.recommendation }} |
| Section | Name | Status | Address data | Detail | Copy |
|---|---|---|---|---|---|
| Likely parent zone | {{ parentCandidate || 'Unavailable' }} | Resolver context | - | This browser tool evaluates recursive DNS-over-HTTPS answers, not a direct parent referral capture. Treat this section as triage context. | |
| Delegation signer | Key tag {{ row.keyTag !== null ? row.keyTag : '-' }} | Alg {{ row.algorithm !== null ? row.algorithm : '-' }} / digest {{ row.digestType !== null ? row.digestType : '-' }} | DS | {{ row.digest || row.raw }} | |
| Delegation signer | {{ parentCandidate || 'Parent zone' }} | Not visible | DS | No DS records were visible in the selected resolver view. | |
| Likely parent nameserver | {{ row.ns }} | {{ row.addressState }} | A: {{ row.a.join(', ') || '-' }}; AAAA: {{ row.aaaa.join(', ') || '-' }} | Parent-side inventory candidate #{{ idx + 1 }}. | |
| Likely parent nameserver | {{ parentCandidate || 'This domain' }} | Unavailable | - | No likely parent nameserver inventory was returned. |
| Resolver | Status | Code | Time | TTL | DS | NS snapshot | Notes | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ row.resolver }} | {{ row.status }} | {{ row.code }} | {{ row.timeMs }} ms | {{ row.ttl !== null ? row.ttl : '-' }} | {{ row.dsCount }} | {{ row.nsSnapshot || '-' }} | {{ row.note }} |
| Priority | Area | Action | Why | Copy |
|---|---|---|---|---|
| {{ row.priority }} | {{ row.area }} | {{ row.action }} | {{ row.why }} |
{{ runbookText }}
Introduction
DNS delegation only works when resolvers can move from a parent zone to the child zone's authoritative nameservers. Glue records matter when a nameserver's own address depends on the zone being delegated. Without enough address evidence, a resolver can learn who should answer but still fail to reach that nameserver reliably.
The highest-risk case is an in-domain nameserver such as ns1.example.com serving example.com. The parent side needs address data for that host because asking the child zone for the address would require reaching the child zone first. Sibling nameservers are different: they live under a zone with the same parent, so they may resolve through another delegation path, but weak sibling visibility can still expose cyclic or operational dependencies.
Delegation checks are useful during registrar migrations, DNS provider moves, DNSSEC rollout, and nameserver renaming. A correct-looking NS list is not enough by itself. The address records, canonical hostnames, optional DS records, and resolver agreement all affect whether the delegation is ready to trust.
A single recursive snapshot cannot replace a direct parent referral trace, but it can quickly show whether the public resolver view has enough delegation and host-address evidence to guide the next repair step.
How to Use This Tool:
Start with the zone apex you are auditing, then add advanced evidence only when it matches the change or incident you are investigating.
- Enter the Domain as the delegated zone, such as
example.com. Pasted URLs are reduced to the host, and the normalized domain appears before results are trusted. - Run Check Delegation with the default resolver posture first. The summary shows pass, warn, or fail counts, nameserver count, in-domain and sibling badges, and the likely parent zone.
- Open Advanced and choose a fixed Resolver when repeatability matters. Auto tries the supported public recursive views in order and uses the first usable nameserver response.
- Turn on Compare resolvers during migrations or incident review. The Resolver Delta tab will show whether compared public recursive views agree on the NS set and DS visibility.
- Paste an Expected NS list during planned cutovers. The Expected NS alignment check marks missing intended nameservers as fail and unexpected nameservers as warn.
- Keep Check CNAME on NS enabled unless you are isolating another failure. Nameserver targets should be canonical hosts, and a visible CNAME answer is a repair item.
- Use Delegation Checks for the verdict, Authority Hosts for host-level evidence, Parent Lens for parent and DS context, and Repair Queue or Runbook Commands for follow-up.
Interpreting Results:
Start with the failed checks, not with the chart. In-domain glue visibility is the most important signal when nameserver hosts sit below the delegated zone. A missing A or AAAA result for an in-domain nameserver can break the path resolvers need to reach the child zone.
Sibling delegation visibility is a warning rather than an automatic fail because sibling glue is not always strictly required. Treat it seriously when the same parent zone, cyclic sibling dependencies, or weak address visibility could make resolution fragile during a provider move.
DNSSEC delegation visibility is contextual. A missing DS record is normal for an unsigned zone but important for a zone that is supposed to be signed. The Parent-view certainty warning is always present because the evidence comes from recursive DNS-over-HTTPS answers rather than a direct authoritative referral capture.
- Glue critical means an in-domain host needs address attention.
- Expected drift means the observed NS set does not fully match the list you supplied.
- Resolver Delta disagreement can be cache lag, resolver policy, or a real publication split.
- Runbook Commands should be verified from an operator shell before making registrar or DNS provider changes.
Technical Details:
DNS glue is address data carried with a referral so a resolver can reach a nameserver whose hostname would otherwise depend on the delegated zone. The same nameserver can be in-domain for one delegation and sibling for another, so scope is evaluated relative to the zone being checked.
Nameserver canonicality also matters. DNS CNAME records identify aliases, but nameserver targets are expected to be canonical hostnames that can resolve directly to address records. A CNAME result for an NS host creates avoidable indirection in a part of DNS where resolvers need stable authority targets.
Rule Core:
| Rule area | Pass condition | Warn or fail condition |
|---|---|---|
| NS set size | Two or more NS hostnames are visible. | No NS records fail. One NS hostname warns because most production delegations should not depend on one server. |
| In-domain glue | Every in-domain nameserver returns at least one A or AAAA address. | An in-domain nameserver with no visible address data fails. |
| Sibling visibility | Sibling nameservers return address data, or no sibling hosts are present. | A sibling nameserver with no visible address data warns for parent-side or cyclic dependency review. |
| Canonical NS hosts | No CNAME answers are found for nameserver hostnames when that check is enabled. | Any visible CNAME answer fails. Disabling the check produces a warning. |
| Expected NS alignment | The observed NS set matches the expected list exactly. | Missing expected hosts fail. Unexpected extra hosts warn. |
The host-level evidence classifies each nameserver as in-domain, sibling, or external. In-domain means the hostname is at or below the checked zone. Sibling means the hostname appears below the likely parent zone but outside the child zone. External means the hostname is somewhere else and usually does not need parent-side glue for this delegation.
| Scope | Glue stance | Main repair cue |
|---|---|---|
| In-domain | Required from parent | Publish matching A and AAAA glue at the parent and matching host records in the child zone. |
| Sibling | Sibling or cyclic | Confirm the parent zone handles sibling glue or that the sibling zone can resolve independently. |
| External | Not usually needed | Verify address records at the external DNS provider if no A or AAAA data is visible. |
The Glue Exposure Map uses rule scores from 0 to 3 for scope, address visibility, CNAME detection, and glue dependency. A higher score means a host-signal cell deserves more attention, but the repair queue remains the better source for what to change first.
Accuracy Notes:
The lookup sends the checked domain, selected resolver, DNS record types, and related options to public DNS resolvers. Results show recursive resolver evidence, not a direct registry, parent-zone, or authoritative trace. For final delegation work, confirm critical findings with an authoritative trace and registrar-side records.
Worked Examples:
A zone delegated to ns1.example.com and ns2.example.com should show those hosts as In-domain. If either host has no A or AAAA result, In-domain glue visibility fails and the Repair Queue points to the registrar or parent zone.
During a provider migration, an expected list of ns1.newdns.example and ns2.newdns.example can expose a partial cutover. If the published NS set still includes an old host, the expected alignment row warns or fails, and the resolver delta can show whether public recursive views are split.
If the result says no NS records were returned for a domain you know exists, first check the normalized domain and resolver selection. A URL path, typo, expired zone, or temporary resolver failure can produce a no-signal result before any glue rule is meaningful.
FAQ:
Is missing glue always a failure?
Missing address data for an in-domain nameserver is a failure because the parent referral needs that address path. Missing sibling or external address data is usually a warning that needs context.
Why does the tool warn about parent-view certainty?
The result is based on public recursive DNS-over-HTTPS answers. That is strong triage evidence, but it is not the same as capturing the parent zone's direct referral response.
Should every signed zone show DS records?
A signed delegation should have DS records at the delegation point. An unsigned zone normally will not. Treat a missing DS warning according to whether the zone is meant to be signed.
What should I do when a nameserver target returns CNAME?
Replace the aliased NS target with a canonical nameserver hostname and make sure that hostname has the required A or AAAA records visible through the right parent or provider path.
Glossary:
- Glue record
- Address data included with a referral so resolvers can reach a delegated nameserver.
- In-domain nameserver
- A nameserver hostname at or below the delegated child zone.
- Sibling nameserver
- A nameserver hostname below another zone delegated from the same parent.
- DS record
- A delegation signer record at the parent side that links a signed child zone into DNSSEC validation.
- Recursive resolver
- A resolver that answers client queries from cache or by following the DNS delegation path.
References:
- RFC 9471: DNS Glue Requirements in Referral Responses, IETF, September 2023.
- RFC 2181: Clarifications to the DNS Specification, IETF, July 1997.
- RFC 2182: Selection and Operation of Secondary DNS Servers, IETF, July 1997.
- RFC 4034: Resource Records for the DNS Security Extensions, IETF, March 2005.
- RFC 8484: DNS Queries over HTTPS, IETF, October 2018.