DNS drift

DNS drift is the gradual mismatch between intended and actual DNS configuration across records, zones, and environments. It usually appears when changes are made manually, ownership is unclear, or multiple teams manage the same estate without version control and review.

Expanded Definition

DNS drift is a configuration integrity problem: the DNS state that exists in production no longer matches the state that was intended, approved, or documented. In NHI and cloud environments, that mismatch can involve A, CNAME, MX, TXT, SRV, and NS records, delegated zones, resolver policies, or environment-specific entries used by services and automation. The risk is not just broken resolution. Drift can redirect traffic, expose internal names, undermine domain validation, and create openings for account takeover or token interception when service endpoints depend on DNS trust. This is why DNS drift belongs in governance conversations alongside change control, asset inventory, and NIST Cybersecurity Framework 2.0. Definitions vary across vendors when DNS is embedded in broader “configuration drift” tooling, but the operational issue is the same: the authoritative record set is no longer the one operators believe is live. The most common misapplication is treating DNS drift as a minor hygiene issue, which occurs when teams assume low-visibility records cannot affect authentication, routing, or verification workflows.

Examples and Use Cases

Implementing DNS change control rigorously often introduces deployment friction, requiring organisations to weigh faster updates against stronger review, rollback, and ownership discipline.

• A service moves to a new cloud region, but the old CNAME remains active, sending some users and automated clients to deprecated infrastructure.
• Multiple teams edit TXT records for domain verification, and one team overwrites another team’s entry, breaking email security or SaaS onboarding.
• An expired proof-of-control record is left behind after a migration, creating misleading evidence that a domain is still tied to an old tenant or tool.
• DNS settings are changed manually during an incident, but the change is never reconciled back into source control or the CMDB.
• For attack context, the Salesloft OAuth token breach illustrates how weak control around connected services can turn a small trust failure into broad exposure, while NIST Cybersecurity Framework 2.0 maps the need for disciplined identify, protect, detect, and recover practices.

These patterns are especially common where DNS is shared across application, security, and infrastructure teams without a single approval path.

Why It Matters in NHI Security

DNS drift matters to NHI security because many non-human workflows depend on DNS to locate APIs, validate domains, fetch certificates, and route automation traffic. When the DNS truth set drifts, service accounts and agents can be sent to the wrong endpoint, validation records can become stale, and attackers can exploit leftover trust paths that operators no longer monitor. NHIMG data shows that 96% of organisations store secrets outside secrets managers in vulnerable locations, and DNS drift often compounds that exposure by making the exposed service surface harder to track. It also weakens incident response: defenders cannot quickly distinguish intended records from abandoned ones, which slows containment and makes rogue changes harder to spot. The governance lesson is simple. DNS should be treated as a controlled identity dependency, not a static background service, and its records should be reconciled as part of the broader NHI lifecycle described in the Ultimate Guide to NHIs. Organisations typically encounter the cost of DNS drift only after a misroute, outage, or token abuse event, at which point the term becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• DNS governance drift
• How should security teams think about a compromised integration like Drift?
• How can security teams reduce privilege drift in Kubernetes RBAC?
• Runtime Drift