DNS record drift: what causes it, why uptime checks miss it, and how to detect it

An expired TLS certificate announces itself — the browser throws NET::ERR_CERT_DATE_INVALID and someone files a ticket within minutes. A changed DNS record is the opposite: it can quietly redirect traffic, break email delivery, or point a subdomain at a server you decommissioned last year, and nothing in your normal monitoring says a word.

I want to walk through what actually causes DNS records to change out from under you, why an HTTP uptime check is structurally blind to it, and how baseline-diff detection catches the class.

What "drift" means here

Drift is any deviation from a known baseline. When you start monitoring a hostname, you snapshot its current records — A, AAAA, CNAME, MX, TXT, NS, whatever is configured. That snapshot is the baseline. Drift is any later lookup that returns a different answer: a record added, removed, or changed in value, that nobody told the monitoring layer to expect.

The word is deliberate. Drift implies gradual or unintentional change, as distinct from a planned migration. Most DNS drift is not malicious — it's the result of normal infrastructure activity that never got communicated to whatever is watching.

Common causes

Hosting / server migrations. A site moves from one provider to another and the new host updates the A record to its own IP. If that happens without a heads-up, your monitoring sees a changed A record with no explanation. This is the single most frequent source of drift.

TTL misconfiguration. A record with a 24-hour TTL (86400) gets cached hard by resolvers. Change the value without lowering the TTL first and different resolvers return different answers during the propagation window — real, but transient. (Worth checking a change from a couple of resolvers yourself with dig @1.1.1.1 / dig @8.8.8.8 before you treat it as an incident.)

DNS provider / registrar changes. Transfer the domain or switch DNS providers and the NS records change; the whole zone has to be re-populated on the new provider. Missing or mis-typed records after that move are a classic post-migration outage.

Accidental edits. Registrar-level DNS editors make it easy to delete or retarget the wrong record while editing a different one — especially in shared accounts where several people have write access.

DNS-level attacks. Rarer, but real: an attacker who gets into a registrar account, or exploits a resolver, can retarget a hostname to infrastructure they control. Baseline-diff detection catches this the same way it catches a benign change — any deviation from the snapshot is flagged.

Why uptime monitors don't catch it

A standard uptime check fetches a URL and records whether it got 200. If the A record changes but the new host also returns 200 for the same path, the uptime monitor reports the site healthy.

That's not a bug in uptime monitoring — it's just not what it's for. A site can be "up" from an availability standpoint while serving from an unexpected host, routing mail to the wrong server, or bypassing the CDN's security layer entirely. Drift detection works one layer down: it watches the records themselves, not the HTTP response they eventually resolve to.

How baseline-diff detection works

The mechanism is simpler than it sounds, and it's worth being precise about it because "we cross-check three resolvers" is a claim you'll see and it's usually not what's happening.

Each cycle, Merlonix resolves the monitored hostname's records through an independent DNS-over-HTTPS resolver — one lookup, from outside your own network, so a stale local cache can't hide a change and a captive resolver can't silently rewrite the answer in transit. That result is diffed against the stored baseline. Any record added, removed, or changed in value is captured.

Then it's triaged, because a raw diff pages you for nothing:

• Benign — CDN IP rotation inside a provider's published ASN ranges (Cloudflare shuffling IPs), TTL tweaks, a TXT record added for third-party verification. Logged for visibility, no page.
• Material — an A record pointing outside known hosting ranges, NS moved to an unrecognized provider, MX removed or changed (email impact), a CNAME retargeted to an unknown host. Fires an alert.

Detection is one DoH query plus a diff against the baseline; the value is in the triage step that decides which diffs are worth waking someone for — not in querying more resolvers.

Responding to a real change

1. Confirm it's real. Cross-reference with a manual dig/nslookup from two locations. If your manual lookup and the monitor agree, it's real, not propagation noise.
2. Determine if it was authorized. Planned migration? A teammate editing the zone? A new service that needed a record?
3. If authorized, re-baseline. Acknowledge the change so the new state becomes the baseline; future checks diff against it.
4. If not, treat it as an incident. An unexplained A, NS, or MX change is a potential compromise — check the registrar's activity log, rotate any exposed credentials, restore the correct values, write it up.

Full version (with the agency-operations framing) on the Merlonix blog: DNS record drift: what causes it, how to detect it, and what to do. Merlonix diffs every monitored domain's DNS against a stored baseline on each cycle and triages benign vs. material change — start a free 14-day trial, no card required.