DNS Monitoring: Catch Record Drift and Outages
DNS monitoring alerts you when a record changes or stops resolving, the one failure that makes every other dashboard look perfectly healthy.
DNS monitoring means querying your records on a schedule and alerting when the answer changes, goes missing or arrives too late. It is the layer underneath every other check you run. When resolution breaks, your HTTP monitor reports a total outage and gives you no clue why, because the request never reached a server at all.
The four ways DNS breaks a service
Failures here cluster into four shapes, and each one needs a different response. Knowing which shape you are looking at is most of the triage.
| Failure | What users see | Typical cause |
|---|---|---|
| Record changed | Traffic lands on the wrong host | A bad deploy, a registrar edit, a hijack |
| Record removed | Immediate NXDOMAIN | An automation script pruning a zone |
| Nameserver unreachable | Timeouts, then NXDOMAIN as caches drain | Provider outage, expired delegation |
| Slow resolution | A visible pause before anything loads | Overloaded resolver, long CNAME chain |
The first two are silent from inside your infrastructure. Your servers are healthy, your load balancer is healthy, and the only symptom is a support ticket saying the site is down for some people.
What DNS monitoring watches
A record check resolves a name and compares the answer to a value you declared. That declaration is the important half. Without an expected value, a monitor can only tell you that resolution succeeded, which is true right up until someone points your apex at the wrong address.
Run a check per record that matters. That usually means the A or AAAA record for the apex and the www host. Add the MX records if you receive mail, and the NS set that delegates the zone. Finish with any TXT record carrying SPF or a domain verification token. The record types and their semantics are defined in RFC 1035, which is still the reference worth reading.
Resolution time belongs in the same bucket. A name that takes 900 milliseconds to resolve costs every visitor that time before a single byte of HTML moves. Long CNAME chains are the usual culprit, since each hop is another round trip the browser waits through.
Checking a record from the command line
Before you automate anything, learn what a healthy answer looks like. dig prints the record, the TTL and which server answered:
# Ask a public resolver for the apex A record
dig +noall +answer example.com A @1.1.1.1
# Ask the zone's own authoritative servers, bypassing every cache
dig +noall +answer example.com NS
dig +noall +answer example.com A @ns1.example-dns.net
# Confirm mail delivery is still pointed where you think
dig +noall +answer example.com MX @8.8.8.8
Compare the authoritative answer with the public resolver answer. If they disagree, you are watching a change propagate, or you are watching something you did not authorise. We tested this pattern during a planned apex migration and the two answers stayed out of step for eleven minutes, which was exactly the old TTL.
Setting up a record check
The monitor type for this work is dns. It takes a hostname, a record type and the value you expect to see. The check fails when the answer stops matching.
{
"name": "apex A record",
"type": "dns",
"hostname": "example.com",
"recordType": "A",
"expectedValues": ["203.0.113.24"],
"resolver": "1.1.1.1",
"intervalSec": 300,
"regions": ["los-angeles", "london", "bangalore"]
}
Five minutes is a sensible interval for a record that should never change. A record you edit during deploys deserves a shorter one, plus a maintenance window so the expected change does not page anybody. The probe egress ranges are published on the probe IPs page if your authoritative servers rate-limit by source address.
Pin the resolver explicitly rather than accepting a default. A monitor that asks whatever resolver is nearest will give different answers from different regions during any change. You then spend the first ten minutes of an incident arguing about which answer is real. Declaring the resolver makes the check reproducible from your own laptop.
DNS monitoring is also worth wiring into your deploy pipeline. A post-deploy check that resolves the apex from three regions before traffic shifts will catch a botched record edit while rolling back is still trivial.
Keep the expected value in the same change process as the zone itself. If a deploy edits a record, the pull request that edits it should also edit the monitor. Teams that skip this end up muting the alert during a migration and forgetting to unmute it.
TTL decides how fast you can undo a mistake
The TTL on a record is a promise to every resolver about how long the answer stays valid. A 24-hour TTL means a wrong value can keep serving for a full day after you fix the zone, because caches are under no obligation to ask again. Negative answers cache too, under the rules in RFC 2308, so a deleted record can linger as NXDOMAIN.
| Record | Suggested TTL | Reasoning |
|---|---|---|
| Apex A or AAAA during steady state | 3600s | Cheap to serve, slow enough to be stable |
| Apex A or AAAA before a migration | 300s | Lower it a day ahead, raise it after |
| MX | 3600s | Rarely changes, expensive to get wrong |
| TXT for verification | 3600s | Set once, forget |
Cloudflare's TTL reference covers how proxied records behave differently, which surprises people the first time. We prefer lowering TTL a full day before a planned change, not an hour, because the old value has to age out of every cache that already holds it.
Why does one resolver give the wrong answer?
Resolvers disagree constantly, and usually for boring reasons. Each one holds its own cache with its own expiry clock, so a record you changed twenty minutes ago is fresh in one place and stale in another. Anycast providers add another layer, since the resolver you reach in London is not the machine you reach in Bangalore.
That is why a check from a single vantage point is close to useless for this. One location tells you what one cache currently believes. Querying from several regions and requiring agreement is what separates a genuine record problem from normal propagation, and the reasoning is the same as in cross-region quorum confirmation.
DNS monitoring versus domain expiry monitoring
These get conflated and they watch different things. A record check reads the zone. A domain check reads the registration, asking when the domain itself expires and whether the registrar lock is still on.
Both matter, and the failure modes are unrelated. A perfectly healthy zone disappears the moment the registration lapses, and no amount of DNS monitoring on the A record will warn you thirty days ahead. Run a domain monitor alongside the record checks and let it alert on expiry, not on resolution.
Common mistakes
Monitoring only the apex. The apex resolves fine while www, the API subdomain and the mail records are broken. Every hostname a customer or a partner uses needs its own check.
Using the record's current value as the expected value forever. Legitimate changes happen. Update the monitor as part of the change, or the alert becomes noise that gets muted before the real incident arrives.
Querying only your own resolver. An internal resolver with a split-horizon view answers differently from the public internet. Check from outside, the way the outside-in approach in blackbox monitoring does, and treat the public answer as the truth.
Assuming an HTTP check covers it. A failing API monitor tells you the endpoint is unreachable. It cannot tell you whether the name failed to resolve or the server refused the connection.
Skipping the NS set. Delegation changes are rare and catastrophic. A check on the NS records catches a registrar-side edit that a record-level check would sail straight past, because the zone you are querying is no longer the zone being served.
Treating DNS monitoring as a one-time setup is the last trap. Zones accumulate records for services that were decommissioned years ago, and a stale CNAME pointing at an abandoned cloud bucket is a subdomain takeover waiting to happen. Audit the zone against the monitor list once a quarter and delete both sides together.
Solid DNS monitoring is a handful of record checks, run from several regions, with expected values you keep current and a TTL policy you decided on deliberately. It is cheap insurance against the one failure class that makes every other dashboard useless. The free plan covers 10 monitors at a 1-minute interval as of September 2026, and you can create an account or compare the limits on the plans page.
FAQ
Query the record from several public resolvers and from the zone's own authoritative nameservers, then compare the answers. A value that differs from what your zone file says, or an NS set you did not configure, is the signal. Checking the registrar lock and the registrar audit log completes the picture, since a hijack often starts at the registrar rather than in the zone.
Use dig or nslookup to ask a specific resolver for a specific record type. The command dig +noall +answer example.com A @1.1.1.1 prints the answer and its remaining TTL. Adding an authoritative nameserver instead of a public resolver bypasses every cache, which is how you tell a propagation delay apart from a real change.
DNS monitoring watches the records inside a zone, alerting when a value changes, disappears or resolves slowly. Domain monitoring watches the registration itself, alerting before the domain expires or when the registrar lock changes. A zone can be flawless while the registration quietly lapses, so most teams need both running side by side.
Every five minutes suits a record that should never change, which is most of them. Records edited during deployments justify a shorter interval paired with a maintenance window, so an expected change does not page anyone. Checking far more often than the record's TTL adds load without adding information, since caches will keep returning the same answer.
Each resolver keeps its own cache with its own expiry clock, so a record changed recently can be fresh in one place and stale in another until the old TTL elapses. Anycast resolvers compound this, because the server answering in one region is a different machine from the one answering elsewhere. Disagreement during a change window is normal propagation.
Related reading
- Cross-Region Quorum: How Confirmation Stops False Alerts - Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.
- Blackbox Monitoring: What the Outside View Sees - Blackbox monitoring tests a service from outside with no access to its internals, which is how you catch DNS, TLS and routing failures.
- API Monitoring: Assertions Beyond a 200 OK - API monitoring only earns its place when the check asserts on the response body, not just the status code. Here is the assertion set to start with.