Which DNS records to monitor, and what should trigger an alert
A practical setup: the records that matter, what should page you, and how to avoid alerting on your own changes.
Monitoring DNS is less about whether it resolves and more about whether it resolves to the right answer, everywhere. Here is a setup that catches the partial failures, not just the total ones.
Records worth watching
- A and AAAA, the address records traffic actually follows
- MX, where your mail is delivered
- TXT, including SPF and DMARC
- NS, your delegation, where the whole zone is served from
- CAA, which authorities are allowed to issue certificates for you
What should trigger an alert
- Any change to A, AAAA, MX or NS that you did not make
- Disagreement between resolvers or regions on the same record
- NXDOMAIN from any vantage point, not just your own
- A TTL raised unexpectedly, which slows every future change
Where to check from
Resolve from several public resolvers and multiple regions, not one. A single-resolver check is the most common DNS blind spot, because it only ever sees one cache.
Cadence and noise
Resolution checks every sixty seconds from multiple regions, record-drift checks every few minutes. Page on a multi-region resolution failure; notify on a single region or a record change. When you plan a change, suppress the drift alert for a short window rather than disabling the monitor and forgetting to switch it back on.
Related field guides
Crowswatch watches the providers, domains and dependencies behind issues like these, and connects them into one operational view.
Start monitoring with Crowswatch