How often should I check for DNS drift?

Frequently enough that a malicious change is caught before it does damage, hourly is a good balance for most organizations, and continuous or near-continuous for high-value domains. Daily checks leave too long a window for a hijack to redirect traffic or mail unnoticed.

Can DNS drift really lead to phishing or fraud?

Yes. A changed A record can point your domain at an attacker's clone, an altered MX record can intercept email, and a dangling CNAME can be claimed by an attacker for a subdomain takeover, all letting someone operate under your trusted domain name.

Doesn't DNSSEC prevent unauthorized DNS changes?

No. DNSSEC cryptographically prevents tampering with responses in transit and cache poisoning, but it does nothing to stop someone who has compromised your registrar or DNS-host account from making authorized-looking changes at the source. You still need drift monitoring.

How to Monitor DNS Records for Unauthorized Changes (DNS Drift)

VigilDog Team · October 13, 2026 · 6 min read

DNS is the most powerful lever an attacker can pull against you, and one of the least watched. A single altered record can redirect your website, intercept your email, or hand an attacker a subdomain to phish from, and because nothing crashes, you often find out from a customer instead of an alert. DNS drift monitoring is the practice of continuously comparing your live records against a known-good baseline so that any unexpected change surfaces immediately. Here's how to do it.

What DNS drift is and why it's dangerous

DNS drift is any change to your DNS records that happens outside your intended change process. Sometimes it's benign, an engineer editing a record in a hurry and forgetting to tell anyone. Often it's not: a compromised registrar or DNS-host account, a hijacked delegation, or a dangling record left behind when a third-party service was decommissioned.

The consequences scale with the record type. A changed A record silently points your domain at an attacker's server. A changed MX record reroutes your inbound mail so it can be read or dropped. A changed NS record hands over your entire domain. And a dangling CNAME pointing at a deprovisioned cloud resource lets someone claim that subdomain, a classic subdomain takeover used for phishing under your own name. Understanding what each record type does is the first step to knowing what a dangerous change looks like.

How a domain name resolves to a server

What to baseline and watch

Effective drift monitoring means snapshotting the records that actually carry risk and re-checking them on a schedule. At minimum, watch:

NS records and the registrar's nameserver delegation, a change here is a full takeover signal.
A and AAAA records for your apex and important subdomains, where your traffic goes.
MX records, where your mail goes.
CNAME records, especially ones pointing at third-party services, to catch dangling entries that enable subdomain takeover.
TXT records carrying SPF, DKIM and DMARC, quiet changes here degrade deliverability and open you to spoofing.
CAA records and, if you use it, the DNSSEC DS record, controls over who can issue certs and whether responses are signed.

DIY drift detection with dig and diff

The core idea is simple: dump your records to a file, do it again later, and diff the two. Query each type explicitly rather than relying on ANY (which many resolvers no longer answer fully). A minimal baseline script loops over the record types and writes sorted output: for t in NS A AAAA MX TXT CAA; do dig +noall +answer example.com $t; done | sort > current.txt, then diff baseline.txt current.txt on a cron schedule and alert on any non-empty diff.

Query the authoritative nameservers directly with dig @ns1.example.com to see the source of truth, and also query a public resolver like dig @1.1.1.1 to see what the world actually resolves, the two can differ during propagation or an attack. Verify what you're seeing lines up with a neutral third party using the DNS checker so you're not trusting a single cached view.

Where the DIY approach runs out of road

A cron-and-diff script gets you surprisingly far, but it has real limits. Caching and TTLs mean a change can hide until records expire, so a single resolver gives you a stale and incomplete picture, you really want multiple geographic vantage points. Raw diffs also generate noise: dynamic records and load-balanced A records rotate legitimately, and un-tuned alerts train you to ignore them. Then there's the meta-problem, the script runs on infrastructure that can itself be compromised, and it won't easily catch registrar-level changes like a lock being removed or the domain being pushed toward transfer.

Storing history so you can answer 'what did this record look like last Tuesday?', validating DNSSEC, and correlating a DNS change with a certificate or expiry event are all things a one-file script won't do well. At that point you're rebuilding a monitoring product, and the honest move is to use one.

Continuous drift monitoring with VigilDog

This is exactly what VigilDog's domain and DNS monitoring is built for: it snapshots your records across all the risky types, checks them continuously from multiple vantage points, and alerts you the moment something changes, with the before-and-after so you can tell a routine edit from a hijack at a glance. It watches the registrar and expiry layer too, not just the zone, and pairs drift detection with SSL and deliverability checks so a single dashboard covers the whole surface.

For teams managing many domains, that consolidation is the difference between catching drift in minutes and finding it in a post-mortem, see how it's structured for agencies managing client domains.