How to monitor nameserver changes on your domains

To monitor nameserver changes, you need two things: a regular snapshot of the domain's NS records (plus the nameservers declared at the registry) and a comparison against the previous state. You can script that with cron and dig, or let a DNS monitoring service capture the state, compute the diff, and email you when something moves. The reason this matters: nameservers decide which DNS provider answers for the entire zone. A nameserver change you did not plan is either a mistake or an attack in progress, and both are worth knowing about the same day. Here is why NS records deserve their own alert, how to read a change depending on context, and the setup step by step.

Why nameservers deserve a dedicated alert

Most DNS records point to one thing. An A record moves your website, an MX record moves your mail. The NS record is different: it hands authority over the whole zone to a set of servers. Whoever controls those servers can rewrite every record at once, silently, including the TXT records that authenticate your email and the CNAME records behind your SaaS tools.

Legitimate nameserver changes are rare events. You migrate from your registrar's default DNS to Cloudflare, or from Cloudflare to Route 53, maybe once every few years, and you know it is happening because you changed the nameservers yourself. Any change outside that scenario is a red flag by default.

There is a subtlety that makes NS records worth watching from two angles. The registry stores the nameservers declared for the domain (visible via RDAP), while resolvers use the NS records actually served in DNS. Those two sets normally match. When they diverge, something is half-migrated, misconfigured, or being tampered with, and the divergence itself is a signal even before anything visibly breaks.

What a nameserver change means in context

Context	Likely meaning
Your domain, migration planned	Expected change, verify and move on
Your domain, no migration planned	Provider acted without telling you, or account compromise
Registry and DNS disagree	Incomplete migration or tampering, investigate today
Third-party domain you track	New hosting or DNS provider, launch prep, or a change of hands

On your own domains

If you planned a migration, the alert is your confirmation that the change went through. If you planned nothing, two explanations remain. The first is that an agency, a freelancer, or a hosting provider with access made a change and did not announce it. The second is worse: someone got into your registrar account and repointed the domain. That scenario is exactly how DNS hijacking starts, and the earlier you catch it, the smaller the damage.

One honest caveat: DNS data tells you what changed and when the change was detected, not who did it. To find the author, check the audit log of your registrar account and ask anyone who has access. The value of the alert is that you start that conversation the same day instead of weeks later.

On third-party domains you track

For domains you do not control, a nameserver change is intelligence. A competitor moving from shared hosting nameservers to Cloudflare or AWS is investing in infrastructure. A parked domain switching to real nameservers often precedes a launch. And a domain whose nameservers jump to an unrelated provider may have changed owners in practice, whatever the WHOIS still says. If you follow client, subsidiary, or competitor domains, NS changes are among the strongest signals you can get from public data.

Set up the alert with Domain Sentinel

The whole flow takes a couple of minutes per domain:

1. Add the domain to your watchlist.
2. Open the domain's detail page and enable DNS monitoring. The default checks include the NS records of the zone apex, so nameserver changes are covered without any manual record selection.
3. There is no step three for the registry side: change notifications already include the nameservers declared at the registry, taken from the domain's RDAP data.

Both checks run daily. Registry data is refreshed at 03:00 and the DNS snapshot runs at 04:00, so a nameserver change is picked up within a day, not within seconds. For NS records that trade-off is fine: legitimate changes are planned events, and even in an attack scenario a same-day email beats finding out from customers.

When something changes, the alert email shows the before and after of the record, so you can tell a familiar migration from an unknown provider at a glance.

Check the current state manually

Before turning monitoring on, record what your nameservers are supposed to be. Query the live NS records:

dig NS example.com

Cross-check against a second public resolver to rule out a stale cache:

dig NS example.com @1.1.1.1
dig NS example.com @8.8.8.8

Then compare with the nameservers declared at the registry, using an RDAP lookup or the DNS lookup tool. The two lists should match exactly. If they already differ before you start monitoring, that is your first investigation.

Start from a known-good baseline

Take five minutes now: list your critical domains, note the expected nameservers for each, and confirm registry and resolution agree. Then put those domains on a watchlist with DNS monitoring enabled. From that point on, the rule is simple: any nameserver alert you did not plan, and any divergence between registry and resolution, gets investigated the same day.