skip to content

In DNS, when does a delegation need glue records in the parent zone, and what goes wrong if they are missing or stale?

level: middleimportance: should knowfreq 36%

answer

  1. a chicken-and-egg lookup
  2. server name below the cut
  3. in-domain, sibling, unrelated
  4. addresses in the referral's additional section

basics

~20 s

Glue is address records for a child zone's name servers, kept in the parent and returned with the referral. It is needed when a server's name lies inside the child zone, which resolvers could not otherwise reach.

solid answer

~40 s

An `NS` record names a server; it does not give its address. If `dev.example.com` is served by `ns1.dev.example.com`, a resolver would have to ask `dev.example.com` where its own server is, a loop RFC 1034 §4.2.1 describes exactly. So the parent `example.com` also holds `A`/`AAAA` records for `ns1.dev.example.com` (**glue**) and hands them over in the referral's additional section. Glue is not authoritative data and is "only used as part of a referral response". A server with an **unrelated** name, such as `ns.example.net`, needs no glue: the resolver looks its address up separately. The classic failure is stale glue: the server is renumbered, the child's own `A` record is updated, but the parent still hands out the old address, and resolvers cannot reach the zone.

code

dns · 6 lines
dns
; example.com zone (parent): delegation of dev.example.com
$ORIGIN example.com.
dev      3600 IN NS   ns1.dev.example.com.  ; in-domain: needs glue
dev      3600 IN NS   ns.example.net.       ; unrelated: no glue here
ns1.dev  3600 IN A    192.0.2.53            ; glue
ns1.dev  3600 IN AAAA 2001:db8::53          ; glue

go deeper

for a junior

Recall that glue is an address record for a name server, stored in the parent zone, and needed when the server's name is inside the zone it serves.

for a middle

Explain the loop glue breaks, the in-domain, sibling and unrelated cases, and that glue travels in the referral's additional section without being authoritative.

for a senior

Treat a name-server renumbering as a two-zone change and expect stale glue to fail only for resolvers without cached child data, which makes it look intermittent.

for a principal

Choose server naming deliberately: in-domain names couple every address change to the parent, unrelated names add an external dependency, and mixing both limits the damage of either.

## The problem glue solves A delegation in the parent zone is an `NS` RRset: a list of *names* of servers for the child. To send a query, a resolver needs an *address*. For most names it can simply look the address up, but consider: - the parent `example.com` delegates `dev.example.com`; - the only server is `ns1.dev.example.com`. To learn the address of `ns1.dev.example.com`, the resolver would have to ask a server for `dev.example.com`, and the only such server is the one whose address it is trying to learn. RFC 1034 §4.2.1 describes this situation almost word for word: without extra data, "the NS RRs tell us that in order to learn a name server's address, we should contact the server using the address we wish to learn." The fix is **glue**: address records (`A` and `AAAA`) for the child's name servers, stored in the *parent* zone next to the delegation and returned in the **additional section** of the referral. RFC 1034 says these records "are only necessary if the name server's name is 'below' the cut, and are only used as part of a referral response". ## When glue is needed: three relationships RFC 9499 classifies the relationship between a delegation and each server named in it: | Relationship | Example for `dev.example.com` in `example.com` | Glue in the parent? | |---|---|---| | **In-domain** | `ns1.dev.example.com` | required, or the child is unreachable | | **Sibling domain** | `ns.ops.example.com` (inside another child of the same parent) | not strictly required, since the name resolves through its own delegation; glue saves that lookup | | **Unrelated** | `ns.example.net` | not possible: the name is outside the parent zone, so the resolver resolves it separately | The unrelated case is the most robust in one sense: nothing in the parent needs to change when the server is renumbered, because the address is published only in the server name's own zone and fetched from there like any other lookup. It has its own trap, though. If two zones name their servers only inside each other (the servers for `example.org` live under `example.net`, and those for `example.net` live under `example.org`), there may be no path in, and neither parent can hold glue for the other's names. ## Glue is not authoritative Glue sits in the parent's file but belongs, logically, to the child. RFC 1034 calls glue records "not part of the authoritative data", and RFC 2181 §5.4.1 ranks glue below data from the child's own authoritative answers. So a resolver that follows a referral using glue and then hears the child's own `A` record for `ns1.dev.example.com` should prefer the child's version. That ranking does not save you from stale glue. The resolver needs the glue to reach the child at all; if the glue is wrong, it never hears the child's corrected record. ## The stale-glue failure The most common glue incident happens during a renumbering: 1. `ns1.dev.example.com` moves from `192.0.2.53` to `198.51.100.53`. 2. The child team updates the `A` record inside `dev.example.com` and moves the server. 3. Nobody updates the glue in `example.com`, which still says `192.0.2.53`. 4. Resolvers following the referral send queries to the old address and time out, or reach whatever now answers there. Symptoms depend on caches: resolvers that already hold the child's own records keep working until those expire, while fresh ones fail. The fix is to update the parent glue in the same change as the child record, and to keep the old address answering until the parent's new glue has propagated. For a domain registered under a public top-level zone, the parent-side records are changed through the registration channel, not by editing your own zone file. ## Practical rules - Add glue for in-domain servers (and, where it helps, sibling-domain ones); an unrelated server name lies outside the parent zone, so the parent cannot carry its address at all. - Publish both `A` and `AAAA` glue if the server is reachable over both protocols. - Treat a name-server address change as a two-zone change: child record and parent glue together. - Prefer at least one server whose name is unrelated to the zone, so a glue mistake is not a total outage. - Remember that glue is unsigned; authenticating a delegation is the job of DNSSEC's DS record, which is a separate mechanism.

  • Where in a DNS referral does glue appear, and does the parent set AA when it returns it?
    Glue travels in the additional section of the referral, next to the child's NS set in the authority section. The referral as a whole has AA clear, because the parent is not authoritative for the child's names, and glue itself is not authoritative data; it is a hint for reaching the child.
  • Why can the example.org zone not simply hold glue for its unrelated name server ns.example.net?
    Glue is only meaningful for server names below the cut the parent is delegating. A zone holds only names at or below its own origin, and ns.example.net is outside the org zone entirely, so the org zone cannot carry its address. The resolver looks ns.example.net up through the net hierarchy instead, as it would any other name.

saying these in an interview costs you the question

  • Every NS record needs a matching glue record in the parent.
  • Glue records are authoritative data of the parent zone.
  • Updating the server's A record in the child also updates the parent's glue.
  • Glue is how a delegation is authenticated.
  • Out-of-zone name servers need glue too, or they cannot be found.