DNS Delegation Health
Every domain has two copies of its nameserver list: the one the registry (your TLD's parent servers) hands out, and the one your own zone publishes at its apex. They are supposed to be identical — and when they drift apart, resolution gets slow, flaky, or breaks entirely. This check fetches the actual delegation the parent gives resolvers, compares it to your zone's own NS records, verifies the glue (the IP addresses the registry ships for nameservers that live inside your own domain), tests each delegated server to confirm it really answers authoritatively, and checks that DNSSEC is anchored — that a DS record at the parent has a matching DNSKEY in your zone. These are registry-side problems that a normal record lookup or a nameserver health check can't see.
Reviewed by the SysGlass team · Updated July 21, 2026
What it checks
- Parent vs zone NS sets agree — the delegation the registry hands out matches your apex NS records
- Glue records: present for in-bailiwick nameservers (e.g. ns1.example.com for example.com), and matching the zone's own A/AAAA
- Lame delegation: every delegated nameserver actually answers authoritatively (sets the AA bit) for the zone
- At least two nameservers (RFC 2182), and a note when they all share one network
- DNSSEC chain consistency: a DS at the parent has a matching DNSKEY at the child (and flags a DS with no key, or a signed zone with no DS)
- Shows the parent (TLD) server that returned the referral and the NS TTLs at the parent and the zone
How to read the result
- NS mismatch means the registry and your zone disagree on which nameservers are authoritative. Resolvers trust the registry's set, so any server only in your zone may never be queried — update the delegation at your registrar, or fix your apex NS RRset, so both match.
- Missing glue for an in-bailiwick nameserver is a bootstrap loop: to find ns1.example.com a resolver must already know example.com. The registry must publish that nameserver's IP as glue (a host record at your registrar).
- Glue mismatch means the registry ships an IP for your nameserver that the zone no longer uses — usually stale glue left after an IP change. Update the host record at your registrar.
- A lame nameserver is listed in the delegation but does not answer authoritatively for the zone — it slows every lookup and risks outages. Load the zone on it or remove it from the delegation.
- A DS record at the parent with no DNSKEY in the zone is a broken DNSSEC chain: validating resolvers return SERVFAIL and the domain fails to resolve for many users. Re-sign the zone or remove the DS to go cleanly unsigned.
Frequently asked questions
How is this different from a nameserver health check?
A nameserver health check inspects the servers your zone lists — are they reachable, IPv6/TCP/EDNS-capable, and in sync. This delegation check looks one level up: the link between your registry (the parent) and your zone. It compares the parent's delegation to your own NS records, verifies glue at the registry, detects lame delegations, and confirms DNSSEC is anchored. The two are complementary.
What is glue and when do I need it?
Glue is the IP address the registry publishes for a nameserver that lives inside the very domain it serves — for example ns1.example.com being authoritative for example.com. Without it, a resolver would have to look up example.com to find ns1.example.com, which it can't do yet. The registry supplies the address directly as glue. Nameservers in a different domain (like ns1.your-dns-provider.net) don't need glue from your registry.
What does a lame delegation mean?
A nameserver is delegated for your zone but doesn't actually serve it authoritatively — it doesn't respond, refuses, or answers without the Authoritative Answer flag. Resolvers still try it, so it adds latency and, if enough servers are lame, can make the domain unresolvable. Either configure the zone on that server or remove it from the delegation.
Why does the DS / DNSKEY check matter?
DNSSEC is anchored by a DS record at the parent that fingerprints your zone's signing key (DNSKEY). If the parent has a DS but your zone has no matching key — for example after a key rollover gone wrong, or moving DNS providers without re-publishing DNSSEC — validating resolvers consider the answer bogus and return SERVFAIL, so the domain stops resolving for those users. Removing the DS (going unsigned) or re-publishing the key both fix it.
My parent delegation couldn't be read — is that a problem?
Not necessarily. Some registries rate-limit or don't answer direct referral queries from every vantage point. When that happens the tool skips the NS-set and glue comparison but still tests each nameserver for lameness and checks the DNSSEC chain, and it tells you the comparison was skipped rather than guessing.