A dangling A record is a DNS A record that still points a domain or subdomain to an IP address where the service is no longer hosted. If that address can be claimed by someone else, requests for the name may reach an unintended server, creating subdomain takeover risk and exposure of traffic or trust.
What a dangling A record means
A dangling A record is a DNS mapping that still sends traffic to an IP address after the intended service has been removed. The risk is not the DNS record itself, but the fact that the name can keep resolving to infrastructure no longer under the owner’s control.
This becomes dangerous when the address can be re-claimed or reused by another party. At that point, the original hostname may silently point users, APIs, or automated clients at an unintended server, which can create takeover conditions and trust confusion.
Why dangling A records are dangerous
DNS records are often treated as passive configuration, but stale A records can preserve a live path into a domain long after the application behind it has been decommissioned. That makes them a form of control-plane drift: the name still looks valid even though the service behind it is gone.
The exposure is especially serious for hostnames embedded in bookmarks, scripts, SSO redirects, callbacks, email templates, or allowlists. If the hostname is later claimed by someone else, the old trust relationship can be redirected without changing the visible name.
Internal cleanup guidance such as Subdomain Takeover and Dangling DNS Guide is useful because the problem is usually a lifecycle failure, not a one-time misconfiguration.
How organisations find exposure
Exposure checks start with an accurate inventory of owned domains, subdomains, and the services they should resolve to. Teams then compare live DNS records against current hosting, CDN, cloud, and application ownership so they can identify names that still point to retired infrastructure.
Internet exposure matters because dangling records are only dangerous when the target address or associated service can be claimed, repurposed, or otherwise made to answer for the name. Vendor decommissioning notices, cloud account inventories, and DNS change records help confirm whether a record is stale or merely unusual.
For response workflow detail, Subdomain Takeover Response Playbook is a practical reference for verifying ownership, removing stale mappings, and sweeping for related records across zones.
Security impact on trust, traffic, and identity-related flows
Dangling A records can expose session cookies, redirect flows, API calls, and user traffic to a host the organisation no longer controls. The practical impact depends on what the hostname was used for, but the failure mode is always the same: the DNS name outlives the service behind it.
When a hostname has been used in login redirects, application embeds, or trusted integrations, takeover can turn a harmless-looking DNS entry into a working entry point for phishing, content injection, or traffic interception. The more deeply a name is embedded in operational trust, the more severe the consequence of leaving it behind.
Risk and Threat Considerations
Dangling A records create a takeover path because DNS can continue to direct users to an address after the rightful service owner has disappeared. If another party can claim that address or the hosting service behind it, the stale hostname may become an attacker-controlled endpoint that still inherits trust from the original domain.
Failure mechanism: The organisation deletes or moves a service but leaves the A record in place, then a third party reuses the target infrastructure or claims the service endpoint and begins answering for the hostname.
Impact: Requests, cookies, redirects, and other trust-bound traffic may be delivered to an unintended server, creating subdomain takeover risk, exposure of sensitive traffic, and reputational damage.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | ID.AM-01 — Physical Devices and Systems Inventory | Dangling A records arise when the live name map diverges from the asset inventory. |
| ID.AM-02 — Software Platforms and Applications Inventory | Stale DNS entries persist when applications are removed without updating their name dependencies. | |
| PR.DS-10 — Data in Transit is Protected | Takeover of a stale hostname can divert traffic that was expected to travel to a trusted endpoint. | |
| Recommendation — Maintain an authoritative inventory of hosted services and DNS names before retiring any endpoint. Track each application hostname and retire its DNS records when the service is decommissioned. Validate that protected traffic still resolves only to authorised destinations after service changes. | ||
| CIS Controls v8 | 5 — Account Management | Ownership and deprovisioning discipline reduce stale externally reachable resources left behind after shutdown. |
| 12 — Network Infrastructure Management | DNS records are part of network infrastructure that must be managed throughout the asset lifecycle. | |
| Recommendation — Remove or reassign externally reachable names when the owning service is decommissioned. Review DNS and other network records during decommissioning to eliminate stale exposure paths. | ||
Practitioner Guidance
What to watch for: Treat DNS as part of asset lifecycle management, not just name resolution. A record should be removed or repointed as part of decommissioning, and any hostname used in authentication, redirects, or allowlists deserves extra validation before retirement.
Governance implication: Ownership of domain and application retirement should include a final DNS review, because stale records are often left behind when infrastructure ownership changes faster than configuration cleanup. A delegated service owner can decommission an app without realising the hostname is still active elsewhere.
Practitioner takeaway: The safest posture is to verify every decommissioned hostname against current hosting before retirement is considered complete.