DNS Drift: What to Monitor

DNS drift is what happens when your DNS records change — intentionally or not — without anyone noticing. It's the slow accumulation of stale records, accidental changes, and forgotten configurations that eventually causes an incident.

Why DNS drift happens

DNS is often treated as "set and forget" infrastructure. Changes are infrequent enough that teams don't build monitoring around it, but frequent enough that records go stale. Common causes:

• Service decommissioning: Teams cancel SaaS tools but forget to clean up DNS records
• Employee turnover: The person who set up a DNS record leaves, and nobody knows what it's for
• Infrastructure migration: Moving between cloud providers or DNS hosts leaves stale records behind
• Shadow IT: Departments set up services and DNS records outside the normal change process
• Provider changes: Email or hosting providers change their recommended DNS settings
• Accidental edits: Fat-fingered DNS changes that go unnoticed for weeks

What to monitor

Not all DNS changes are equally important. Here's what matters most, ordered by impact:

Critical (alert immediately)

• NS record changes: If your nameservers change unexpectedly, someone may have hijacked your DNS delegation
• MX record changes: Unexpected MX changes can redirect inbound email to unauthorized servers
• DMARC policy regression: If your DMARC policy drops from p=reject to p=none, you've lost email spoofing protection
• SOA serial regression: If the SOA serial number goes backward, someone may have overwritten your zone with an older copy

High (alert within hours)

• SPF record changes: New includes or removed mechanisms change who can send mail as you
• New CNAME records: Could indicate a new service — or an unauthorized subdomain
• Wildcard DNS changes: Wildcard records can expose your entire domain to subdomain takeover
• A/AAAA record changes: Traffic may be going somewhere unexpected

Medium (daily digest)

• TTL changes: Sudden TTL drops may indicate someone preparing for a migration (or attack)
• DKIM selector rotation: Expected during key rotation, but should be tracked
• TXT record changes: Domain verification records for new services

Low (weekly report)

• CAA record changes: Changes to certificate authority authorization
• DNSSEC key updates: Expected during scheduled key rollovers

Building a change feed

The most useful DNS monitoring isn't dashboards or graphs — it's a change feed. A chronological list of what changed, when, and how it compares to the previous state. Each entry should include:

• What record changed (type, name, old value, new value)
• When the change was detected
• Severity classification (critical/high/medium/low)
• Suggested action (investigate, verify, ignore)

This gives ops teams a single place to review DNS changes without polling DNS consoles across multiple providers.