DNS changes are quiet. There's no exception thrown, no alarm triggered, no deploy log entry. A record changes, and the first sign is usually a user ticket: "The site is down," "Email stopped working," "The API is timing out." By the time you're digging through your DNS provider's change history, the incident has already been running for an hour.
Setting up a DNS change notification — an alert that fires within minutes of any record changing — is one of the cheapest reliability improvements you can make. This post covers why DNS changes are so hard to catch, what a good notification setup looks like, and how to get one running today.
DNS is aggressively cached at every level: your resolver, your ISP, your operating system, your browser. When a record changes, you may not see the new value for minutes or hours, depending on the TTL. This means a wrong change can be live in the wild long before anyone at your company even notices the old value is gone.
Most production domains touch DNS through at least two teams: whoever manages the registrar, and whoever manages the cloud provider or CDN. Vercel, Cloudflare, AWS Route53, and Netlify all create DNS records as part of their setup flows. A routine infrastructure change — rotating a load balancer, switching CDN plans, deprovisioning a staging environment — can silently delete a record that production depended on.
Unauthorized changes are obviously dangerous. But the truly expensive DNS incidents usually come from legitimate changes that had an unexpected side effect. Someone updated the CNAME for a subdomain and didn't realize a third-party integration was pointed at it. Someone rotated a TXT record for SPF verification and accidentally dropped a needed include. The change was intentional. The breakage wasn't.
api.example.com to point to a new server. They test the new server directly by IP — it works. But they don't know that a partner integration is hardcoded to the old A record value. The integration breaks silently. Four hours later, a partner sends an escalation email. Total downtime: 4 hours.
A useful DNS change alert is more than "something changed." The alert should tell you:
Without the before/after diff, the alert is low value — you still have to dig through your provider's change log to understand what happened. The whole point of a notification is to give you the information you need to decide: expected change, or incident?
The simplest approach is a service that queries your DNS records at a set interval and emails or Slacks you when it detects a change. You point it at your domain, tell it which record types matter, and it runs continuously in the background.
The key variables are:
If you want full control, a simple cron-based DNS watcher is surprisingly easy to build. The idea: query your critical records on a schedule, compare to a stored snapshot, and alert on any diff.
#!/bin/bash
# dns-watch.sh — run every 15 minutes via cron
DOMAIN="example.com"
SNAPSHOT_FILE="/var/run/dns-snapshot.txt"
ALERT_EMAIL="oncall@example.com"
# Query current A record
CURRENT=$(dig +short A "$DOMAIN" @8.8.8.8)
# Compare to snapshot
if [ -f "$SNAPSHOT_FILE" ]; then
PREVIOUS=$(cat "$SNAPSHOT_FILE")
if [ "$CURRENT" != "$PREVIOUS" ]; then
echo "DNS CHANGE: $DOMAIN A record changed from $PREVIOUS to $CURRENT" \
| mail -s "⚠️ DNS change: $DOMAIN" "$ALERT_EMAIL"
fi
fi
# Update snapshot
echo "$CURRENT" > "$SNAPSHOT_FILE"
The limitations: you need a reliable server to run this on, it only watches what you explicitly script, and you're responsible for keeping the snapshot in sync across restarts. It works well for one or two critical records. It becomes a maintenance burden when you're watching ten domains across multiple record types.
Many DNS providers offer an audit log or change history. Cloudflare, Route53, and Google Cloud DNS all record who changed what and when. This is useful for forensics but not for alerting — you only see what changed after the fact, and you're not notified in real time.
Some providers offer webhooks or event notifications on DNS changes. Cloudflare's Notifications system can alert on certain DNS events. Route53 supports CloudWatch Events. If you're already invested in one provider's ecosystem and your critical domains live there, this is worth checking first — you may have native alerting you haven't configured.
The gap: most teams split DNS across providers (registrar + CDN + cloud). A provider-native alert only covers its own records. If a record changes at the registrar level and you're monitoring at the CDN level, the alert doesn't fire.
Not all DNS changes are equally risky. Here's a practical priority order:
Before setting up DNS change notifications, you need a snapshot of what your records currently look like. If you don't know what "normal" is, you can't recognize an anomaly.
The free DNS checker returns all record types for any domain in one lookup — no login, no install. Enter your domain and export the results. That's your baseline.
DNSWatch monitors your DNS records and sends you an email the moment any record changes — with a before/after diff so you know instantly whether it's expected or an incident.