How to Monitor DNS Changes and Detect Hijacking

DNS hijacking remains one of the most effective and underdetected attacks on internet infrastructure. When an attacker modifies your DNS records, they redirect your traffic -- web, email, API -- to systems they control. Detecting these changes quickly is the difference between a contained incident and a full-scale breach.

This guide covers how to monitor DNS changes, which records to prioritize, and how automated detection works in practice.

If you need a primer on DNS record types and why monitoring matters, start with our introduction to DNS monitoring.

TL;DR

Real-world DNS hijacking attacks have caused millions in losses -- detection speed directly determines the blast radius.
Classify record changes by severity: NS/MX/A are critical, SPF/DMARC weakening is high, CAA/SRV are medium.
Use CDN-aware monitoring to suppress false positives from Cloudflare/Akamai IP rotation while catching genuine attacks.
Monitor DNSSEC signature expiry and domain registration status (EPP codes) alongside DNS records themselves.
When unauthorized changes are detected: verify, secure credentials, revert records, check CT logs, and notify affected parties.

Real-World DNS Hijacking Attacks

DNS hijacking is not a theoretical threat. High-profile incidents demonstrate the real-world impact.

MyEtherWallet (2018)

Attackers used BGP hijacking to reroute traffic to Amazon's Route 53 DNS servers, then answered DNS queries for MyEtherWallet.com with the IP address of a server they controlled. Visitors saw a valid-looking website and entered their cryptocurrency wallet credentials.

The attack lasted approximately two hours and resulted in the theft of roughly $17 million in Ethereum.

Brazilian banks (2017)

Attackers compromised the DNS registrar account of a major Brazilian bank and changed the DNS records for all 36 domains. For approximately five hours, all traffic -- web, mobile banking, email, ATM-to-headquarters communications -- was redirected to attacker-controlled servers.

The attackers hosted their infrastructure behind valid SSL certificates obtained using DNS-based domain validation.

Sea Turtle campaign (2019)

A nation-state threat actor systematically compromised DNS infrastructure across the Middle East and North Africa. Rather than targeting individual domains, the attackers compromised DNS registrars and registry operators, giving them the ability to modify DNS records for any domain managed by those providers.

In each case, DNS monitoring would have detected the record changes within minutes. The key insight is that detection speed directly determines the blast radius.

Manual DNS Checking with dig and nslookup

Before automating, it helps to understand the manual tools. dig is the standard DNS query tool on Linux and macOS.

Query all record types for a domain

# A records (IPv4)
dig example.com A +short

# MX records (mail)
dig example.com MX +short

# NS records (nameservers)
dig example.com NS +short

# TXT records (SPF, DKIM, DMARC)
dig example.com TXT +short

# CAA records (certificate authority authorization)
dig example.com CAA +short

# Query DMARC policy specifically
dig _dmarc.example.com TXT +short

Query a specific nameserver

# Query Google's resolver
dig @8.8.8.8 example.com A +short

# Query Cloudflare's resolver
dig @1.1.1.1 example.com A +short

# Query the authoritative nameserver directly
dig @ns1.example.com example.com A +short

Querying multiple resolvers helps detect propagation issues and ensures that all nameservers return consistent answers. Inconsistency between authoritative nameservers is a red flag -- it can indicate a partial compromise or a misconfigured zone transfer.

Check DNSSEC validation

# Check if DNSSEC is enabled (look for RRSIG records)
dig example.com A +dnssec +short

# Verify the DNSSEC chain
dig example.com A +dnssec +multi

Which DNS Records to Monitor and Why

Not all DNS changes carry the same risk. A useful monitoring system classifies changes by severity so that critical alerts get immediate attention while informational changes are logged for review.

NS records: the highest-priority check

Nameserver changes should always trigger an immediate critical alert. In normal operations, NS records change rarely -- typically only when migrating DNS providers. An unexpected NS change means someone has redirected your domain's entire DNS resolution to a different set of servers.

A/AAAA records: context-dependent severity

For servers with static IP addresses (your own infrastructure, colocated servers), an A record change is critical. For domains fronted by CDN providers like Cloudflare or Akamai, IP address rotation is normal and expected.

A good monitoring tool detects your DNS provider and suppresses false positives from CDN IP rotation while still alerting on genuinely unexpected changes.

MX records: email routing integrity

MX record changes redirect email delivery. If you use Google Workspace, your MX records should point to aspmx.l.google.com and related servers. If they suddenly point somewhere else, your incoming email is being intercepted.

Monitor MX records with priority values -- even a change in priority ordering (which server gets tried first) can be significant.

SPF, DKIM, and DMARC: email authentication

These TXT records form the backbone of email authentication. Monitor for:

SPF weakening -- a change from -all (hard fail) to ~all (soft fail) or ?all (neutral) allows unauthorized senders to forge email from your domain
DMARC removal or weakening -- removing _dmarc records or changing policy from reject to none disables email authentication enforcement
DKIM key changes -- unauthorized DKIM key rotation can indicate an attacker setting up their own email signing capability for your domain
SPF lookup count -- SPF allows a maximum of 10 DNS lookups (including recursive includes). Adding services can push you over this limit, effectively breaking SPF validation entirely

Understanding Dynamic IP Providers

CDN and DDoS protection providers like Cloudflare, Akamai, and Fastly intentionally rotate the IP addresses in A/AAAA records as part of their normal operation. If your monitoring system alerts on every Cloudflare IP change, you will be overwhelmed with false positives and start ignoring alerts entirely.

The solution is provider-aware monitoring. By checking your NS records, a monitoring tool can detect that your DNS is managed by a provider that rotates IPs. Metric Tower's DNS change detection does this automatically: it identifies Cloudflare, Akamai, Fastly, and other dynamic IP providers from NS records and suppresses A/AAAA change alerts for those domains.

DNS-only hosting providers like AWS Route 53, Azure DNS, and Google Cloud DNS are intentionally excluded from suppression because their A/AAAA records are static and changes are always significant.

Common Mistake

Alerting on every A/AAAA record change without CDN awareness. This floods your team with false positives from normal Cloudflare/Akamai IP rotation and trains everyone to ignore DNS alerts -- exactly what an attacker exploits.

Setting Up Automated DNS Change Monitoring

Here is how to move from manual dig checks to continuous automated monitoring.

1. Establish your baseline

The first step in change detection is knowing your current state. Query all record types for each domain and store the results. This becomes your reference point for future comparisons.

# Quick baseline script
for type in A AAAA MX NS TXT CNAME CAA SRV SOA; do
  echo "=== $type ==="
  dig example.com $type +short
done

2. Configure per-record-type monitoring

Not every record type needs the same level of attention. A practical default: monitor all record types except SOA (too noisy -- serial numbers increment on every zone edit) and PTR (reverse DNS is managed by IP owners, not domain owners). Enable SOA monitoring only if you have specific compliance requirements.

3. Set up severity-aware alerting

Route alerts based on severity. Critical alerts (NS, A/AAAA on static IPs, MX) should go to PagerDuty or your on-call rotation for immediate response. High-severity alerts (SPF/DMARC changes) should go to a security team channel.

Medium and informational changes can go to a log or lower-priority channel for periodic review.

4. Monitor domain registration status

Beyond DNS records, track your domain registration via RDAP (Registration Data Access Protocol). RDAP provides structured JSON data about domain registration: expiry dates, registrar information, and EPP status codes. Critical EPP statuses to watch for:

pendingDelete -- domain is being deleted (usually after expiry grace period)
serverHold -- domain is suspended by the registry (often for abuse or legal reasons)
pendingTransfer -- an unauthorized transfer may be in progress
redemptionPeriod -- domain has expired and is in its last grace period before release

DNSSEC: Protecting DNS at the Protocol Level

DNSSEC adds cryptographic signatures to DNS records. When enabled, resolvers can verify that the records they receive are authentic and have not been tampered with in transit. DNSSEC protects against DNS cache poisoning and man-in-the-middle attacks on DNS queries.

However, DNSSEC introduces its own monitoring needs:

Signature expiry. DNSSEC signatures (RRSIG records) have expiry dates. If signatures expire without being re-signed, DNSSEC-validating resolvers will refuse to resolve your domain.
Key rotation. DNSSEC keys (DNSKEY records) need periodic rotation. The rollover process requires coordination between the domain's authoritative servers and the parent zone.
Chain of trust. DNSSEC validation works from the root zone down through TLD zones to your domain. A break anywhere in this chain invalidates the signatures for your domain.

Responding to Detected DNS Changes

When your monitoring detects an unexpected DNS change, speed matters. Here is a response framework:

Best Practice

Have a documented DNS incident response runbook before you need it. Include registrar login procedures, baseline record snapshots, and escalation contacts. When a DNS hijack is detected, every minute of response delay extends the attacker's window.

Verify the change is unauthorized. Check with your team -- someone may have made a legitimate change without documenting it. This is the most common explanation and highlights the importance of a change management process for DNS.
If unauthorized, log into your DNS provider immediately. Check the audit log for who made the change and when. Change your DNS provider credentials. Enable 2FA if it is not already active.
Revert the records. Restore your DNS records from your documented baseline. Lower the TTL temporarily so the corrected records propagate faster.
Check for related compromise. If DNS was compromised, check whether the attacker also obtained SSL certificates for your domain during the hijacking window. Check Certificate Transparency logs for unexpected issuances.
Notify affected parties. If customer data may have been intercepted during the hijacking window, you may have notification obligations under GDPR, CCPA, or other data protection regulations.

Key Takeaways

1 DNS hijacking is a proven attack vector -- real-world incidents have caused millions in losses and affected dozens of organizations simultaneously.
2 Classify DNS changes by severity (critical/high/medium/info) and route alerts to the right channel -- not all changes deserve a 2 AM page.
3 Use CDN-aware monitoring to eliminate false positives, and monitor DNSSEC, domain registration, and SPF/DMARC records alongside A/NS/MX changes.
4 Prepare a DNS incident response runbook now -- when an unauthorized change is detected, your response time directly determines the blast radius.

Automated DNS monitoring through a platform like Metric Tower ensures you detect changes within minutes, not days. Combined with SSL monitoring and uptime checks, you get a comprehensive view of your domain's security posture from a single dashboard.

For a comparison of tools that can handle DNS change detection, see our review of DNS monitoring tools.