DNS Delegation and Glue Records

How a delegation works

The point where one zone ends and a delegated child zone begins is called a zone cut. At the cut, the parent zone holds NS records for the child name, and the child zone holds its own SOA record and its own NS records at its apex. The parent's NS records are not authoritative data; they are a signpost. The child's NS records are the authoritative version.

When a resolver asks a parent server about a name below a cut, the parent does not answer the question. It returns a referral: a response with an empty answer section, the child's NS records in the authority section, and any glue in the additional section. The authoritative answer (AA) flag is not set, which is how you can tell a referral from a real answer.

Ask a .com server about example.com without recursion (output trimmed, illustrative):

$ dig +norecurse example.com NS @a.gtld-servers.net

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4721
;; flags: qr; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 3

;; AUTHORITY SECTION:
example.com.            172800  IN      NS      ns1.example.com.
example.com.            172800  IN      NS      ns2.example.com.

;; ADDITIONAL SECTION:
ns1.example.com.        172800  IN      A       192.0.2.53
ns2.example.com.        172800  IN      A       198.51.100.53

There is no aa in the flags line, the answer count is zero, and the two A records in the additional section are glue. The additional count of three includes the EDNS OPT pseudo-record that dig always reports. A resolver now knows where to send its next query.

Delegation is not only for registered domains. Inside your own zone you can delegate dev.example.com to a different team's servers by adding NS records for dev in the example.com zone. The same rules about glue apply.

When glue is required

Whether glue is needed depends on where the name server's own name lives relative to the delegation. RFC 9499, DNS Terminology, gives these cases names, and RFC 9471, DNS Glue Requirements in Referral Responses, sets out what an authoritative server must include in a referral.

RFC 9471 requires a server to include all available in-domain glue in a referral, and to set the truncation (TC) flag if that glue does not fit in the UDP response, so the resolver retries over TCP. Sibling glue is optional. Out-of-zone name servers cost the resolver an extra lookup, which is one reason many hosted DNS providers use name server names under their own domain: those names are already cached by most busy resolvers.

Avoid delegations where every name server is out-of-zone and points back at the zone being resolved, for example example.com served by ns1.example.net while example.net is served by ns1.example.com. With no glue to break the cycle, resolvers can fail to resolve either domain from a cold cache.

Glue at the registrar and registry

For a registered domain, you do not edit the parent zone directly. You tell your registrar which name servers to use, and the registrar passes that to the registry. If a name server is in-domain, the registry also needs its address. Registrars usually call this "registering a name server", "child name servers", or "host records", and in the registry's systems it is stored as a host object with one or more IP addresses.

That registry copy is separate from the A record inside your own zone. If you renumber ns1.example.com from 192.0.2.53 to 203.0.113.53, you must update both: the A record in your zone and the glue at the registrar. Forgetting the glue is a classic mistake. Resolvers that start from the parent keep receiving the old address, while resolvers that already cached the child's A record use the new one, so the failure is intermittent and hard to explain.

Parent and child NS records must agree

Because the delegation exists in two places, the two NS sets can differ. That happens when someone adds a name server at the provider but not at the registrar, or removes a retired server from the zone but leaves it in the delegation. Resolvers differ in which copy they prefer. Under the data-ranking rules in RFC 2181, authoritative data from the child outranks referral data from the parent, so many resolvers replace the parent's set with the child's once they see it. Others keep using the parent's set. The result is that different users reach different servers.

Lame delegation

A delegation is lame when a listed server does not actually serve the zone. It may not answer at all, it may return REFUSED, or it may answer without the AA flag. Resolvers eventually stop using a lame server, but every user who hits it first waits through timeouts and retries. Lame Delegation covers causes and fixes in more detail.

TTL mismatch

The parent's NS TTL is set by the registry, often a day or two for large TLDs. The child's NS TTL is whatever you choose. When you change providers, the parent TTL decides how long some resolvers keep sending queries to the old servers, which is why the old provider should keep serving the zone for a while. DNS TTLs and Caching Explained covers how those timers combine.

Checking a delegation yourself

Three dig commands answer most delegation questions. First, ask the parent what it delegates to, with recursion off. Second, ask each listed server for the zone's SOA, also with recursion off, and confirm the aa flag and matching serial numbers. Third, compare the NS set the child publishes.

1. What does the parent say?

$ dig +norecurse +noall +authority +additional example.com NS @a.gtld-servers.net

2. Does every listed server answer authoritatively, with the same serial?

$ for ns in ns1.example.com ns2.example.com; do
    dig +norecurse +noall +comments +answer example.com SOA @$ns | grep -E 'flags|SOA'
  done
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300
;; flags: qr aa; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
example.com.  3600  IN  SOA  ns1.example.com. hostmaster.example.com. 2026101501 7200 900 1209600 300

3. What does the child say?

$ dig +norecurse +short example.com NS @ns1.example.com
ns1.example.com.
ns2.example.com.

A listed server responding without authority may be lame. REFUSED may reflect an ACL, and a timeout proves only a lack of response on that path; investigate those separately. Different SOA serials suggest a stale secondary only in a shared primary/secondary transfer topology. Independent primaries can use different serials, so compare the actual RRsets. Check discrepancies between parent and child NS lists against the intended delegation. Running dig +trace example.com shows referrals in order; the dig Command Deep Dive explains the flags.

How DNS Panopticon helps

Domain Visualizer collects a domain's NS and SOA records during every scan and groups the results under a Delegation category. It flags a domain with no NS records, warns when only one name server is listed, and reports a potentially lame delegation when a name server hostname does not resolve to an IP address, which is a common symptom of glue or name server records left behind after a migration. It also flags a missing or malformed SOA record and checks whether a DS record exists at the parent for DNSSEC.

Website Recon uses the authoritative name server names as one of its signals for identifying the likely DNS provider, which helps confirm that a delegation points where you expect after a provider change.

Zone Analyzer is useful for the child side. Load a zone export and filter for NS records to review sub-delegations such as dev.example.com, then filter by hostname to confirm the matching glue A and AAAA records are present and current.