TL;DR: Dangling DNS records that point to decommissioned cloud services can let attackers take over trusted subdomains, bypass perimeter controls, and use an organisation’s own domain for phishing or malware delivery, according to DigiCert. The core issue is identity and ownership drift: records outlive the assets they were meant to represent, so governance fails before detection does.
At a glance
What this is: This is DigiCert’s analysis of how abandoned DNS records can become hijackable trust points that expose subdomains to takeover.
Why it matters: It matters because DNS ownership drift creates an identity governance problem for machine, platform, and security teams that manage service endpoints, cloud migrations, and delegated access.
By the numbers:
- Over 670 Microsoft subdomains were found vulnerable to takeover due to misconfigured DNS entries pointing to unclaimed Azure services.
👉 Read DigiCert's analysis of dangling DNS records and domain hijacking risk
Context
Dangling DNS records are DNS entries that still resolve even though the underlying service, storage bucket, or cloud resource has been deleted, moved, or no longer belongs to the organisation. In identity terms, the name still exists after the asset has left, which means trust can persist after ownership has gone.
That creates a governance gap for NHI and cloud operations teams because subdomains often inherit organisational trust by default. In environments with frequent migrations, third-party integrations, and rapid product rollouts, cleanup trails the infrastructure lifecycle, and the stale record becomes a claimable attack surface.
For practitioners, the problem is not just broken routing. It is the mismatch between DNS lifecycle and asset lifecycle, which is why DNS hygiene has to be treated as an identity-adjacent control rather than a housekeeping task.
Key questions
Q: How should security teams prevent dangling DNS records from creating takeover risk?
A: Security teams should tie DNS record retirement to the same workflow that decommissions the underlying service. That means inventorying subdomains, removing obsolete CNAME and A records, confirming third-party targets are still owned, and verifying that redirects or replacements do not leave a stale trust pointer behind.
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: What signs show that DNS hygiene has drifted out of control?
A: Look for records that point to retired cloud services, unexplained resolution failures, subdomains with no clear owner, and changes that are not tied to an approved decommissioning workflow. If DNS change logs do not match the infrastructure lifecycle, stale exposure is already present.
Q: Who is accountable when a hijacked subdomain is used for phishing or malware?
A: Accountability usually sits with the team that owned the subdomain, the platform group that retired the resource, and the governance function that failed to enforce lifecycle closure. The key question is not only who discovered it, but who allowed the trust boundary to remain after the asset was gone.
Technical breakdown
How dangling DNS records create a claimable trust boundary
A dangling A or CNAME record points traffic to a resource that no longer exists or is no longer controlled. DNS does not validate ongoing ownership of the target, so resolution continues even when the asset has been decommissioned. If the abandoned cloud name can be re-registered or re-created, an attacker can bind malicious content to a trusted subdomain. The failure is not DNS resolution itself. The failure is that name ownership, resource ownership, and access control have drifted apart.
Practical implication: inventory every external DNS target and confirm the named resource is still owned, active, and monitored.
Why subdomain takeover bypasses normal security controls
Subdomain takeover works because many security tools, users, and allowlists treat a legitimate parent domain as a trust signal. Once the attacker controls the dangling target, they can host phishing pages, malware, or credential-harvesting workflows under a familiar domain name. That reduces user suspicion and can sidestep controls that key off domain reputation alone. DNSSEC can protect record integrity, but it does not solve abandoned ownership or unrevoked external dependencies.
Practical implication: pair DNSSEC with lifecycle offboarding for records that point to third-party or cloud-hosted resources.
What DNS hygiene needs to do across cloud migrations and decommissioning
Effective DNS hygiene is a control loop, not a one-time cleanup. It should tie asset retirement, third-party service removal, and DNS record review into the same workflow so obsolete entries are removed when the underlying service is retired. Change approval, version control, and logging matter because they create a reviewable record of who changed what and why. Without that linkage, the organisation keeps a trust pointer that no longer corresponds to a real asset.
Practical implication: bind DNS record removal to decommissioning workflows so stale entries cannot survive service retirement.
Threat narrative
Attacker objective: The attacker wants to weaponise a trusted subdomain so malicious content appears to come from the organisation itself.
- Entry begins when an attacker identifies a dangling DNS record that points to a decommissioned or unclaimed service under a trusted domain.
- Escalation occurs when the attacker claims the abandoned target or re-creates the referenced service, gaining control of the subdomain’s content and traffic.
- Impact follows when the hijacked subdomain is used for phishing, malware delivery, or credential harvesting while inheriting the parent domain’s trust.
Breaches seen in the wild
- Codefinger AWS S3 ransomware attack — Codefinger used compromised AWS credentials to encrypt S3 buckets via SSE-C.
- Azure Key Vault privilege escalation exposure — Azure Key Vault Contributor role misconfiguration enabled privilege escalation.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dangling DNS records are an identity governance failure, not a routing problem. The visible symptom is a bad DNS pointer, but the underlying issue is that the organisation allowed a trust-bearing name to outlive the asset it identified. That breaks the basic governance assumption that ownership, control, and resolution remain aligned through the lifecycle. Practitioners should treat stale records as evidence of lifecycle drift across infrastructure, security, and platform teams.
Identity blast radius extends to every trusted subdomain that outlives its service owner. Once a subdomain is decoupled from the resource behind it, an attacker can inherit brand trust without compromising the primary domain. That makes subdomain takeover an NHI-adjacent risk because the exposed surface is machine-managed, delegated, and often outside human review cadence. The practical implication is that DNS records need the same lifecycle scrutiny as service accounts and API credentials.
DNSSEC is necessary but not sufficient when ownership has already expired. Record authenticity does not matter if the named target has been abandoned and can be reclaimed or impersonated elsewhere. This is the same control gap seen in other lifecycle failures: the system validates the pointer, not the continuing legitimacy of the destination. Security teams should therefore measure ownership continuity, not just record integrity.
Stale trust pointers is the right concept for this problem. The record still resolves, the domain still looks valid, and the organisation may still trust it, but the underlying service relationship has ended. That concept matters because it shifts the conversation from cleanup to governance of trust persistence. The organisation that cannot retire names cleanly cannot reliably control where its authority is being projected.
From our research:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, with 46% confirmed and 26% suspected, according to the 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, which shows that identity compromise is rarely isolated once governance drift begins.
- For a broader view of the identity control problem, the Ultimate Guide to NHIs , Key Challenges and Risks helps practitioners map sprawl, over-privilege, and abandoned credentials into one governance model.
What this signals
With 67% of organisations still relying heavily on static credentials in the 2026 Infrastructure Identity Survey, the lesson for platform teams is straightforward: stale trust pointers and stale secrets tend to fail together, so DNS lifecycle and secret lifecycle should be governed as one control plane.
Stale trust pointers: this pattern is not limited to DNS. Any delegated name, endpoint, or token that survives after its underlying asset has changed can preserve trust longer than control, so asset retirement workflows need explicit identity closure steps.
Teams that already manage machine identity through lifecycle discipline should extend the same review logic to subdomains, redirects, and cloud endpoint records. The control objective is continuity of ownership, not just continuity of service.
For practitioners
- Bind DNS cleanup to service decommissioning Require DNS record removal or repointing as a mandatory step in cloud service retirement, subdomain migration, and third-party offboarding. If the underlying resource changes, the record should not remain as a live trust pointer.
- Scan for unclaimed or orphaned DNS targets Use inventory and monitoring tools to detect CNAME and A records that resolve to decommissioned services, expired cloud resources, or external targets no longer under organisational control.
- Treat subdomains as governed assets Assign clear ownership, review cadence, and logging for every subdomain, including marketing, product, and integration endpoints. A subdomain without an owner is a trust boundary without accountability.
- Validate trust paths after every migration After cloud moves or service retirements, confirm that public names, redirects, certificates, and DNS targets still align. This prevents old names from continuing to resolve to services the organisation no longer controls.
Key takeaways
- Dangling DNS records create a governance gap because the trusted name survives after the underlying asset has been retired.
- The takeover risk is real and measurable, with more than 670 Microsoft subdomains previously exposed through misconfigured DNS entries.
- The most effective control is lifecycle-linked DNS cleanup, backed by ownership tracking, inventory scans, and mandatory decommissioning checks.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-05 | Dangling DNS records are an unmanaged identity and trust exposure. |
| NIST CSF 2.0 | PR.AC-4 | Trust boundary drift exposes public-facing assets to unauthorised use. |
| NIST Zero Trust (SP 800-207) | PR.AA-1 | Continuous verification fails when abandoned endpoints remain trusted. |
Revalidate external endpoints and delegated targets as part of zero-trust asset review.
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.
- DNS Hygiene: The discipline of keeping DNS records accurate, owned, reviewed, and tied to real assets throughout their lifecycle. In practice it combines change control, inventory, decommissioning checks, logging, and continuous cleanup of obsolete or unsafe entries.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance maturity, it is worth exploring.
This post draws on content published by DigiCert: Dangling DNS Records and the Risk of Domain Hijacking. Read the original.
Published by the NHIMG editorial team on 2026-06-17.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org