Delegation and Glue

What delegation is

A zone hands a subdomain to another set of nameservers by publishing NS records in the parent zone. That is the whole mechanism.

; in the example.com zone (the PARENT)
dev     IN  NS  ns1.dev-provider.net.
dev     IN  NS  ns2.dev-provider.net.

From that point on, example.com's servers stop answering questions about dev.example.com and return a referral instead: an empty answer section, the NS records in the authority section, and the aa flag clear.

dig @ns1.example.com dev.example.com A +norecurse

;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 2, ADDITIONAL: 2

;; AUTHORITY SECTION:
dev.example.com.   172800 IN NS ns1.dev-provider.net.
dev.example.com.   172800 IN NS ns2.dev-provider.net.

The same NS records must also exist at the apex of the child zone. The parent copy drives resolution. The child copy is authoritative. They must match, and a mismatch is one of the two classic delegation bugs.

Glue records

If a nameserver's name is inside the zone it serves, resolution deadlocks: to find ns1.example.com you must ask example.com's nameserver, which is ns1.example.com. Glue breaks the cycle by putting the address in the parent's additional section.

; in the com zone, published by the registry via your registrar
example.com.       172800 IN NS  ns1.example.com.
example.com.       172800 IN NS  ns2.example.com.
ns1.example.com.   172800 IN A   198.51.100.10   ; <- glue
ns2.example.com.   172800 IN A   198.51.100.11   ; <- glue

# see the glue the TLD hands out
dig @a.gtld-servers.net example.com NS +norecurse
dig +trace example.com A | grep -A4 'IN.*NS'

Glue is created at the registrar, as a "host object", "registered nameserver", or "child nameserver" depending on the panel. You cannot publish it from your own zone, because the parent controls the additional section.

Stale glue outlives everything. Change ns1.example.com's address in your zone and forget the glue, and resolvers keep using the old IP from the parent for up to two days.

Changing nameservers

Two independent things to update, in this order.

1. Set up the new provider fully. Import every record. Verify by querying the new servers directly, before anything points at them. dig @ns1.new-provider.net example.com A +norecurse must return aa and the right answer. 2. Lower TTLs at the old provider if any record is about to change value. Nameserver changes and record changes at the same time make failures unattributable. 3. Update the NS records at the registrar. This changes the parent delegation, which is what actually moves traffic. 4. Update glue if your nameservers are in-zone. 5. Leave the old provider serving for at least 48 hours. The TLD's delegation TTL is typically 172800, and some resolvers hold it longer. 6. Verify from the top, not from your resolver: dig +trace example.com NS.

# what the parent says (the truth for resolution)
dig @$(dig +short com NS | head -1) example.com NS +norecurse +noall +authority

# what the child says (must match)
dig @ns1.new-provider.net example.com NS +norecurse +short

# both, compared
diff <(dig +short example.com NS @a.gtld-servers.net | sort) \
     <(dig +short example.com NS @ns1.new-provider.net | sort)

Lame delegation

A delegation is lame when the parent points at a server that does not authoritatively serve the zone. The symptom is intermittence, which is why it takes so long to diagnose.

Intermittent failure is the signature. With two NS records and one lame, a resolver that picks the good one succeeds and caches, so roughly half of cold lookups fail and every warm one works. Users report "sometimes the site is down", and it clears up the moment you test it.

Find it by asking every listed nameserver directly:

for ns in $(dig +short example.com NS); do
  printf '%-30s ' "$ns"
  dig @"$ns" example.com SOA +norecurse +noall +comments 2>&1 |
    grep -oE 'status: [A-Z]+|flags:[^;]*' | tr '\n' ' '
  echo
done

ns1.example.com.               status: NOERROR flags: qr aa rd
ns2.example.com.               status: REFUSED flags: qr rd

aa present on every server is healthy. Any REFUSED, SERVFAIL, timeout, or missing aa is a lame delegation.

host -C does the same check in one command:

host -C example.com
dig +nssearch example.com

Verification checklist

External checkers worth a minute during a migration: Zonemaster, DNSViz, intoDNS, and MXToolbox.

Gotchas

- NS records at the parent are the only ones that matter for resolution. Changing NS records in your own zone changes nothing about where traffic goes. - An NS record must point at a name with an A or AAAA, never a CNAME. A CNAME as an NS target is invalid and resolvers treat it as broken, not as an alias. - Registrar UIs conflate "nameservers" and "glue". Setting the nameserver list does not always update the host objects, and some panels require deleting the child host before you can change its address. - A delegation to a zone that does not exist yet is worse than no delegation, because NXDOMAIN gets cached against the whole subtree. - DNSSEC turns a nameserver change into a two-phase operation. The DS record at the parent must match a DNSKEY the new provider serves, or every validating resolver returns SERVFAIL. Remove the DS, wait out its TTL, migrate, then re-add. - Registry-level delegation TTLs are commonly 172800 and are not yours to lower. Plan two days, not two minutes.