Lame Delegation / NS Mismatch at the Registry

What’s actually happening

The domain resolves for some people and dead-fails for others, and it often gets worse the longer you wait. dig @8.8.8.8 yourdomain.com comes back SERVFAIL while a query straight to the authoritative server answers fine. The pattern usually shows up right after you migrate DNS hosts or delete a subdomain's zone but leave its NS glue behind.

Common causes

• Parent (registry) NS records still list the old DNS provider after a migration to a new one
• A delegated subdomain zone was deleted, but the NS records delegating to it remain at the parent
• Nameservers listed at the registrar were never actually configured to host the zone (typo or never-created zone)
• One of several listed nameservers is lame — resolvers that happen to pick it get SERVFAIL while others succeed
• Glue records at the registry point to stale IPs after the nameserver's own address changed

How to fix it

1. Compare parent vs child NS setsRun dig +norec NS yourdomain.com @<a-root-or-tld-server> for the parent view and dig NS yourdomain.com @<your-authoritative-ns> for the child view. Every nameserver in the parent set must answer authoritatively (AA flag) for the zone. Any that don't are the lame ones.
2. Fix the NS records where they actually liveFor a root domain, edit the nameserver list at the registrar — that's the parent. For a delegated subdomain, fix the NS records in the parent zone at whoever hosts the parent. Editing NS records inside the child zone alone won't change what the registry hands out.
3. Remove delegation for zones you deletedIf you tore down a subdomain's zone, delete the matching NS (and any glue) records in the parent. Otherwise resolvers keep getting referred to servers that no longer host anything.
4. Confirm every listed nameserver responds authoritativelyQuery each NS by IP: dig @ns1.provider.net yourdomain.com SOA — you want the AA bit set and a real SOA. Drop or repoint any server that returns REFUSED or a non-authoritative answer.
5. Wait out the TTL, then re-verifyParent NS and glue are usually cached for 24-48h at the TLD level. After correcting them, recheck with DNSViz or Zonemaster to confirm the lame-delegation warning is gone before declaring it fixed.