A DNS A record maps a domain name to an IPv4 address. It's how browsers find your server, how email finds your MX host, and how your infrastructure routes traffic to the right place. When an A record changes unexpectedly — whether from a registrar compromise, a CDN misconfiguration, a provider failover, or a simple operator error — the impact is immediate and often silent: traffic redirects, services break, and users see either a blank page or, in the worst case, content served from somewhere you don't control.
DNS A record monitoring is the practice of continuously comparing your current A record values against a known-good baseline and alerting the moment a change is detected.
Changes to A records don't always come from deliberate internal action. Several common causes are worth understanding before choosing a monitoring strategy:
Domain registrar accounts are a frequent target for credential attacks. Once an attacker gains access to your registrar, they can change your nameservers or add/modify DNS records directly. The attacker doesn't need to touch your server — they redirect your domain at the DNS layer, intercepting traffic before it reaches you. High-profile examples of this attack pattern occur several times per year against major brands.
The insidious part: from your server's perspective, nothing changed. Your logs show normal traffic. Only the external DNS resolution changed — pointing visitors and API clients to a different IP entirely.
Many teams manage DNS through a CDN (Cloudflare, Fastly, Akamai) or a managed DNS provider. When these providers have outages, failovers, or configuration changes, the A records they publish can change as part of their routing logic. Cloudflare's anycast IPs, for instance, can shift as your account configuration changes. A "proxied" record in Cloudflare doesn't expose your origin IP — until someone accidentally switches it to "DNS only," at which point your origin IP is suddenly public and your A record points somewhere different from what you intended.
During a planned migration — moving infrastructure, changing cloud providers, deploying to a new region — you update your A record and lower the TTL to accelerate propagation. After the migration, the TTL should be raised again. If it isn't, your record propagates quickly across resolvers, which is fine until the old record is still cached somewhere and the new record is inconsistent. Monitoring A record values from multiple global vantage points catches propagation inconsistencies that single-source checks miss.
Infrastructure-as-code tools (Terraform, Pulumi, Ansible) manage DNS records alongside infrastructure. A mis-targeted apply, a state file conflict, or a module that manages DNS in a different stack can overwrite A records unexpectedly. The change might be intentional from the automation's perspective but entirely unexpected from the operator's perspective — especially in teams where multiple engineers have Terraform apply access.
The two standard tools for querying DNS A records from the command line are dig and nslookup.
# Query the A record for a domain
dig A yourdomain.com +short
# Query a specific nameserver (bypasses local cache)
dig A yourdomain.com @8.8.8.8 +short
# Show the full response including TTL
dig A yourdomain.com
# Check from multiple resolvers
for NS in 8.8.8.8 1.1.1.1 9.9.9.9; do
echo -n "$NS: "
dig A yourdomain.com @$NS +short
doneThe +short flag returns just the IP address(es), which is useful for scripting. Querying multiple resolvers — Google (8.8.8.8), Cloudflare (1.1.1.1), Quad9 (9.9.9.9) — shows whether your record has propagated consistently worldwide or whether different resolvers are still serving different values.
# Basic A record lookup
nslookup yourdomain.com
# Query a specific nameserver
nslookup yourdomain.com 8.8.8.8
# Query only A records
nslookup -type=A yourdomain.comnslookup is available on most platforms by default, including Windows. dig is more scriptable and provides richer output.
dig @8.8.8.8 to bypass the local cache and query an authoritative public resolver directly.
Store the expected IP for each domain in a file and compare it against the current value on a schedule:
#!/bin/bash
# /opt/scripts/dns-monitor.sh
ALERT_EMAIL="ops@yourcompany.com"
declare -A EXPECTED_IPS=(
["yourdomain.com"]="203.0.113.42"
["api.yourdomain.com"]="203.0.113.43"
["www.yourdomain.com"]="203.0.113.42"
)
for DOMAIN in "${!EXPECTED_IPS[@]}"; do
CURRENT=$(dig A "$DOMAIN" @8.8.8.8 +short | head -1)
EXPECTED="${EXPECTED_IPS[$DOMAIN]}"
if [ "$CURRENT" != "$EXPECTED" ]; then
echo "DNS CHANGE DETECTED: $DOMAIN
Expected: $EXPECTED
Current: $CURRENT
Time: $(date -u)" \
| mail -s "DNS A RECORD CHANGED: $DOMAIN" "$ALERT_EMAIL"
fi
done# Run every 15 minutes
*/15 * * * * /opt/scripts/dns-monitor.sh >> /var/log/dns-monitor.log 2>&1This approach works for a small number of domains but requires maintaining the expected IP list manually. When you intentionally change an A record, you must update the script or it will alert forever.
For teams already using version control for infrastructure, storing DNS snapshots in a git repository provides a natural change log:
#!/bin/bash
# Snapshot current A records for key domains
cd /opt/dns-snapshots
for DOMAIN in yourdomain.com api.yourdomain.com www.yourdomain.com; do
dig A "$DOMAIN" @8.8.8.8 +short > "current/$DOMAIN.txt"
done
if git diff --quiet; then
echo "No DNS changes detected"
else
git diff
git add -A
git commit -m "DNS change detected: $(date -u)"
# Send alert email with diff output
git show HEAD | mail -s "DNS RECORDS CHANGED" ops@yourcompany.com
fiThe git log becomes an audit trail: you can see exactly when each A record changed, what it changed from, and what it changed to.
For production infrastructure, an external monitoring service is more reliable than self-hosted scripts because it checks from multiple global vantage points, doesn't depend on your own server's health, and handles alerting without an MTA. DNSWatch monitors your A records continuously and sends alerts the moment a change is detected — including detecting propagation inconsistencies across global resolvers.
When an alert fires for an unexpected A record change, work through this sequence:
dig @8.8.8.8, dig @1.1.1.1, dig @9.9.9.9). If they all return a different IP from your baseline, the change is propagated and real.See what IP your domain resolves to right now — from multiple global resolvers. Free, no signup.
Check your DNS records →DNSWatch monitors your DNS records from multiple global vantage points and sends alerts the moment a change is detected — without scripts to maintain or servers to manage. Enter your domains; get alerts when your A records change.
DNSWatch monitors your A records continuously and alerts you instantly when they change — whether from a registrar compromise, CDN misconfiguration, or an accidental IaC apply.
Join the DNSWatch waitlist → Check your DNS records free