A DNS record that still resolves to a target the organisation no longer controls. It usually points to a deleted cloud service, expired resource, or unused third-party endpoint. The record remains live even though the underlying asset has left the lifecycle.
Expanded Definition
A dangling DNS record is not just a stale entry. In NHI and cloud operations, it is a live naming artifact that still resolves even though the underlying service, endpoint, or delegated resource has been decommissioned, transferred, or abandoned. That creates a trust gap between what DNS says exists and what the organisation actually controls. The operational risk is similar to a reclaimed identifier: the record can misroute traffic, expose users to takeover conditions, or preserve a path to a forgotten dependency.
Definitions vary across vendors on whether the term should include only direct CNAME-style service aliases or also orphaned records created by load balancers, third-party SaaS, and subdomain delegations. NHI Management Group treats the term broadly because the security problem is the same: the organisation has lost authoritative control while the name remains public and routable. For governance, this should be handled as an asset lifecycle failure, not a simple DNS hygiene issue. The most common misapplication is treating a dangling DNS record as harmless cleanup debt, which occurs when teams deprovision the service before removing every dependent record.
For the baseline record lifecycle and control expectations, see NIST Cybersecurity Framework 2.0.
Examples and Use Cases
Implementing dangling-record controls rigorously often introduces release friction, requiring organisations to balance fast cloud teardown against the discipline of verifying every DNS dependency before decommissioning.
- A marketing subdomain still points to a cloud app that was deleted after a campaign ended, leaving the record exposed to re-registration by another tenant.
- A CNAME remains mapped to a third-party SaaS tenant that the company no longer owns, creating a route for content impersonation if the namespace is reclaimed.
- A load balancer address is removed during migration, but the DNS alias survives in production zones and continues to resolve for external users.
- A delegated subdomain is retired during a merger, yet the child zone record is never removed, leaving an unnecessary public trust boundary behind.
- A service endpoint tied to an expired proof-of-concept environment persists after shutdown, which is easy to miss when teams only track infrastructure tickets and not DNS ownership.
NHIMG’s Ultimate Guide to NHIs highlights how lifecycle blind spots appear across offboarding and revocation, and the same pattern applies when DNS entries outlive the assets they describe. For implementation detail on names, delegation, and authoritative control, organisations often pair that lifecycle view with NIST Cybersecurity Framework 2.0 to anchor asset governance and change control.
Why It Matters in NHI Security
Dangling DNS records matter because they extend the attack surface of non-human identities beyond the credentials themselves. A record may still route users, automation, or API calls to an endpoint that no longer has legitimate ownership, which can enable traffic capture, impersonation, or hidden dependency failures. In NHI programs, this often becomes a governance problem rather than a purely technical one, because DNS records are frequently created by one team and retired by another.
That disconnect is especially dangerous when the record fronts systems protected by tokens, service accounts, or certificates. If the target has been abandoned but the name remains active, defenders may assume the asset is still in scope while an attacker sees an opportunity to claim the abandoned service path. The same lifecycle gap also undermines Zero Trust, because policy enforcement depends on knowing what is actually authoritative and current. The Ultimate Guide to NHIs notes that only 20% of organisations have formal offboarding and API-key revocation processes, which is a useful indicator of how often teardown steps are incomplete.
Organisations typically encounter the consequence only after a takeover attempt, traffic anomaly, or failed migration reveals that the DNS name still resolves, at which point dangling DNS record management becomes operationally unavoidable to address.
