DNS records change for three reasons: somebody on your team made a deliberate change, somebody on your team made an undeliberate change, or somebody outside your team made a change you didn't authorise. The first is fine. The second is preventable. The third is a security incident.
A DNS-drift monitor catches all three by capturing the current record set as a baseline and alerting when subsequent checks diverge. This guide walks through setting one up, and crucially, picking the right record types so you get useful alerts instead of noise.
What a DNS-drift monitor actually does
Every 15 minutes (by default), our worker runs a DNS lookup against your target hostname for the record types you selected, normalises the result, and compares it to the baseline captured on the monitor's first check. If anything differs, a removed record, an added record, a changed value, you get an alert with a diff.
Recovery alerts fire when the record set returns to the baseline (or to a previously-confirmed state).
Step 1. Pick the right hostname
DNS-drift monitoring is useful for hostnames whose records shouldn't change without your knowledge. That's typically:
- Your apex domain and
www - Mail hostnames (
mail.example.com) - API hostnames (
api.example.com) - Specific subdomains tied to customer-facing services
Don't monitor hostnames you don't control. You'll get false alerts every time the third party makes a deliberate change.
Step 2. Pick the right record types
This is the most important choice. Different record types have wildly different stability characteristics, and monitoring a noisy type will train you to ignore the alerts.
| Record type | Stability | Recommended? |
|---|---|---|
| A / AAAA for static hosts | Stable | Yes |
| A / AAAA behind a CDN (Cloudflare, Fastly) | Changes constantly | No, these IPs rotate normally |
| MX | Almost never changes legitimately | Yes, very high signal |
| TXT (SPF, DMARC, DKIM, verification records) | Should never change without ceremony | Yes, high signal |
| CNAME | Stable | Yes |
| NS | Almost never changes legitimately | Yes, change here is usually significant |
| SOA | Serial number changes on every zone update | No, too noisy |
Open /dashboard/monitors/new/dns-record and tick the record types that match. For most production domains, MX + TXT + NS is the trifecta: deliberate changes are rare, and an unexpected change is almost always something you want to know about.
If your A records are behind a CDN, skip them. Monitor the CNAME pointing to the CDN instead.
Step 3. Pick a resolver
The resolver is the upstream DNS server we query through. Choices:
- Google (8.8.8.8) - default. Worldwide, fast, generally consistent.
- Cloudflare (1.1.1.1) - fast, privacy-friendly.
- Quad9 (9.9.9.9) - security-filtering resolver. Good if you want to know whether a record is reachable for security-conscious networks.
- OpenDNS (208.67.222.222) - Cisco-owned, used widely in enterprise.
For most cases, Google or Cloudflare is fine. If you've had issues where a specific resolver served stale answers, pick that one for the monitor.
Step 4. Pick the check interval
Default is 15 minutes. That's a good balance, frequent enough to catch a change before it bites you, infrequent enough not to generate ten checks per typo.
If you're on Professional or Enterprise, you can drop to 1-minute cadence, useful for the brief window during a planned rollout when you want to verify propagation in near-real-time. For ongoing monitoring, 15 minutes is right.
Step 5. Pick the alert channels
Email is on by default and goes to your account address. Webhook (Starter and up) is the better integration if you have a Slack or PagerDuty workflow. DNS changes are exactly the kind of thing you want surfaced in a team channel for visibility.
The webhook payload includes a diff summary in the check.result field so the channel message can show "removed: TXT:v=spf1 include:old.example.net; added: TXT:v=spf1 include:new.example.net" without anyone clicking through.
Step 6. Save and capture the baseline
Click Create monitor. The first check runs immediately and captures the current record set as the baseline. The state pill goes to ok and the summary reads "Baseline captured (N records across MX, TXT, NS)".
Audit the baseline. Click into the monitor's detail page and check the result.records from the first check. Is that what you expect the records to be? If not, you've just learned something useful before any drift event: your DNS isn't currently what you thought it was. Fix it, then update the baseline.
Step 7. Handling a real drift alert
When an alert fires, the email and webhook payload include a human-readable diff:
DNS drift detected on api.example.com
removed: TXT:v=spf1 include:_spf.old-mail.com ~all
added: TXT:v=spf1 include:_spf.new-mail.com ~all
Your decision tree:
- Is this change one of yours? Ask your team. Check your DNS provider's change log. If yes, go to step 4.
- Is the change benign? A new TXT record added by a vendor verification (Google Postmaster, DMARC monitor) is usually fine. A new MX record pointing somewhere you don't recognise is not.
- Is the change malicious? Unexpected A / NS / MX changes can be domain hijack indicators. Lock the domain with your registrar, rotate registrar credentials, and audit the change history.
- Update the baseline. Once you've confirmed the new state is correct, delete and recreate the monitor (we don't yet have an in-UI "accept new baseline" button. It's on the v1.1.x roadmap). The new baseline captures on first check.
Common DNS-monitoring mistakes
Monitoring A records behind a CDN. Cloudflare and Fastly rotate IPs on you regularly. Monitor the CNAME, not the rotating A.
Forgetting that propagation is slow. Right after a deliberate change, the resolver you're querying might still have the old cached value. Wait 5-10 minutes after a planned change before re-confirming the monitor, or update the baseline immediately and use DNSChecker for the global-propagation question.
Monitoring SOA records. SOA's serial number increments on every zone update. You'll get alerts for every internal change, which is exhausting. Skip SOA.
Single-record TTL flap. Some record sets legitimately include time-bound records (short-TTL geo-DNS, for example). If a hostname uses geo-DNS, you'll get drift alerts when the resolver pool rotates. Either don't monitor that hostname, or skip the geo-routed record types.
Not testing the channel. As with SSL monitoring, fire a test alert deliberately. Easiest way: create the monitor pointing at a hostname under your control, capture baseline, change the record at your DNS provider, wait one check interval, confirm the alert lands.
What this catches that on-demand DNS lookups don't
The DNS Lookup tool tells you what's there now. The drift monitor tells you when what's there changes. They're complementary:
- DNS lookup - when you're actively investigating something
- DNS drift monitor - when you want to be told about changes you didn't initiate
Most outages and security incidents start with "a record changed and nobody noticed." This monitor is the cheapest way to make sure "nobody noticed" doesn't apply to you.
TL;DR
- Open /dashboard/monitors/new/dns-record.
- Enter the hostname (one you control).
- Pick MX + TXT + NS for high-signal monitoring. Skip A behind CDNs. Skip SOA.
- Pick a resolver. Google default is fine.
- 15-minute cadence is right; 1-minute on Pro+ for active rollouts.
- Save → first check captures baseline. Audit it.
- On a drift alert: confirm it's intentional, update baseline if needed; if unexpected, investigate.
Related
- How to perform a DNS lookup - the on-demand version
- DNS Lookup tool - what the monitor wraps
- How to set up SSL certificate monitoring - same pattern, TLS layer