One of your nameservers doesn't exist. Who answers for your domain now?

Your domain hands out a list of nameservers. When anything on the internet wants to know where yourdomain.com lives, it asks one of them. You set that list once, probably when you moved DNS providers, and you have not looked at it since. So here is a fair question: if you ran dig NS yourdomain.com right now and checked that every host in the answer still exists, would they all pass?

Plenty of real domains fail that check. We scan a thousand live sites at a time, and the nameserver list is one of the quieter places things rot. Two examples from a recent run make the failure mode concrete, and one of them is funny in the way that only production DNS can be.

What a delegation is, and how one dangles

Your registrar publishes a set of NS records that delegate authority for your domain to specific nameserver hosts. ns1.yourdns.com, ns2.yourdns.com, that kind of thing. A resolver picks one, asks it for your records, and trusts the answer because the delegation says that host speaks for you.

The delegation is just a list of names. Nothing forces those names to keep existing. A nameserver host lives on some domain, and that domain can lapse, get deleted, or have been wrong the day you typed it. When one of the listed hosts hard-fails to resolve, NXDOMAIN on both A and AAAA, the host genuinely is not there, you have a dangling delegation. Part of your domain's authority points at a nameserver that's gone.

The reason this hides so well: the domain keeps working. The other nameservers answer, the site loads, mail flows, nothing breaks in a way you'd notice. The dead entry just sits in the delegation, doing nothing, until the day it can do something for someone else.

Why it's a takeover gap, not a typo

If the domain that dead nameserver lived on has lapsed and is registrable, an attacker can register it, stand up a nameserver on it, and step straight into your delegation as an authoritative source for your DNS. From there they can answer queries for your domain: point your records wherever they like, issue valid TLS certs for names they now control, redirect mail. It's the same broken-pointer pattern as a subdomain takeover via a dangling CNAME, aimed one level up at the delegation itself, which makes the blast radius the whole zone rather than one subdomain.

How big a foothold a single dangling nameserver gives depends on the resolver and how many of your nameservers an attacker controls. Sometimes it's intermittent, a fraction of queries landing on the hostile server; sometimes it's the whole thing. The point is that a delegated nameserver you don't own is a position inside your DNS that you didn't intend to grant, and you can't see it from the site.

Two real ones

A major-brand domain delegating to a host on a dead TLD. A household-name electronics company lists eight nameservers. Seven resolve and answer normally. The eighth points at a host on a top-level domain that no longer exists, so it hard-NXDOMAINs every time. The domain runs fine on the other seven, which is exactly why a stale entry like this survives for years: nothing forces a cleanup, because nothing is visibly broken. Even at that scale, the NS list is something somebody edited once and moved on from.

A site with three nameservers set to public resolver IPs. This is the funny one, and it is a real record we found. The domain's NS set included three entries that read like google.8.8.8.8, cloudflare.1.1.1.1, and google8.8.4.4. Someone meant to configure DNS resolvers and typed the resolver IP addresses into the nameserver-hostname fields. Those are not hostnames, they don't resolve to anything, and all three hard-NXDOMAIN. The two real nameservers carried the domain, so it worked, and the broken three sat there as a permanent reminder that DNS config is a text box and text boxes accept nonsense.

Both are the same finding underneath: a name in the delegation that does not exist. One came from corporate drift, one from a fat-fingered setup. Neither owner would have known without looking from outside.

How to check, and how to close it

This is checkable from anywhere, because your delegation is public. Pull the NS set and resolve every host in it:

dig +short NS yourdomain.com
# ns1.yourdns.com.
# ns2.lapsed-domain.com.
dig +short A ns2.lapsed-domain.com  &&  dig +short AAAA ns2.lapsed-domain.com
# (both empty -> NXDOMAIN -> dangling)

Any nameserver host that returns NXDOMAIN on both A and AAAA, while the rest of your set still answers, is a dangling delegation. Treat the name it lived on as claimable until you've confirmed otherwise. The fix is in your registrar, not on the dead host: remove the stale NS record, or repoint the delegation at a nameserver you actually run. Then make it a habit, when you change DNS providers, to delete the old delegation in the same sitting instead of leaving both sets live and letting one quietly expire.

A scan reaches this before you do because it's reading the same public delegation an attacker would. SurfaceCheckr resolves each of your nameserver hosts and reports the ones that hard-NXDOMAIN while the others survive, and it only fires on that unambiguous case, never a transient SERVFAIL or a timeout that's just a momentary glitch. We don't register the lapsed name to prove the takeover, and we can't see a nameserver you've never published. What we can do is tell you, in the time it takes to run a scan, that one of the hosts answering for your domain stopped existing a while ago.