DNS Glue & Delegation Check

Introduction

DNS delegation is the handoff that lets a parent zone send resolvers to the nameservers responsible for a child zone. The parent publishes the child zone's NS records, and resolvers use those hostnames to continue the lookup. Glue is the address data that prevents that handoff from looping back on itself when a delegated nameserver is inside the child zone it is supposed to answer for.

The fragile case is an in-domain nameserver such as ns1.example.com for example.com. A resolver needs an address for ns1.example.com before it can ask the example.com zone anything. If the only place to learn that address is inside example.com, the resolver has no useful starting point. Parent-side glue carries the A or AAAA address beside the NS referral so the resolver can reach the authority server.

Nameserver placement changes the repair path. External nameservers normally resolve through another independent zone. Sibling nameservers live under another child of the same parent, so they are often reachable through ordinary follow-up lookups, but they can still create fragile dependency chains during provider moves or cyclic sibling arrangements. Delegation repair is therefore not just a question of whether an NS record exists; it is a question of whether every authority hostname can be reached from the referral path a resolver actually follows.

• Registrar or registry changes can update the parent NS set while old host objects or glue addresses remain behind.
• DNS provider migrations often expose expected-list drift because some recursive resolvers still see the old delegation.
• DNSSEC rollouts add DS records to the parent side, so a signed child zone can fail validation even when ordinary NS lookups appear healthy.
• Nameserver renames can leave CNAME aliases or stale address records where resolvers expect canonical authority hosts.

Delegation checks become most valuable during change windows. Registrar transfers, DNS provider migrations, nameserver renames, DNSSEC rollouts, and emergency rollbacks can leave parent NS records, child-zone host records, DS records, and resolver caches showing different stories for a while. One public resolver may still answer from cache while another has already refreshed, so a single successful lookup can hide a partial delegation problem.

A careful glue review separates several signals: the NS set that is visible, the address records for each authority host, whether any nameserver points through a CNAME, whether the expected nameservers match the observed delegation, and whether DS records are visible when the zone is meant to be signed. Those clues do not replace an authoritative parent referral trace, but they give a fast repair map before a broken delegation becomes a wider outage.

How to Use This Tool:

Run a quick resolver snapshot first, then enable the advanced checks that match the migration or incident you are investigating.

1. Enter the Domain as the delegated zone apex, such as example.com. If you paste a URL or email-like value, the check reduces it to the hostname before querying DNS.
2. Click Check Delegation. The summary shows the overall state, nameserver count, in-domain host count, sibling host count, glue-critical count, selected resolver, and likely parent zone.
3. Choose a fixed Resolver when you need repeatable evidence. Auto tries the supported public recursive resolvers in order and is useful for a quick first pass.
4. Turn on Compare resolvers during propagation checks or incident review. The Resolver Delta tab compares public resolver views by NS snapshot, response code, timing, TTL, DS count, and notes.
5. Paste an Expected NS list when you know the intended delegation. Missing expected hosts fail the alignment check, while extra observed hosts warn because they may be stale or transitional nameservers.
6. Keep Check CNAME on NS enabled for normal audits. Enable Check DS records when DNSSEC state matters, and use Require IPv6 on in-domain NS only when your runbook requires AAAA reachability for delegated hosts.
7. Read the tabs in repair order: Delegation Checks for verdicts, Authority Hosts for host evidence, Glue Exposure Map for concentrated risk, and Repair Queue or Runbook Commands for follow-up checks.

Interpreting Results:

At Risk means at least one failed check is present. The strongest glue failure is an in-domain nameserver with no visible A or AAAA address data, because the nameserver may be listed in the delegation but unreachable through the referral path.

Review means the evidence needs operator attention without proving a hard break. Common review cases include a single visible nameserver, missing address data for sibling or external authority hosts, disabled resolver comparison, no DS record for a zone that may be unsigned, or disagreement between public resolver snapshots.

Consistent means the evaluated checks passed for the selected options and resolver evidence. It is not a registrar-side guarantee. Use authoritative parent traces, registrar host records, and the generated command notes before closing a high-risk nameserver move.

• Glue critical marks in-domain nameserver hosts that need address attention.
• Expected drift means the observed NS set does not match the intended list you supplied.
• Resolver Delta disagreement can come from cache age, resolver policy, DNSSEC handling, propagation lag, or a real delegation split.
• Parent Lens is investigative context. Treat the likely parent and parent nameserver list as leads to verify with an authoritative trace.

Technical Details:

DNS glue is address data attached to a delegation referral. Current DNS guidance distinguishes in-domain, sibling, and cyclic sibling nameservers because a resolver can only follow a referral after it has a reachable address for the next authority server. In-domain glue is part of the core referral path, while sibling glue is often an optimization unless the sibling zones depend on each other.

Canonical nameserver hostnames are a separate requirement. NS records should name real authority hosts, not CNAME aliases. An alias adds another lookup where resolvers expect a stable server name, and it can prevent the required address data from appearing with the referral. The clean repair is to publish the canonical host in the NS set and make sure its address records match the parent-side glue where glue is required.

Rule Core:

Authority host scope is based on the checked zone and the likely parent. An in-domain host is at or below the child zone. A sibling host is below the same likely parent but outside the checked child. An external host sits elsewhere and normally depends on its own provider's A and AAAA records rather than glue in the checked parent.

The exposure score in the glue map runs from 0 to 3 for each nameserver signal. A score of 0 means that signal is clear in the current resolver evidence. A score of 3 marks the strongest repair pressure, such as required in-domain glue with no visible address data or a nameserver CNAME. Scores are triage weights, not protocol severity codes; use them to find the concentrated failure, then verify the change at the registrar or DNS provider.

Recursive resolver evidence can show useful symptoms before an authoritative trace is collected. It can also hide parent-side detail because recursive resolvers answer from cache, apply their own DNSSEC policy, and may retry or normalize responses before a browser receives them. For final delegation work, compare the recursive snapshot with direct parent referral output from an operator environment.

Limitations, Privacy, and Accuracy Notes:

The check sends the domain and DNS questions from your browser to the selected public resolver. Those providers can see the names you query according to their own logging and privacy policies. The page does not need registrar credentials, DNS provider tokens, or zone-file secrets.

Public recursive DNS is strong triage evidence, but it is not the same as a packet capture of the parent zone's authoritative referral response. Cache state, resolver policy, transport failure, DNSSEC handling, and propagation timing can change what one public resolver returns. The likely parent label is also a cue for investigation, not proof of the delegation cut.

Before changing production delegation, verify failed glue, CNAME, DS, and expected-NS findings in the registrar or DNS provider control plane. When the result includes command output to run, execute it from a trusted operator environment and compare the answers with the registrar-side records.

Worked Examples:

A zone delegated to ns1.example.com and ns2.example.com should show both hosts as In-domain. If ns2.example.com returns no A or AAAA answer, the in-domain glue check fails, the host row shows missing address data, and the repair queue points to parent-side glue plus matching child-zone host records.

During a move from old provider nameservers to ns1.newdns.example and ns2.newdns.example, paste those two hostnames into the expected list. If a resolver still returns an old nameserver, expected alignment warns or fails. Resolver comparison then shows whether the mismatch appears across the selected public views or only in one cached resolver.

For a signed zone, a missing DS warning needs context. It may be harmless before DNSSEC is enabled, but it is a blocker if validators should already be able to follow the DNSSEC chain from the parent. Pair the DS warning with direct DNSKEY and parent-side checks before publishing, replacing, or removing DNSSEC material.

FAQ:

Glossary:

Glue record

Address data for a delegated nameserver, carried by the parent side so resolvers can reach that nameserver.

In-domain nameserver

A nameserver hostname at or below the delegated child zone, such as ns1.example.com for example.com.

Sibling nameserver

A nameserver hostname under another child of the same parent, which can create dependency risks in some layouts.

DS record

A delegation signer record in the parent zone that links a signed child zone into DNSSEC validation.

Recursive resolver

A resolver that answers clients from cache or by following the DNS delegation path on their behalf.

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.