Dangling DNS leaves trusted subdomains claimable across cloud estates

At a glance

What this is: This is a Red Sift analysis of dangling DNS, showing that stale records can let attackers claim deleted cloud names and take over trusted subdomains.

Why it matters: It matters because DNS ownership drift can turn a valid business domain into an identity and trust compromise, affecting phishing, session abuse, and delegated access paths.

Context

Dangling DNS happens when a DNS record continues pointing at a cloud resource after that resource has been deleted. The security problem is not the DNS record itself, but the trust boundary it preserves after ownership of the underlying resource has been lost. In cloud-heavy environments, that drift can create a claimable path into a subdomain that users and services still treat as legitimate.

For IAM and NHI programmes, the identity angle is indirect but real. A reclaimed subdomain can support phishing, token theft, OAuth flow abuse, and mail spoofing that then feed credential compromise or delegated access abuse. The operational weakness is governance continuity: records, resources, and ownership change at different speeds, and most teams do not reconcile them continuously.

Key questions

Q: What breaks when a DNS record still points to a deleted cloud resource?

A: The trust relationship breaks, not just the technical resolution. A stale record can send traffic to a name another party now controls, which turns a legitimate subdomain into an attacker-owned endpoint. That can enable phishing, OAuth abuse, cookie theft, and email interference if the record supports login or messaging flows.

Q: Why do dangling DNS records create more risk than simple broken links?

A: Because they preserve organisational trust after the asset has gone. A dangling record can still resolve under a legitimate domain, which lets an attacker claim the destination and use that trust for phishing, malware delivery, or credential harvesting without needing to compromise the parent domain.

Q: How should security teams prevent subdomain takeover across cloud and third-party services?

A: Security teams should treat subdomain takeover as a lifecycle control problem, not just a DNS issue. The practical approach is to inventory every subdomain, confirm each DNS record still points to an active and owned service, and remove stale CNAMEs and abandoned records during decommissioning. Continuous monitoring matters because attackers often claim orphaned services quickly once a subdomain becomes unclaimed.

Q: What is the difference between DNS hygiene and takeover resistance?

A: DNS hygiene is about keeping records tidy and accurate. Takeover resistance is stronger, because it assumes names can become dangerous after the resource disappears and therefore requires continuous verification of claimability, external reachability, and ownership drift across the whole estate.

Technical breakdown

Why dangling DNS becomes a takeover path

A dangling DNS record usually points to a CNAME target that once resolved to a cloud service, storage bucket, or hosted endpoint. When the resource is deleted, many providers return the name to a reusable pool. If the DNS record is still live, an attacker who registers the same name can receive traffic meant for the original owner. The security failure is not hidden code or credential theft. It is stale external naming combined with resource reuse, which creates a trust transfer the organisation never intended.

Practical implication: Track every external DNS dependency against the live resource it references, not just the DNS record itself.

Why cloud platforms do not close the gap

Cloud providers document the issue, but their controls are not universal across services. Different services handle name reuse, verification, and deletion semantics differently, so a platform may prevent one class of takeover while leaving another untouched. That means the governance problem sits above the provider layer. Teams cannot assume that deleting the cloud asset also neutralises the external attack surface, because the DNS entry can outlive the service and remain externally reachable.

Practical implication: Treat cloud deletion as incomplete until the dependent DNS record is removed and verified as dead.

Continuous discovery versus point-in-time scanning

The operational challenge is scale. A modern estate can contain thousands of subdomains spread across multiple registrars, DNS providers, and clouds. Point-in-time scans miss records created, transferred, or inherited between scans. Continuous discovery is therefore the control pattern that matters: discover, classify, and re-check external records often enough to catch drift before it becomes a takeover opportunity. In practice, that is less about a one-off audit and more about an always-on inventory discipline.

Practical implication: Build external asset monitoring that runs continuously across all registrars and clouds, not just in one account.

Threat narrative

Attacker objective: The attacker’s objective is to inherit trust in a live subdomain and use that position for fraud, credential capture, or session abuse.

1. Entry occurs when an attacker identifies a dangling DNS record that still points to a deleted cloud resource or reusable hostname.
2. Credential or trust abuse follows when the attacker claims the released name and receives traffic intended for the original subdomain.
3. Impact occurs when the attacker uses the trusted subdomain for phishing, token capture, OAuth abuse, or mail-related interception.

Breaches seen in the wild

• 230M AWS environment compromise: 230M AWS environments compromised via exposed .env files with cloud credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Dangling DNS is a governance failure, not a hygiene nuisance. The underlying problem is that ownership of names, records, and resources is not synchronized across cloud and DNS operations. Once those control planes drift apart, external trust persists after the asset is gone. Practitioners should treat stale DNS as an exposure class, not a cleanup task.

Continuous verification is the real control boundary for external naming. Cloud deletion does not equal risk removal because DNS is a separate trust layer with its own lifecycle. The practical lesson is that external identity and access control extend beyond accounts and tokens into the naming infrastructure that routes user and service traffic. Teams that ignore that layer leave a persistent claim path open.

External attack surface management has become a trust-integrity requirement. The named concept here is claimable subdomain exposure: a condition where a valid-looking subdomain can be reassigned through stale DNS and reused cloud names. That exposure sits between infrastructure operations and identity trust. The practitioner conclusion is simple: if the name can be claimed, the control is not finished.

Updated DNS guidance now formalises what many teams treated as edge case risk. The reference point is no longer informal best practice. The combination of OWASP guidance, AWS documentation, and the new NIST DNS deployment guidance means organisations can measure their DNS governance against explicit expectations. That changes the conversation from awareness to accountable control ownership.

Security teams should stop measuring DNS only by availability. Availability misses the more dangerous failure mode, which is attacker-controlled continuity under a trusted name. For identity and fraud teams, that means subdomain takeover sits upstream of phishing, delegated login abuse, and brand impersonation. The right conclusion is that DNS integrity belongs in the same governance conversation as authentication and domain trust.

What this signals

Claimable subdomain exposure: the useful way to think about dangling DNS is as an external identity problem, not just an infrastructure mismatch. When a trusted name can be reclaimed, the control failure sits at the boundary between DNS operations and trust governance, which is exactly where many programmes have weak ownership.

The programme response should shift from cleanup to continuous verification. That means asset inventory, decommissioning controls, and external monitoring need to be linked so that a deleted cloud resource cannot leave a durable public trust path behind.

For practitioners

• Map every external DNS dependency Create a live inventory of records, target resources, registrars, and cloud accounts so deleted assets can be tied back to the names they still support.
• Remove records before decommissioning resources Make record removal a required step in cloud retirement and service offboarding so DNS never outlives the underlying resource.
• Continuously scan for claimable targets Run continuous discovery for dangling CNAMEs, stale hosted endpoints, and reusable cloud names across all registrars and providers.
• Classify high-trust subdomains first Prioritise records used for login, email, OAuth flows, and customer-facing services because those are the highest-value takeover paths.
• Verify takeover resistance after deletion Re-check removed resources from the outside and confirm the old name no longer resolves to a claimable service.

Key takeaways

• Dangling DNS turns ordinary decommissioning drift into a trust compromise when a deleted cloud name remains reachable through an old record.
• The core risk is not theoretical because claimable names can let attackers inherit trusted subdomains and use them for phishing or login abuse.
• The control gap is continuous verification across registrars, DNS providers, and clouds, not a one-time cleanup of individual records.

Key terms

• Dangling DNS Record: 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.
• Subdomain Takeover: An attack in which someone claims or recreates a service behind a dangling subdomain and uses the trusted name to serve malicious content. The key issue is not the parent domain compromise, but the attacker inheriting trust through a stale pointer.
• Claimable Resource: A resource provisioned for an agent or unauthenticated user that can later be claimed by a person or organisation. Claimable resources are typically temporary and size-limited until ownership is established. This pattern reduces friction for automated setup while preserving accountability and preventing open-ended access.
• External Attack Surface Management: External attack surface management is the continuous discovery and monitoring of internet-facing assets, records, and exposures. It helps teams find stale names, orphaned services, and trust drift across multiple registrars, clouds, and SaaS platforms before attackers do.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps identity and security practitioners connect lifecycle control to the broader trust boundaries their programmes depend on.