Diagnose parent and child NS or glue differences

The parent zone delegates a child with NS records in a referral. The child zone also publishes an NS RRset at its apex. Those are distinct data under distinct control planes. Differences can be temporary during a reviewed migration, but unplanned differences can send resolvers to incomplete or unreachable authorities.

Glue is address data supplied in a referral. It is required when resolving a nameserver name would otherwise depend on first reaching the delegated child. It is not a separate DNS record type and is not required for every nameserver.

Scope the symptom

Capture:

• exact delegated zone;
• parent zone and delegation point;
• parent NS, glue, and DS;
• child-apex NS and SOA from every named authority;
• A and AAAA answers for every nameserver target;
• authoritative-answer and recursion flags;
• resolver, network, TTL, and observation time; and
• any active nameserver or DNSSEC migration plan.

The registrant or authorized registrar path controls parent delegation and submitted glue. The child DNS operator controls child-apex NS, SOA, zone contents, and authoritative service.

Read-only checks

1. Review the Domain Registration Lookup pathway for available parent-facing nameserver fields.
2. Use the DNS Lookup pathway to capture NS at the parent referral and child apex. Label which server produced each result.
3. Query every parent-listed and child-listed nameserver directly for child SOA, NS, and a known zone name with recursion disabled.
4. Resolve A and AAAA for every nameserver target from outside the child where possible.
5. For an in-bailiwick target such as ns1.example serving example, inspect the parent referral’s glue and compare it with authoritative address data.
6. Capture parent DS and child DNSKEY before treating a reachability problem as unrelated to DNSSEC.

RFC 9471 specifies when referrals need glue and distinguishes in-domain, in-bailiwick, and sibling glue behavior [3]. RFC 2181 ranks authoritative data above non-authoritative referral and additional data, so record which server and response section supplied each observation [2].

Interpret the observations

Observation	Supported interpretation	Responsible owner
Parent and child NS match; all answer authoritatively	Delegation and authority are consistent for the tested path	No corrective owner
Parent lists a server that is non-authoritative	The delegation is lame or the server is not ready	Registrar path and DNS provider
Child lists additional working servers absent at parent	Child data differs, but those servers are not selected by the parent referral	Child DNS owner
Parent and child sets differ during a documented overlap	A migration state may be intentional, but both sets must remain complete	Change owner
Required in-bailiwick glue is absent or wrong	Resolver reachability can fail before the child is reached	Parent glue owner
Glue differs from authoritative address data	Cached paths can reach different nameserver addresses	Parent glue and nameserver-address owners

Delegation establishes an administrative boundary [1]. DNS terminology distinguishes referral data, authoritative data, and glue; do not collapse them into one “NS result” [4].

Likely causes

• a parent nameserver change was made without updating or preparing the child;
• child-apex NS was copied from an old provider;
• one listed server has not loaded the zone or is answering non-authoritatively;
• nameserver A or AAAA data changed without corresponding required glue;
• a registrar UI retained stale host-object address data;
• IPv4 and IPv6 reachability differ;
• resolver caches still contain an earlier delegation or glue address; or
• the observed difference is a planned migration overlap without complete documentation.

Safe next actions

Stop before editing if no complete zone export exists, any intended server is non-authoritative, current DS state is unknown, the correct nameserver address is disputed, or the rollback owner is unavailable.

• Read-only: preserve the parent referral, every authority response, nameserver address, TTL, and timestamp.
• Reversible: correct child-apex NS only from the DNS provider’s reviewed source of truth and verify every server before changing the parent.
• Availability-impacting: correct parent NS or required glue only through the authorized registrar path, as one reviewed full-set change with a preserved prior set.
• Availability-impacting: if a cutover is incomplete and the prior service remains healthy, execute the approved full-set rollback while keeping both services available for cached delegations.

Do not delete a “duplicate-looking” child NS or glue address until its layer, owner, bailiwick, and cache window are identified.

Verification

Verify in order:

1. parent NS, required glue, and DS match the approved state;
2. every parent-listed authority answers authoritatively;
3. child-apex NS and SOA are consistent across those servers;
4. nameserver A and AAAA destinations are reachable on published paths;
5. named recursive resolvers return explainable results; and
6. required web, email, and verification records remain present.

During rollback or overlap, verify every old and new server that a cached delegation can still select.

What this evidence does not prove

An NS mismatch or glue observation does not by itself prove:

• which control plane contains the error;
• that all resolver paths fail;
• that every parent/child difference is harmful;
• that out-of-bailiwick nameservers need glue in this referral;
• that DNSSEC is healthy; or
• that a website or email application works once authority is reachable.

Next protocol layer

If the difference followed a delegation cutover, continue with website failure after changing nameservers. If recursive resolution ends in SERVFAIL, use the SERVFAIL path and preserve DNSSEC evidence. Once authority is consistent, move to the failing record or application layer.