DNS changes are among the most invisible infrastructure failures. An A record points to the wrong IP, an MX record disappears, a CNAME resolves to a domain that no longer exists — and nothing raises an exception. Services degrade silently. Traffic routes to the wrong place. Email bounces. And because DNS TTLs cache the old result for hours or days, the breakage arrives slowly and at different times for different users.
This guide covers why DNS changes are so hard to detect, how to build a polling script that compares current DNS values against a known baseline, and when to use automated detection tools.
Most systems that break immediately produce an error. DNS changes break at a delay and break different users at different times depending on their resolver's cached values. This creates a confusing failure mode: some users see the problem, others don't, and the window between "change was made" and "impact is visible" can be hours.
Real-world scenarios where DNS changes cause unexpected outages:
An MX record change that drops an SPF-aligned mail server causes sent email to be flagged as spoofed or rejected outright. Incoming email may route to the wrong server and silently vanish. The change takes effect at TTL expiry, so some senders continue delivering successfully (cached old record) while others start bouncing. Support tickets arrive reporting "I never got your email" — but the problem started two days ago when someone updated the MX records during a provider migration.
You migrate to a new server IP and update the A record. You set the TTL to 3600 (one hour) on the new record — but the old record had a TTL of 86400 (one day). Users whose resolvers cached the old A record before your migration continue hitting the old server for up to 24 hours, seeing a down site, even after your monitoring confirms the new server is healthy. Lowering TTL before a planned migration is a best practice specifically to avoid this window — but it requires knowing a change is coming.
DNS access credentials shared across a team create a risk of unauthorized changes — whether accidental or malicious. A CNAME changed to point at a different service silently redirects all traffic to that service without any application-level error. Without change detection, the only signal is user reports that the site "looks different."
The most reliable way to detect DNS record changes is to capture a baseline and compare against it on a schedule. dig is the standard tool for querying DNS records from the command line:
# Query the A record for a domain
dig +short A example.com
# Query MX records
dig +short MX example.com
# Query from a specific authoritative nameserver (bypass local cache)
dig +short A example.com @8.8.8.8
# Query with TTL visible
dig A example.com | grep -v "^;"A complete change-detection script:
#!/bin/bash
# dns-change-check.sh — detect DNS record changes
DOMAIN="example.com"
RECORD_TYPE="A"
BASELINE_FILE="/var/lib/dns-monitor/${DOMAIN}-${RECORD_TYPE}.baseline"
ALERT_EMAIL="ops@example.com"
# Query current value (using Google DNS to bypass local cache)
CURRENT=$(dig +short "$RECORD_TYPE" "$DOMAIN" @8.8.8.8 | sort)
if [ -z "$CURRENT" ]; then
echo "DNS query failed for $DOMAIN $RECORD_TYPE at $(date)" \
| mail -s "DNS ALERT: query failed for $DOMAIN" "$ALERT_EMAIL"
exit 1
fi
# Create baseline on first run
if [ ! -f "$BASELINE_FILE" ]; then
mkdir -p "$(dirname "$BASELINE_FILE")"
echo "$CURRENT" > "$BASELINE_FILE"
echo "Baseline created for $DOMAIN $RECORD_TYPE: $CURRENT"
exit 0
fi
BASELINE=$(cat "$BASELINE_FILE")
if [ "$CURRENT" != "$BASELINE" ]; then
ALERT_MSG="DNS CHANGE DETECTED: $DOMAIN $RECORD_TYPE
Previous: $BASELINE
Current: $CURRENT
Time: $(date)"
echo "$ALERT_MSG" | mail -s "DNS CHANGE: $DOMAIN $RECORD_TYPE changed" "$ALERT_EMAIL"
echo "$ALERT_MSG"
# Update baseline to the new value after alerting
echo "$CURRENT" > "$BASELINE_FILE"
fiAdd to crontab to run every 15 minutes:
*/15 * * * * /usr/local/bin/dns-change-check.sh >> /var/log/dns-monitor.log 2>&1To monitor multiple record types for the same domain, run the script once per record type by passing arguments:
*/15 * * * * RECORD_TYPE=MX /usr/local/bin/dns-change-check.sh
*/15 * * * * RECORD_TYPE=TXT /usr/local/bin/dns-change-check.sh
*/15 * * * * RECORD_TYPE=A /usr/local/bin/dns-change-check.shdig example.com without @8.8.8.8) returns cached values and can miss a real change for as long as the TTL. For change detection, always query a public resolver like 8.8.8.8 (Google) or 1.1.1.1 (Cloudflare) to get the authoritative current value.
DNS changes propagate at TTL expiry, not instantly. A record with a TTL of 3600 (one hour) won't be visible to all resolvers for up to one hour after the change is published at the authoritative nameserver. This means:
To find and query the authoritative nameserver directly:
# Find the authoritative nameservers
dig +short NS example.com
# Query the authoritative nameserver directly (no cache)
dig +short A example.com @ns1.example-dns-provider.comQuerying the authoritative server catches changes the moment they're published, before any resolver caches propagate the new value.
Email is a reasonable alert channel for DNS changes that happen during business hours. For critical domains — primary sales site, payment pages, email infrastructure — you want faster notification. Integrating a webhook into the change detection script routes alerts to Slack: