The registry and the zone disagree about the nameservers
What this check looks for
The nameserver list held at your registry is not the list your own zone publishes. Which one a visitor uses depends on their resolver, so the domain behaves differently for different people.
Why it matters
This is how a nameserver you decommissioned months ago keeps taking traffic. Resolvers that learned the delegation from the registry keep asking the old server; resolvers that learned it from your zone ask the new one. Both are following the rules, and the two get different answers.
When the check passes, your report says: “The registry and the zone agree on the nameserver list”.
What it costs your score
When this check fails it removes 8 points from your DNS score, before the status, confidence and repeat multipliers are applied. DNS carries a weight of 10 in the overall score.
It shares the dns.health.delegation family ceiling of 35 points: however many findings that family produces, together they cannot remove more than that from DNS. One underlying problem showing up in several places is still one problem.
- Severity
- medium
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 8 points
- Family cap
- dns.health.delegation · 35
- Category
- DNS
- Module
- Dns health
- Fix owned by
- registrar
- In the ruleset since
- 2026.09
How to fix it
Make the NS set at the registrar and the NS records in the zone identical.
While they differ, some resolvers use nameservers you thought you had removed.
Decide which list is correct — normally the one your DNS provider currently serves.
Update the delegation at the registrar to match it exactly.
Update the apex NS records in the zone to match it exactly.
Wait for the parent's NS TTL (often 2 days) before concluding that a stale server has stopped receiving traffic.
How to confirm it worked
dig +short NS ‹domain› — the zone's own list
dig +norecurse @<tld-nameserver> NS ‹domain› — the registry's list; the two must match
A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.
Technical detail
Only at the registry: ‹only parent›. Only in the zone: ‹only child›. RFC 1034 §4.2.2 expects the delegating NS set and the zone's own apex NS set to be identical; RFC 2181 §5.4.1 makes the zone's own copy authoritative, but the registry's copy is what a resolver finds first, so both are used in practice. Fix both sides, not one.
Standards and references
Test this on your domain
Run the check that produces this finding, on its own, against any domain.
Other dns health checks
- A name has a CNAME alongside other records
- A glue record's address does not match the nameserver's own
- A nameserver inside the domain has no glue record
- A nameserver you delegate to does not answer for the zone
- The domain has fewer than two nameservers
- A nameserver name is an alias rather than a host
- All nameservers resolve to one address
- All nameservers sit in one network block
- A nameserver name has no address
- The delegation could not be checked
- A nameserver answers queries for domains that are not yours
- Your nameservers are serving different versions of the zone