Nameserver Reachability Monitoring: What It Catches That Record Monitoring Doesn't

Most DNS monitoring, including the core of what OneDollarDNS does, works by comparing values: what does this record say now, and did that change since the last check? That catches almost everything that goes wrong with a domain. It doesn't catch a nameserver that's still correctly listed in your NS records but has simply stopped answering.

That's a real, common failure mode, and it's the reason nameserver reachability monitoring exists as its own check, separate from watching for record changes.

The gap between "listed" and "working"

Your domain typically has two or more nameservers listed in its NS records, for redundancy:

example.com.    NS    ns1.example.com.
example.com.    NS    ns2.example.com.

Nothing about that record set tells you whether ns1.example.com is actually up, responding within a reasonable time, and returning correct answers. A resolver querying your domain picks one of the listed nameservers (the exact selection algorithm varies by resolver) and asks it. If that nameserver is down, slow, or misconfigured, the resolver either falls back to a different one in your set or, in the worst case, times out and the lookup fails for that user.

This is called lame delegation: a nameserver is listed as authoritative for a zone but isn't actually serving it correctly, whether because it's offline, misconfigured, or no longer has the zone data at all. The NS record hasn't changed. Nothing looks wrong from a record-comparison standpoint. But a fraction of queries, sometimes a large fraction, are failing.

Common ways this happens

One nameserver in a pair goes down and stays down. Secondary nameservers are often run on infrastructure that's easy to forget about. If the process crashes, the disk fills up, or the VM gets reclaimed, and nobody's watching that specific server, the domain keeps working (queries just route to the surviving nameserver) until that one also has a bad day.

A nameserver holds stale or missing zone data. If zone transfers between a primary and secondary nameserver break silently, the secondary keeps answering queries, but with an old copy of the zone. Some resolvers get the current data, others get whatever the secondary last synced.

Firewall or network changes block DNS traffic to one nameserver. A security group rule, a change in cloud provider networking, or an IP change upstream of the nameserver can cut it off from the internet on port 53 while everything else about the server looks healthy.

A self-hosted nameserver runs out of resources. BIND, PowerDNS, and similar servers under memory or CPU pressure can start timing out on queries intermittently, well before they'd be considered fully "down."

None of these change your NS records. All of them degrade what a fraction of your visitors, or your mail servers, actually experience.

How nameserver reachability monitoring works

Rather than only checking what your NS records say, this monitors whether each nameserver listed in that set is actually answering, by querying it directly:

1. Every nameserver in your domain's NS record set is queried independently, not just whichever one happens to answer first.
2. Each query checks for a timely, valid response, not a timeout, refusal, or SERVFAIL.
3. If a specific nameserver stops responding correctly while the others in the set are still fine, that's flagged on its own. It's a distinct signal from "your NS records changed," and it's often the earlier warning.

This is complementary to NS record monitoring, not a replacement for it. Record monitoring catches the high-severity case: someone changed which servers are authoritative for your domain at all, which is the scenario covered in What NS Records Are. Reachability monitoring catches the case where the delegation is exactly what it should be, but part of it isn't actually working.

What to do when a nameserver alert fires

Confirm it against a public resolver first, since a single check timing out could be transient network noise rather than a genuinely down server:

dig @ns1.example.com example.com SOA
dig @ns2.example.com example.com SOA

If one nameserver responds and the other doesn't, or responds with clearly wrong or stale data (compare the serial number in the SOA response), you've confirmed a real problem with that specific server. If you manage it yourself, check the process is running and the zone data is current. If it's provided by your DNS host, this is worth reporting to them directly. Either way, it's better to find out from a monitoring alert than from a support ticket that says "email works for me but not for my coworker."

How this fits with everything else OneDollarDNS monitors

Record-change monitoring answers "did anything in my zone change." Reachability monitoring answers a different question: "is my delegation actually working end to end, right now." Both run continuously against your domain, and both generate the same kind of alert when something's off, so you're not left digging through logs to figure out which one caught the problem.