Notifications
Clear all
Topic starter
23/06/2026 7:12 pm
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.
NHIMG editorial — based on content published by DigiCert: Dangling DNS Records and the Risk of Domain Hijacking
By the numbers:
- Over 670 Microsoft subdomains were found vulnerable to takeover due to misconfigured DNS entries pointing to unclaimed Azure services.
Questions worth separating out
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.
Q: Why do dangling DNS records create more risk than simple broken links?
A: Because they preserve organisational trust after the asset has gone.
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.
Practitioner guidance
- 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.
- 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.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how CNAME and A records become dangling after cloud retirement
- Practical DNS hygiene steps for scanning, repointing, and removing obsolete records
- The subdomain takeover scenario explained in the context of user trust and phishing risk
- DNSSEC and logging considerations for teams managing exposed public namespaces
👉 Read DigiCert's analysis of dangling DNS records and domain hijacking risk →
Dangling DNS records: what they mean for identity governance?
Explore further
25/06/2026 3:05 am
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Dangling DNS records are a domain hijacking risk for IAM teams
