DNS monitoring: which DNS failures take sites down, what to check, how often and how to alert

DNS monitoring means querying your domain's records from outside your infrastructure on a schedule and alerting when answers disappear, change unexpectedly or stop matching across nameservers. Most sites that go down because of DNS do so for unexotic reasons: an expired domain, a broken delegation, records lost or left stale during a migration, or an outage at the DNS provider. Check A/AAAA, CNAME, MX and NS against expected values every one to five minutes for critical hostnames, check delegation and domain expiry less often, and page only when several regions agree.

Why DNS failures need their own checks

An HTTP check against https://www.example.com will notice that something is wrong when DNS breaks. It will not tell you that DNS is the cause, and it often notices late. Resolvers cache answers for the record's TTL, so a deleted or changed record can keep working for minutes or hours from your probe's point of view while new visitors already fail.

DNS failures are also frequently partial. One of four nameservers serves an old zone. The IPv4 record is correct but the IPv6 record points to a decommissioned server. Mail breaks while the website stays up. A dedicated check asks the specific question and compares the answer to what you expect.

Which DNS failures actually take sites down

Expired domain registration

When a domain expires, the registry eventually removes or replaces its delegation. Website, API, email and every subdomain stop resolving at once. Auto-renewal fails silently more often than people expect: an expired card, a billing contact who left the company, a registrar account nobody can log into. Domain expiry is not a record you can query with dig, so it needs a separate check.

Broken delegation

Delegation is the NS set the parent zone (for example .com) hands out for your domain. It breaks when the NS records at the registrar point to nameservers that no longer host your zone, when a nameserver hostname stops resolving, or when one of several nameservers answers with stale data. A DNSSEC variant of the same problem: after switching DNS providers, the DS record at the registrar still matches the old provider's keys, and validating resolvers return SERVFAIL for everyone who uses them.

Wrong records after a migration

Migrations to a new DNS provider, CDN, load balancer or hosting platform are the most common source of self-inflicted DNS outages. Typical mistakes:

• Updating the A record but forgetting the AAAA record, so IPv6 clients hit the old server.
• Not copying MX, TXT (SPF, DKIM, verification records) or rarely used subdomains to the new zone.
• Switching NS at the registrar before the new zone is complete.
• Leaving a high TTL in place, so a wrong answer stays cached long after you fix it.

DNS provider outage

If all of your nameservers sit with one provider and that provider has a problem, cached answers keep some users working until their TTL runs out, then resolution fails. From the outside this looks like a slow, spreading outage rather than a clean cut. Checking the authoritative servers directly shows it immediately, without waiting for caches to expire.

Accidental changes

A record deleted in the provider's dashboard, a Terraform apply against the wrong workspace, a CNAME edited to point at a staging host. These are fast to fix once detected and hard to detect from an HTTP check while caches still hold the old answer.

What to check in DNS monitoring: A/AAAA, CNAME, MX and NS

Useful DNS monitoring compares answers against expected values, queried both from public resolvers and directly from your authoritative nameservers; a check that only asks whether a name resolves misses most real failures.

• A and AAAA for the apex and www and for every hostname your product depends on (API, app, auth). Expected value: the set of IPs you actually serve from. Alert on no answer, NXDOMAIN, SERVFAIL or an IP outside the expected set.
• CNAME for hostnames that point to a CDN, load balancer or SaaS platform. Expected value: the exact target. A changed target is either a planned change or an incident.
• MX for domains that receive mail. Expected value: your mail provider's hosts and priorities. Missing MX records do not take the website down, but they silently bounce support and billing email.
• NS as seen by the parent zone and as served by your own nameservers. Both sets should match your provider's nameservers. Also compare the SOA serial across all nameservers to catch one that stopped syncing.

You can do all of this by hand with dig, which is also the fastest way to verify an alert:

# Delegation as the parent zone sees it (.com/.net example)
dig +short NS example.com @a.gtld-servers.net

# Find the parent servers for other TLDs
dig +short NS org.

# Answers straight from your authoritative servers, bypassing caches
dig +short A example.com @ns1.your-dns-provider.net
dig +short AAAA example.com @ns1.your-dns-provider.net

# What a public resolver returns (cached view)
dig +short CNAME www.example.com @1.1.1.1
dig +short MX example.com @8.8.8.8

# SOA serial from every nameserver, should all match
dig +nssearch example.com

# DNSSEC: a validating resolver returns SERVFAIL on a broken chain
dig A example.com @1.1.1.1 | grep status

The difference between the authoritative answer and the resolver answer is the point. Authoritative queries show the truth right now. Resolver queries show what users get, including stale caches and DNSSEC validation failures.

How often to run DNS checks

Match the interval to how fast each failure hurts and how fast it can change:

• A/AAAA/CNAME for critical hostnames: every 1 to 5 minutes, the same cadence as your HTTP checks.
• NS set and SOA serial consistency: every 5 to 15 minutes. Delegation rarely changes, but when it breaks you want to know before caches expire.
• MX and TXT records: every 5 to 15 minutes. Mail delivery retries for a while, so a few minutes of delay costs little.
• Domain expiry: once a day is plenty, with warnings starting 30 days ahead.

Before a planned migration, lower the TTL of the affected records to something like 300 seconds at least one full old-TTL period in advance. That keeps a wrong answer from being cached for hours and makes your monitoring results reflect reality faster.

How to set up DNS monitoring step by step

1. List every hostname that matters: apex, www, API, app, auth, status, mail. Include hostnames used by mobile apps and webhooks, which people tend to forget.
2. Write down the expected value for each record type, ideally generated from the same source as your zone (Terraform, zone file) so it stays current.
3. Create record checks for A, AAAA, CNAME and MX with those expected values, run from several regions.
4. Add a delegation check: NS at the parent equals NS in your zone equals your provider's nameservers, and the SOA serial matches across all of them.
5. Add a domain expiry check for every registered domain, including the ones that only redirect.
6. Keep your HTTP checks. DNS checks tell you why, HTTP checks tell you whether users are affected.
7. Route alerts by severity, as described below, and test each route once.

For domain expiry, a small daily script that pings a heartbeat URL only while the domain is healthy works well, because a missing ping alerts you both when the domain is close to expiring and when the script itself stops running. The pattern is the same one described in heartbeat monitoring for cron jobs:

#!/bin/sh
# Runs daily via cron. Pings the heartbeat only if expiry is > 30 days away.
DOMAIN=example.com
EXPIRY=$(whois "$DOMAIN" | grep -iE 'Registry Expiry Date|Expiration Date' | head -1 | awk '{print $NF}')
EXP_TS=$(date -d "$EXPIRY" +%s) || exit 1
DAYS=$(( (EXP_TS - $(date +%s)) / 86400 ))
if [ "$DAYS" -gt 30 ]; then
  curl -fsS -m 10 "$HEARTBEAT_URL" > /dev/null
fi

WHOIS output differs between registries, so test the grep pattern for each TLD you own, or query RDAP instead, which returns structured JSON.

How to alert on DNS problems

DNS alerts are a mix of urgent and slow-burning problems, so they should not all go to the same place.

• Page immediately: a critical hostname returns no answer, NXDOMAIN or SERVFAIL, confirmed from at least two regions on two consecutive checks. Same for an A or CNAME of the main hostname that changed to a value outside the expected set.
• Team chat, business hours: MX or TXT changed, one nameserver out of sync (SOA serial mismatch lasting longer than 30 minutes), NS set differs from expected but still resolves.
• Email or ticket: domain expires in under 30 days. Escalate to chat at 14 days and to a page at 7 days, because by then nobody has acted on the earlier warnings.

Requiring agreement from several regions matters more for DNS than for most checks, because a single resolver or network path can return an odd answer for its own reasons. The broader techniques for this are covered in how to reduce false positive alerts.

Write the first verification step into the alert text: the exact dig command against the authoritative server and against a public resolver. Whoever is on call at 3 a.m. should not have to remember which nameservers you use.

Running DNS checks with m0nitor

If you prefer not to maintain this yourself, m0nitor offers a DNS monitor type alongside HTTP(S), TCP, ping, SSL certificate expiry and heartbeat monitors. Checks run from distributed probes in several regions, and an outage is confirmed by multiple locations before an alert fires. With alert workflows you can route DNS events differently from other monitors, for example notifying a chat channel, creating an incident or calling a webhook. The domain expiry script above pairs with a heartbeat monitor. Any other uptime tool or a set of scheduled dig scripts can cover the same ground.

FAQ

What is DNS monitoring?

DNS monitoring is the scheduled querying of your domain's DNS records from outside your network, comparing the answers against expected values and alerting when records go missing, change unexpectedly, return errors or differ between nameservers.

How often should DNS records be checked?

Check A, AAAA and CNAME records of critical hostnames every 1 to 5 minutes, NS, SOA, MX and TXT every 5 to 15 minutes, and domain registration expiry once a day with warnings starting 30 days before expiry.

Is an HTTP uptime check enough to catch DNS problems?

No. An HTTP check detects that users cannot reach the site but not that DNS is the cause, and cached DNS answers can hide a broken record from the probe for the length of the TTL. Partial failures like a wrong AAAA record or broken MX records may not affect the HTTP check at all.

How do I monitor domain expiration?

Query WHOIS or RDAP for the expiry date once a day and alert when it falls below 30 days. A simple approach is a cron script that pings a heartbeat URL only while the domain is safely valid, so both an approaching expiry and a broken script trigger an alert.