DNS Record Monitoring
Watch a DNS record for changes: confirm a domain still resolves, or alert when MX, TXT, NS or CAA records stop matching the values you expect.
A DNS monitor queries one record for a domain and tells you when the answer stops being what it should be.
When This Adds Something
Be honest about the overlap first: if a domain stops resolving entirely, every
HTTP monitor pointed at it already fails, with DNS FAILURE as the reason.
A DNS monitor on the same domain would page you a second time for the same
event.
Where a DNS monitor sees something nothing else can:
- MX records — mail routing changes or disappears. No page goes down, no HTTP check fails, and nobody finds out until a customer says they never received the password reset.
- TXT records — your SPF or DMARC record is edited or dropped. Mail starts landing in spam, or spoofed mail as your domain starts being delivered.
- NS records — a nameserver migration half-applies, so resolvers reach either set and get different answers.
- CAA records — an unexpected certificate authority is authorised to issue for your domain.
- A domain with no website — a mail-only domain, or an apex you do not serve, has no HTTP monitor to fail on your behalf.
Configuration
Target
A bare hostname, like a ping or TCP monitor — example.com, not
https://example.com.
Record Type
A, AAAA, CNAME, MX, TXT, NS or CAA.
What to Check
Just confirm the record resolves (default) — alerts if the record disappears or the domain stops resolving. Nothing to configure, and nothing to keep in step when you legitimately change the record.
Must include these values — alerts if any expected value is missing. Extra values pass, so scaling out from two addresses to three does not page you.
Must be exactly these values — alerts if anything is missing or added. This is the only mode that catches a record added alongside your real one, which is what a hijack looks like — and the only one that will alert on an ordinary CDN.
Order does not matter and matching ignores case. For MX, include the priority
(10 aspmx.l.google.com), because changing it changes mail routing.
The CDN Trap
Do not assert values on an A, AAAA or CNAME record that sits behind a CDN or uses geo-based routing. Those return a different, entirely correct answer depending on where the query came from. Pingara checks from up to four regions, so an expected-value check against one will fail in the regions that got a different answer — and because a status change needs several regions to agree, that reads as a confirmed failure rather than a glitch.
For those records, use Just confirm the record resolves, or list every address you serve.
MX, NS and CAA records do not vary by geography, so value assertions on them are safe.
What the Alert Tells You
| Reason | What happened | Where to look |
|---|---|---|
DOMAIN NOT FOUND | NXDOMAIN — the domain does not exist | Registrar: registration and delegation |
NO RECORDS | The domain resolves, but has no record of that type | DNS provider: the record itself |
NAMESERVER ERROR | SERVFAIL — nameservers reached but could not answer | DNS provider status; DNSSEC |
DNS TIMEOUT | Nameservers did not answer in time | DNS provider status |
DNS VALUE CHANGED | Resolved fine, but did not match your expected values | The record at your DNS provider |
DNS TIMEOUT and DOMAIN NOT FOUND are deliberately different reasons. A
timeout is a network event; it does not mean your record is gone.
Caching
Pingara queries through a resolver, so answers can be served from cache for as long as the record's TTL. Two consequences worth knowing:
- A change you make may take up to the TTL to be visible here.
- After you fix a broken record, recovery can also lag by the TTL — negative answers are cached too.
Related Articles
- HTTP/HTTPS Monitoring — what an HTTP check already covers
- Monitor Intervals and Regions