Overview
Security scanners frequently identify dangling DNS records and report them as potential security risks. While dangling DNS records should be reviewed and corrected when possible, a dangling record does not automatically mean that a domain or subdomain takeover is possible.
A dangling DNS record is a configuration issue.
A domain or subdomain takeover is a security vulnerability.
Understanding the difference helps organizations prioritize remediation efforts and avoid false positive security findings.
Understanding the Difference
A common misconception is that every dangling DNS record creates a takeover vulnerability.
This is not always the case.
A dangling DNS record means DNS points to a destination that may no longer be valid.
A takeover vulnerability exists only if another party can successfully obtain control of the referenced resource and serve content or services using the affected hostname.
The DNS record alone does not prove that this condition exists.
What Is a Dangling DNS Record?
A dangling DNS record exists when a DNS record points to a resource that no longer exists, has been removed, or is no longer associated with the intended service.
Dangling DNS records are also commonly referred to as:
- Dangling CNAME records
- Orphaned DNS records
- Abandoned DNS records
- Stale DNS records
Common examples include:
- CNAME records pointing to deleted cloud services.
- Records referencing decommissioned websites.
- References to expired third-party services.
- Records pointing to resources that have been removed from a cloud provider.
Example:
www.example.com CNAME abandoned-service.cloudprovider.com
Example:
portal.example.com CNAME deleted-application.vendor.com
In these situations, DNS continues directing traffic toward a destination that may no longer be operational.
What Is a Domain or Subdomain Takeover?
A domain or subdomain takeover occurs when a third party gains control of the resource referenced by a DNS record and begins serving content, applications, or services using the affected hostname.
Examples include:
- Claiming an abandoned cloud application.
- Registering an unclaimed SaaS tenant.
- Taking ownership of a deleted hosting resource.
- Serving content under an organization's hostname.
A takeover requires actual control of the destination resource.
The Key Difference
A dangling DNS record indicates a potential risk that should be investigated.
A takeover indicates that the risk has been successfully exploited.
The existence of a dangling record alone does not prove that a vulnerability exists.
Why Security Scanners Frequently Report Takeover Risk
Many security scanners classify dangling records as takeover vulnerabilities because they cannot always determine whether the destination resource can actually be claimed.
The scanner may detect:
- A DNS record exists.
- The destination appears inactive.
- The resource no longer responds.
The scanner often cannot determine:
- Whether the resource can be claimed by another party.
- Whether ownership protections exist.
- Whether the provider permanently reserves deleted resources.
- Whether account-level controls prevent registration.
- Whether the service requires ownership validation.
As a result, automated findings frequently identify potential takeover conditions that require additional investigation.
When a Dangling Record Does Not Create Takeover Risk
A dangling record may not be exploitable when:
- The destination resource cannot be claimed by another customer.
- The provider permanently reserves deleted resources.
- Ownership validation is required before activation.
- The referenced service no longer accepts new registrations.
- Additional security controls prevent reassignment.
In these situations, the DNS record may be misconfigured but may not create a takeover opportunity.
When a Dangling Record May Create Takeover Risk
A dangling record may create takeover risk when:
- The referenced service allows registration of previously used identifiers.
- The destination resource can be re-created by another party.
- Ownership validation is not required.
- The original service instance has been removed.
- A third party can successfully activate the referenced hostname.
In these situations, remediation should occur as quickly as possible.
Common Examples
Low Risk Scenario
app.example.com CNAME retired-service.vendor.com
The service no longer exists, but the provider does not allow retired identifiers to be claimed by other customers.
Result:
- Dangling record exists.
- No takeover opportunity exists.
Potential Takeover Scenario
portal.example.com CNAME oldapp.provider.com
The original application was removed and another customer can register the same identifier.
Result:
- Dangling record exists.
- Takeover opportunity may exist.
Confirmed Takeover Scenario
portal.example.com CNAME oldapp.provider.com
A third party successfully registers the referenced resource and serves content using portal.example.com.
Result:
- Takeover confirmed.
- Immediate remediation required.
What Information Should Be Collected?
Before concluding that a dangling DNS record represents a vulnerability, gather:
- DNS record details.
- Destination hostname.
- Evidence that the destination resource is inactive.
- Evidence that the resource can be claimed.
- Screenshots or proof of successful registration.
- Screenshots or proof of successful content hosting.
Without evidence that the resource can actually be controlled by another party, the finding should be treated as a potential risk rather than a confirmed vulnerability.
How UltraDNS Helps Identify Dangling Records
UltraDNS includes a Dangling DNS Records Report that helps identify DNS records that may reference inactive or misconfigured resources.
The report is intended to help customers proactively identify and review potential risks within their DNS environment.
The presence of a record in the report does not automatically indicate a takeover vulnerability. Additional validation is required to determine whether the referenced resource can actually be claimed by a third party.
Recommended Remediation
- Determine whether the DNS record is still required.
- Determine whether the destination resource still exists.
- Remove obsolete DNS records.
- Update records that should point to active resources.
- Evaluate whether the destination resource can be claimed by another party.
- Prioritize remediation when exploitability has been confirmed.
Important Notes
- A dangling DNS record is not automatic proof of a vulnerability.
- A takeover vulnerability requires evidence that another party can control the referenced resource.
- Automated scanner findings often require additional validation.
- Removing unused DNS records reduces operational and security risk.
- Exploitability should be confirmed before classifying a finding as a confirmed takeover.
Summary
A dangling DNS record and a takeover vulnerability are not the same thing.
A dangling DNS record indicates that DNS points to a destination that may no longer be valid.
A takeover vulnerability exists only when a third party can successfully obtain control of that destination and serve content or services under the affected hostname.
Organizations should treat dangling DNS records as indicators for investigation, not automatic confirmation of compromise or exploitability.
```