What DNS monitoring catches (and what it can't)

6/18/20266 min read

DNS monitoring catches changes and failures in how your domain resolves: a record pointing at the wrong server, a nameserver that fell out of sync, an expired DNSSEC signature, an MX or SPF record that broke email overnight. These are failures an uptime check, busy reporting a cheerful 200 OK, will never surface. Knowing what DNS monitoring cannot catch matters just as much, because that blind spot is where some of the nastiest outages actually live.

This is a map of both sides: what DNS monitoring reliably catches, with the command you can run yourself to see the same thing, and what it structurally cannot catch no matter how good the tool is.

What DNS monitoring actually watches

Uptime monitoring answers one question: is the service responding? DNS monitoring answers a different one: is your domain still resolving to the right place, with the right records, from the resolvers your users actually use? It is a separate layer, and the two rarely fail at the same time.

A DNS monitor queries your domain on a schedule and watches a few things at once:

The records themselves: A, AAAA, CNAME, MX, NS, TXT, CAA and more, checked against the values you expect
Resolution success: whether a query returns an answer at all, or fails with SERVFAIL or NXDOMAIN
DNSSEC validity: whether the signatures on a signed zone still validate, or have gone bogus
Answer agreement: whether different public resolvers hand back the same answer, or disagree

What it catches

Here is where DNS monitoring earns its place. Each of these is a real failure mode, and each is invisible to a plain HTTP check.

A record that points somewhere new

The most common DNS incident is also the most boring: someone changes a record. A migration updates an A record, a script with the wrong credentials rewrites it, or an attacker who got into your registrar repoints your apex at their own server. The page may still load. It is not your page anymore.

You can see the current answer in one command:

dig +short example.com A
93.184.216.34

A monitor stores that value as a baseline and alerts when it moves. The cheapest reliable signal for any edit inside a zone is the SOA serial, which the operator is meant to bump on every change:

dig +short example.com SOA
ns1.example.com. hostmaster.example.com. 2026062801 7200 3600 1209600 3600

When that serial moves and you did not touch anything, something changed. That is the cue to diff the records and find out what.

Email breaking without a single error on your site

MX, SPF, and DMARC records all live in DNS, and they fail quietly. Drop or fat-finger an SPF record and your mail keeps leaving the building, it starts landing in spam folders. Nothing about your website looks wrong. A monitor that tracks the TXT and MX records flags the edit the moment it lands:

dig +short example.com MX
10 mail.example.com.

dig +short example.com TXT
"v=spf1 include:_spf.example.com ~all"

Without this, the first sign of trouble is usually a customer asking why your replies never arrived.

Nameservers drifting out of sync

If you run more than one nameserver, and you should, they can disagree. One gets an update the others miss, or the delegation at your registrar points to a server that no longer answers for the zone. Resolvers then get the right answer or the stale one depending on which nameserver they happen to hit, which produces the maddening "works for me" class of outage.

Querying each nameserver directly exposes the disagreement:

dig @ns1.example.com example.com A +short
dig @ns2.example.com example.com A +short

If those two answers differ, your zone is not consistent, and only some of your users are affected.

DNSSEC going bogus

DNSSEC adds cryptographic signatures to your records. While the signatures are valid, validating resolvers trust the answer. When the signatures expire or are wrong, those resolvers are required by the standard to refuse the answer and return SERVFAIL, which to a user looks exactly like the domain ceasing to exist.

This is not theoretical. On May 5, 2026, DENIC published incorrect DNSSEC signatures for the entire .de zone during a scheduled key rollover, and every validating resolver was obligated to return SERVFAIL. Millions of German domains went dark for users on validating resolvers while resolving normally for everyone else. Cloudflare documented how 1.1.1.1 saw the .de DNSSEC failure.

You can check the validation status of a zone yourself. The "ad" flag in the response header means the answer was authenticated:

dig +dnssec example.com
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 2, AUTHORITY: 0

Resolvers that disagree about your domain

Your laptop asks one resolver. Your users ask hundreds: their ISP resolver, 8.8.8.8, 1.1.1.1, Quad9, a corporate resolver. A change that reached one may not have reached another, and a poisoned or misconfigured resolver can hand back an answer no authoritative server ever published. Checking from a single machine hides this completely.

Querying several public resolvers and comparing the answers is the manual version of what a monitor does continuously:

dig @8.8.8.8 example.com A +short
dig @1.1.1.1 example.com A +short
dig @9.9.9.9 example.com A +short

Why your uptime monitor misses all of this

An uptime check resolves your domain once, connects, and reads the HTTP status. If a hijacked or misconfigured server answers with a 200, the check is satisfied. It cannot tell that the IP it resolved is not yours, that email is broken, or that validating resolvers are getting SERVFAIL while its own resolver is not. A green dashboard and a broken domain coexist comfortably.

The two checks answer different questions, which is the whole argument for running both rather than treating uptime as enough. For the related question of how often those checks should run, and which failure modes a given interval can and cannot catch, see how often you should check uptime.

What DNS monitoring can't catch

Here is the part most tool pages leave out. DNS monitoring has hard limits, and they come in two shapes: what it cannot prevent, and what it cannot see.

It detects, it does not prevent. A monitor tells you a record changed, after it changed. It cannot stop the bad edit, and when the change happens inside a provider you depend on, you are not the person who can fix it. The roughly fifteen hour AWS outage on October 20, 2025 came down to, in Amazon's own post-event summary, "a latent race condition in the DynamoDB DNS management system that resulted in an incorrect empty DNS record" for the regional endpoint. External monitoring would have shown that endpoint failing to resolve within minutes. It could do nothing about a race condition inside Amazon's automation.

It only sees as often as it looks. Every DNS monitor polls on an interval, whether that is once a minute or once a day. A record that breaks and self-heals between two checks leaves no trace. Faster polling narrows the window but never closes it, and since records change far less often than they break, most schedules lean toward the slower end anyway.

It queries from its vantage points, not your users'. A monitor checks from its own machines and a set of public resolvers. It does not see the stale record cached inside one customer's corporate resolver, or the answer their ISP is handing them. If the breakage lives in a resolver you cannot query, the monitor reports all clear while that user stays broken.

It only knows about DNS. A perfectly resolving domain in front of a crashed application is, to a DNS monitor, completely healthy. That is the reason it is a layer and not a replacement: it sits alongside uptime, SSL, and application monitoring rather than standing in for any of them.

How to start

You can begin with nothing but dig and cron. Snapshot the records you care about, save the output, and on each run compare the new answer against the stored one. Watch the SOA serial as a cheap change signal, and query a couple of public resolvers so you are not trusting a single answer.

One gotcha is worth knowing before you trust a script: a bare dig in a cron job does not always resolve the way it does in your shell, because cron runs with a stripped environment and can reach a different resolver, or none at all. Pin the resolver explicitly instead of relying on the box default, or you will get empty answers that read like outages:

# explicit resolver, short output, no surprise from cron
dig @1.1.1.1 +short example.com A

A hand-rolled script is genuinely fine for a domain or two. It stops scaling when you have dozens of zones, want history and alerting, need DNSSEC validated properly, or want answers checked from more than one network. That is where a dedicated service earns its keep.

WebPixie's DNS monitoring runs daily checks across more than 20 record types from multiple public resolvers (Google, Cloudflare, and Quad9), validates DNSSEC status, parses SPF, DMARC, and BIMI, and alerts when a record changes. The daily cadence is the same tradeoff as the cron script: it catches changes and drift, not sub-day flaps. That is the honest limit of any polled DNS check, hosted or homemade.

← Back to blog