DNS Record Drift: What Causes It, How to Detect It, and What to Do When It Happens

DNS record drift is a silent category of infrastructure change. Unlike an expired SSL certificate — which produces a visible browser error — a DNS record change can go completely unnoticed while quietly redirecting traffic, breaking email delivery, or pointing a subdomain at a decommissioned server.

For marketing agencies managing multiple client domains, drift is a persistent background risk. The DNS zone for a client domain may be controlled by the client's IT team, a previous agency, or a registrar account the client set up five years ago. Changes happen for many reasons, often without the agency being informed.

What DNS Record Drift Is

Drift, in this context, means any deviation from a known baseline. When you establish monitoring for a domain, the monitoring system snapshots the current DNS records for that hostname: the A records, AAAA records, CNAME values, MX records, TXT strings, NS delegation, and any other record types configured.

That snapshot becomes the baseline. Drift is any subsequent check that returns a different answer — a record added, removed, or changed in value — that was not expected and not authorized by the agency.

The word "drift" is deliberate. It implies gradual or unintentional change, as distinct from a planned migration. Most DNS record drift is not malicious. It is the result of normal infrastructure activity that was never communicated to the monitoring layer.

Common Causes of DNS Drift

Server or hosting migrations

When a client moves their site from one hosting provider to another, the hosting company typically updates the A record to point to the new server IP. If the migration is handled by the client's IT team or the new hosting provider without notifying the agency, the agency's monitoring will detect a changed A record with no explanation. This is one of the most frequent sources of drift alerts.

TTL misconfiguration

A very high TTL — say, 86400 seconds — means DNS resolvers cache records for 24 hours. If a change is made to a record and the TTL was not lowered first, different resolvers will return different answers during the propagation window. A monitoring system checking from multiple resolvers simultaneously may see inconsistent results, which can appear as drift even if the change was intentional.

DNS provider changes

When a client transfers their domain to a new registrar or switches their DNS to a different provider, the NS records change and the entire zone needs to be re-populated. Missing or incorrectly configured records on the new provider are a common post-migration issue, and the monitoring system will detect the NS change as drift immediately.

Accidental deletion

DNS control panels — especially registrar-level DNS editors — make it straightforward to accidentally delete a record or modify a value while editing a different one. This is more common than it sounds, particularly in shared registrar accounts where multiple people have access.

DNS-level attacks

DNS hijacking and cache poisoning attacks are less common than the above, but they do occur. An attacker who gains access to a registrar account or exploits a resolver vulnerability can redirect a hostname to a server they control. Drift detection catches this class of change the same way it catches benign changes — any deviation from the baseline triggers an alert.

Why Uptime Monitors Do Not Catch DNS Drift

A standard uptime check fetches a URL and records whether the response is HTTP 200. If the A record for a domain changes but the new server also returns 200 for the same URL, the uptime monitor reports the site as healthy.

This is not a failure of uptime monitoring — it is simply not what uptime monitoring is designed to detect. A site can be "up" from a pure availability perspective while serving content from an unexpected host, routing email to the wrong server, or exposing a configuration that bypasses the CDN's security layer.

DNS drift detection works at a different layer: it watches the DNS records themselves, not the HTTP response they ultimately point to.

How Drift Detection Works

Merlonix checks each monitored domain's DNS records from three independent resolvers on each check cycle. Using three resolvers rather than one serves two purposes: it filters out single-resolver anomalies (stale cache, transient lookup failure), and it provides corroboration for genuine changes (if all three resolvers agree on a new value, the change is real).

Each check result is diffed against the stored baseline. Any deviation — a record added, removed, or changed in value — is captured and classified.

Benign drift examples:

CDN IP rotation within a known provider's IP space (e.g., Cloudflare shuffling IP addresses within its published ASN ranges)
TTL value adjustments
TXT record additions for third-party service verification

Material drift examples:

A record pointing to an IP outside known hosting provider ranges
NS records changed to an unrecognized DNS provider
MX records removed or modified (email delivery impact)
CNAME changed to an unknown target hostname

Merlonix's triage layer classifies detected drift as benign or material and routes accordingly. Material changes fire an immediate alert. Benign changes are logged for visibility without generating a page.

How to Respond When Drift Is Detected

Step 1: Confirm the change is real. Cross-reference with a manual DNS lookup (dig or nslookup) from at least two locations. If the monitoring system and your manual lookup agree, the change is real.

Step 2: Determine if it was authorized. Check with your internal team and the client's team. Was a server migration planned? Did the client's IT team make changes to the zone? Was a new service added that required a DNS record?

Step 3: If authorized, update the baseline. Acknowledge the change in your monitoring dashboard so the new record state becomes the new baseline. Future checks will diff against the updated snapshot.

Step 4: If unauthorized, investigate immediately. An unexplained A record change, NS delegation change, or MX record modification is a potential security incident. Check the registrar account's activity log, change any compromised credentials, and restore the records to their correct values. Document the incident for the client.

DNS drift monitoring is included in all Merlonix plans. When you add a domain, Merlonix snapshots the current DNS state and begins diffing from the next check cycle forward. You do not need to configure what to watch — all record types are monitored by default.

Start a free 14-day trial at merlonix.com/pricing/ — no credit card required.