Interpreting a subdomain delegation NS/glue mismatch

Two delegations, two different places to look

A domain can be “delegated” in two genuinely different senses, and conflating them is the usual reason a subdomain delegation problem takes longer to find than it should. Delegating example.com itself happens at the registrar: the registrar publishes the domain’s NS records (and any glue they require) into the .com zone, and a Whois/RDAP lookup shows exactly what’s on file there. Delegating dev.example.com to a different set of name servers — a common pattern when a SaaS platform, a separate team, or a different DNS provider is meant to run one piece of a larger domain — is an entirely different act: it’s a set of NS records published inside example.com’s own zone file, by whoever controls that zone’s DNS, with no registrar step at all and nothing a WHOIS/RDAP lookup on the domain will ever show you. RFC 1034 describes both as ordinary zone cuts, but only one of them is visible outside the DNS itself.

When subdomain glue is needed, and where it actually lives

The same circular-lookup problem that makes glue records necessary for a whole domain applies identically one level down. If dev.example.com is delegated to a name server called ns1.dev.example.com — a hostname inside the very subdomain being delegated, or inside the parent domain — resolving that name server’s address would normally mean asking a zone that hasn’t been reached yet, exactly the circularity RFC 8499 defines glue records to solve. The difference from apex-domain glue is entirely about where the fix goes: a whole-domain glue record is published by the registrar into the TLD zone, but a subdomain’s glue record has to be published directly in the parent zone’s own file — example.com’s zone, not the registrar’s nameserver settings — alongside the NS records that delegate the subdomain in the first place. A delegation set up by someone who only thought to check the registrar, because that’s where “glue records” usually live for a whole domain, is a common way this gets missed entirely.

The decision tree

Work through these in order rather than guessing which layer is broken:

1. Does the parent zone even show a delegation for the subdomain? Query the subdomain’s NS records with AdminKit’s DNS lookup tool. No NS records at all means the subdomain was never delegated in the parent zone — there’s nothing further down the chain to diagnose yet.
2. Do the delegated name servers resolve to an address? If one of them has a hostname inside the subdomain or parent domain and doesn’t resolve, that’s a missing glue record at the parent zone — the resolver can’t even reach the server to ask it anything, regardless of whether that server is correctly configured.
3. If the name servers resolve, do they actually answer authoritatively for the subdomain? Query one of the delegated servers directly for the subdomain’s own records. A timeout, refusal, or non-authoritative answer here is a lame delegation, not a glue problem — see glue records and lame delegation explained for how to confirm and fix that specific failure.
4. Does the subdomain’s own NS record set match what the parent delegates? A child zone listing a different (or larger) NS set than the parent isn’t automatically wrong — resolvers generally trust the child’s own answer once the referral succeeds — but if the parent’s list includes a server the child zone no longer recognizes as authoritative for itself, that’s a stale delegation left over from a provider migration, worth cleaning up even when it isn’t currently causing outright failures.

Why this looks like a registrar problem until it isn’t

The most common dead end in troubleshooting a broken subdomain delegation is spending time in the registrar’s control panel, where the whole-domain NS records and any apex-level glue are both correct and entirely irrelevant to the problem. Because a subdomain delegation lives one level deeper, in the parent zone’s own DNS records, confirming it means querying DNS directly rather than checking what the registrar has on file — the registrar genuinely has no visibility into delegations made inside a zone it merely delegates the apex of.

Next step

Run AdminKit’s DNS lookup tool against the subdomain in question, checking its NS record set first, then resolving each listed name server’s own A/AAAA record — that sequence is what the decision tree above walks through, and it’s the fastest way to see which step the delegation actually breaks at.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.