DNS Delegation & Glue — Conceptual Anatomy and Failure Signals

Opening spread — referral specimen and where glue shows up

Resolvers learn which nameservers hold a child zone through a referral from the parent. That referral is an NS set carried in the parent’s zone. If any nameserver listed lives inside the child zone itself, the parent often includes glue (A/AAAA) in an additional section so a resolver can reach that server without first querying the child zone.

Question: [example-child.] Referral (from parent): NS: ns1.[child.] ; delegation record (names only) NS: ns2.external. Additional (parent-supplied glue): A: ns1.[child.] -> [ipv4-address] ; glue present when NS is in child (ns2.external. has no glue here)
Marginal note: the Additional section is where a parent can include glue. If NS names are out‑of‑bailiwick, the parent will normally not include addresses.

Definitions — parent vs child authority and the role of glue

Parent authority: the zone above the delegated child. It publishes the NS delegation (a referral). Child authority: the zone that contains the delegated names and the authoritative answers for them. The delegation itself is a statement of "ask these nameservers for records about the child".

Glue is not part of the DNS data model in the child zone; it is a pragmatic convenience stored by the parent so that lookups avoid a routing circularity. When a resolver receives a referral that names servers inside the child, it may need an IP address to contact those servers before it can fetch authoritative data from the child. Parent-stored glue supplies those addresses in the additional section of the referral.

In-bailiwick: an NS whose name is within the child zone. Out-of-bailiwick: an NS whose name lies elsewhere. The "is the nameserver name inside the child?" decision determines whether the parent might need to supply glue.

Annotated fragment: In-bailiwick → parent may include glue. Out-of-bailiwick → resolver will resolve the nameserver's name normally (no parent glue expected).

Taxonomy map — delegation decision node and circular dependency

The taxonomy card at left shows the minimal branching: parent stores NS delegation; resolver must decide whether NS names are inside the child. If yes, the parent can provide glue (addresses) to break a circular dependency where the resolver would otherwise need the child's authoritative data to resolve the nameserver's name.

Conceptually, glue is an admission in the parent's zone: "we cannot let you ask the child to find its own nameservers' addresses, so here are the addresses we know." Glue is authoritative only for the purpose of bootstrap — the child’s own A/AAAA records are the ultimate source.

Concrete specimens — schematic examples (labels, not live records)

Example A — in‑bailiwick NS with glue

Authority (parent): NS: ns1.[child.] ; delegate to in-bailiwick name Additional (parent): A: ns1.[child.] -> [ipv4-address] ; parent-supplied glue to bootstrap Resolver inference: parent can direct the resolver to an IP so it can contact ns1.[child.] immediately.
Interpretation: glue appears in the additional section because the NS name lies within the child zone.

Example B — out‑of‑bailiwick NS (no glue)

Authority (parent): NS: ns1.external. ; nameserver outside child zone Additional (parent): (none from parent) Resolver inference: resolver must resolve ns1.external. via normal resolution; parent adds no glue since nameserver name is elsewhere.
Interpretation: no glue is expected; the resolver will follow normal name resolution for the external nameserver.

Example C — missing glue, bootstrapping ambiguity

Authority (parent): NS: ns1.[child.] ; in-bailiwick nameserver declared Additional (parent): (no A/AAAA given) ; glue missing Resolver inference: resolver sees NS inside child but has no address; it must attempt to fetch A/AAAA for ns1.[child.] — but that requires contacting authoritative servers for [child.], which are the same names. Circular dependency arises.
Interpretation: missing glue creates a bootstrap ambiguity; different resolvers may handle the situation by exploring cached data or treating the delegation as temporarily unresolved.

Failure anatomy — common patterns and observable symptoms

Below are conceptual failure modes and how they typically present when reading referrals, authority, and additional sections from parents and caches. These are descriptive signals — not operational remediation steps.

Missing glue (in-bailiwick NS, no parent A/AAAA)

Symptom: parent referral lists in-bailiwick NS but the additional section lacks addresses. Resolver behaviour varies: some will attempt to resolve the NS name (which requires the child), others will rely on cached glue or treat the child as temporarily unreachable. Observables: referral present, additional empty for the NS names.

Stale or mismatched glue

Symptom: parent provides glue pointing to addresses that the child no longer uses. Observables include disagreement between parent additional-section addresses and child’s authoritative A/AAAA records (if those are reachable). This can cause intermittent resolution depending on which source a resolver trusts for bootstrap.

Orphaned NS at parent

Symptom: NS entries remain at the parent long after the child stopped serving or after the child moved its authoritative names. Observables: referrals still reference nameservers that either refuse queries or respond with SOA for a different zone; this typically leads to resolution failures that manifest as repeated referrals without authoritative answers for the queried names.

Key observation: resolver behavior when encountering these symptoms depends on cached data and local implementation choices; reading the parent's authority and additional sections gives the primary clues to which mode applies.

Read‑the‑response specimen — how to infer delegation state

Below is a synthesized, schematic response fragment annotated with the inferences a resolver must make. Labels are schematic placeholders (not live data).

RESPONSE from parent for [child.] (referral) QUESTION: record for www.[child.] AUTHORITY: NS: ns1.[child.] NS: ns2.external. ADDITIONAL: A: ns1.[child.] -> [ipv4-address] ; glue present for in-bailiwick (no A for ns2.external.) Inference steps: - Parent authoritatively delegates [child.] to the NS set above. - ns1.[child.] is in-bailiwick and parent supplied glue — resolver can contact it directly. - ns2.external. is out-of-bailiwick; resolver must resolve its name separately.
Annotated summary: check the authority section for NS names, then the additional section for A/AAAA entries that match those names. A parent-supplied A/AAAA for an in-bailiwick NS is the primary signal of glue being provided.

Recap — compact indicators and further topics to read

Delegation is the parent’s publication of NS records for a child. Glue is a parent-side convenience: A/AAAA records included with the referral so resolvers can bootstrap contact to in-bailiwick nameservers. Out-of-bailiwick nameservers do not require parent glue.

  • Referral present + additional empty for in‑bailiwick NS: signal for missing glue / bootstrap ambiguity.
  • Authority lists NS names that disagree with child’s authoritative NS set: signal for inconsistent delegation.
  • Additional A/AAAA matching an NS name inside the child: clear parent-supplied glue used for bootstrapping.
  • Out‑of‑bailiwick NS with no glue: expected; resolver must resolve the NS name normally.

For conceptual follow-up reading, search RFC material on DNS delegation, NS records, and glue/bootstrap behavior to see normative descriptions of delegation semantics and resolver bootstrapping. This panel is focused on conceptual literacy and recognition, not operational change steps.

Final exhibition label: delegation hands the question "who is authoritative?" to the names listed in NS. Glue is the parent's tactical answer to "where do I reach those names?" when the names are inside the delegated zone.