What is DNS Drift and Why Does It Matter?

What is DNS drift?

DNS drift is when the actual records on your DNS provider don't match what your team approved and intended to be there. It's the gap between "what we think our DNS looks like" and "what it actually looks like right now."

In a perfect world, every DNS change goes through a process: someone proposes a change, someone else reviews it, it gets applied, and the live state matches the approved state. Drift is what happens when that chain breaks — when records get added, modified, or deleted outside your normal workflow.

The term borrows from infrastructure-as-code concepts. Just as Terraform detects "configuration drift" when cloud resources diverge from declared state, DNS drift is when live zones diverge from what was last approved through your change management process.

What causes drift?

Drift doesn't usually happen because someone is being malicious. It happens because production environments are messy and humans take shortcuts under pressure. Here are the most common causes:

Direct console access

Someone logs into the AWS Route 53 console (or Azure Portal, or Cloudflare dashboard) and makes a change directly. Maybe it's 2am and there's an outage. Maybe they just forgot about the workflow. Either way, the change exists on the provider but not in your change log.

Scripts and automation running outside the workflow

A deployment script creates a DNS record as part of provisioning a new service. The script uses the provider's API directly — it works, the record gets created, but nobody submitted a change request. Three months later, nobody remembers why temp-migration-api.example.com exists or whether it's safe to remove.

Provider-side changes

Some DNS changes happen without anyone on your team doing anything. Certificate authority validation records that auto-expire but don't get cleaned up. Records modified during a provider migration. TXT records added by third-party services during verification. These accumulate silently.

Partial failures

A batch change partially completes — three out of five records get created, then the API call fails. Your change log shows "applied" but the actual state is incomplete. Without verification, you won't know until something breaks.

Multiple people, no coordination

In larger teams, two engineers might be working on the same zone without knowing it. One makes a change through the official process, the other makes a "quick fix" directly. The second change isn't tracked, and if there's ever a conflict, the untracked change wins silently.

Why is drift dangerous?

Drift isn't just an untidiness problem. It creates real operational and security risk:

Outages from unexpected record changes

If someone changes an A record outside your process and the new target goes down, your monitoring might catch the outage — but the on-call engineer won't find the change in your audit log. They'll spend time investigating the wrong things because the record "shouldn't have changed." Every minute of confusion during an outage costs money.

Security exposure

MX records control where your email goes. TXT records control SPF, DKIM, and DMARC — the mechanisms that prevent email spoofing. If someone modifies these records outside your workflow, you might not notice until phishing emails are sailing past filters because your SPF record now includes an attacker's mail server.

CNAME records are another risk vector. A dangling CNAME that points to a decommissioned service (a deleted S3 bucket, an expired Heroku app) can be claimed by anyone — they register the target, and your subdomain now serves their content. This is called subdomain takeover, and it starts with untracked DNS drift.

Compliance violations

Many regulatory frameworks (SOC 2, ISO 27001, PCI DSS) require that infrastructure changes be tracked and authorized. If an auditor asks "show me the approval for this DNS change" and the change happened outside your workflow, you have a compliance gap. Drift creates exactly this kind of undocumented change.

On-call confusion

When the DNS records on the provider don't match what your team expects (based on their change log or documentation), troubleshooting takes longer. Engineers trust their tools — if the tool says the record should be 10.20.30.40 but it's actually 10.20.30.99, they'll waste time looking for the problem everywhere except the actual DNS state.

How to detect drift

The manual approach

Some teams try to detect drift manually:

1. Export the current zone from the DNS provider (via CLI or console).
2. Compare it against their documentation or last-known-good state.
3. Look for records that were added, changed, or removed without a corresponding change record.
4. Repeat this for every zone, on every provider, on a regular schedule.

This works, technically. But it doesn't scale. If you manage 20 zones across three providers, you're looking at a tedious, error-prone process that most teams stop doing after the first month. And drift that happens between checks goes undetected until the next manual review — or until something breaks.

The automated approach

Automated drift detection works differently. The system maintains a model of what DNS should look like (based on approved changes), then continuously queries the live provider to compare actual state against expected state. When a discrepancy is found — a record that shouldn't exist, a record that's been modified, a record that's missing — it alerts immediately.

This is what Netra's drift detection does. It connects to each DNS provider, pulls the current zone state on a schedule, and compares it against the last approved state in its change log. Discrepancies trigger notifications through whatever channel the team uses — Slack, Teams, email, or webhooks. The alert includes exactly what changed: which record, what the expected value was, and what the actual value is now.

The key difference from manual detection is time. Automated detection catches drift within minutes, not days or weeks. And it catches every discrepancy, not just the ones you happen to notice.

What to do when drift is detected

Detecting drift is only useful if you have a clear remediation process. Here's a practical framework:

1. Investigate

Before you do anything, figure out what happened. Questions to answer:

• Who made the change? Check provider audit logs (CloudTrail for AWS, Activity Log for Azure, Audit Log for Cloudflare). Most providers track API calls and console actions.
• Why was it made? Talk to the person. Was it an emergency? A mistake? An automated process nobody documented?
• Is the change correct? Sometimes drift is actually the right state — the approved state was wrong, or circumstances changed. Don't blindly revert.

2. Remediate

Once you understand the change, decide what to do:

• Revert: If the change was unauthorized and incorrect, revert it to the approved state. Do this through your normal change process so it's tracked.
• Formalize: If the change is actually correct (a legitimate emergency fix, for example), formalize it — submit a change request retroactively, get it approved, and update your expected state so it's no longer flagged as drift.

3. Prevent

After remediating, address the root cause so it doesn't recur:

• Restrict direct access. Remove console write access for DNS where possible. Use IAM policies that allow read but not write. If people can't change records directly, they can't create drift.
• Use scoped API tokens. If automation needs to modify DNS, give it a token that only Netra (or your change management tool) controls. Don't hand out provider-level write credentials to scripts.
• Establish an emergency process. People go around the workflow during emergencies because the workflow is too slow for a 2am outage. Fix this by having a fast-path — an expedited approval process for emergencies that's still tracked, not bypassed entirely.
• Communicate expectations. Sometimes drift happens because team members don't know the workflow exists. A short onboarding doc or team agreement ("all DNS changes go through Netra, even small ones") prevents accidental bypasses.

Drift is inevitable — detection is the discipline

No team achieves zero drift forever. Emergencies happen. New team members don't know the process yet. Automated systems interact in unexpected ways. The goal isn't to prevent drift from ever occurring — it's to detect it quickly, understand it clearly, and remediate it before it causes harm.

Teams that treat drift detection as a continuous practice (rather than a periodic audit) catch issues in minutes instead of discovering them during incident reviews or compliance audits. That's the difference between a minor cleanup and a major investigation.