NS Delegation Consistency

Two NS sets exist for any domain. The parent zone holds the delegation NS (what your TLD points resolvers at). Your zone holds the in-zone NS (what your authoritative nameservers return when asked NS for the apex). When these two sets disagree, resolvers can land on a nameserver the other side has never heard of, which causes intermittent resolution failures and makes DNSSEC harder to keep coherent.

Warn: parent and zone disagree

RedScore queries the TLD nameserver directly for your delegation, then asks the recursive resolver chain for what your zone publishes. The evidence breaks the mismatch into two lists:

• only_at_parent: nameservers the TLD delegates to but your zone does not advertise. Resolvers will hit these and may get SERVFAIL, REFUSED, or stale answers.
• only_in_zone: nameservers your zone advertises but the TLD does not delegate to. Resolvers will rarely reach these because the parent never points at them.

Pick the source of truth, then sync the other side

Decide which set is correct, then make the other side match. Three common scenarios:

• Migration in progress. You moved DNS to a new provider but only updated one side. Decide whether the migration is finished. If yes, set both sides to the new NS. If rolling back, set both sides to the old NS.
• Nameserver added or removed without updating both sides. Decide whether the change is permanent, then mirror it at the registrar (parent side) or in the zone (in-zone side).
• Stale parent cache after a recent change. The parent is just slow. Wait one parent-zone TTL (commonly 24 to 48 hours for TLDs) and re-scan before assuming a real mismatch.

Updating the parent side

Edit the nameservers field in your registrar's domain control panel. Most registrars accept up to 13 hostnames. If any of your nameservers live inside your own domain (in-bailiwick NS like ns1.yourdomain.tld), the registrar must also publish glue A/AAAA records for them. Add those at the same time, or recursive resolvers will not be able to find your nameservers on a cold cache.

Updating the in-zone side

Edit the NS records in your DNS provider's zone editor. The set published here must exactly match the registrar's set: same hostnames, same spelling. Most providers create the in-zone NS records automatically when a zone is added, but they can drift if records were edited by hand or migrated between providers.

Verify the fix

• Run dig +short NS yourdomain @1.1.1.1. This reflects the in-zone view as a recursive resolver currently sees it.
• Query a parent TLD nameserver directly. For .com, .net, and .edu: dig +short NS yourdomain @a.gtld-servers.net. For other TLDs, run dig NS <tld> first to find a TLD nameserver, then query it the same way.
• DNSViz (dnsviz.net) renders the full delegation graph and flags any inconsistencies in red.
• Re-run the RedScore lookup once both sides have propagated.

Common pitfalls

• Forgetting glue records. If your nameservers live under your own domain, the parent registry must publish IP glue or resolvers cannot find them.
• Case and trailing dots. Hostnames are case-insensitive but should be published lowercase. Trailing dots are normal in zone files; most registrar UIs strip them.
• Declaring a mismatch before parent TTL has elapsed. Parent zones are cached for hours to days. Always wait one parent-TTL after a registrar change before assuming the change failed.
• Mixing NS rollovers with DNSSEC key rollovers. Each is hard alone; doing them together compounds the failure modes. Stage them.

If your scan returned a degraded result instead of a mismatch (note: "could not retrieve delegation" or similar), it is a scanner-side network failure rather than a real misconfiguration. Re-run the lookup; if it persists across multiple scans, check whether your TLD's nameservers are reachable over UDP/53 from public networks.