Cybersecurity glossary
What is a Dangling DNS Record?
Learn what a dangling DNS record is, why stale records pointing to deleted cloud resources create takeover paths, and how to clean up DNS safely during service decommissioning.
Definition
A dangling DNS record is a live DNS entry that still points to a resource that has been deleted, released, or is no longer under the owner's control, creating a risk that someone else can claim the destination.
Why dangling records become takeover opportunities
DNS usually changes more slowly than cloud infrastructure. Teams spin up preview apps, move mail providers, retire CDNs, shut down storage buckets, and rename load balancers. If the DNS cleanup step never happens, the record can outlive the resource it names.
That gap is where a dangling DNS record becomes dangerous. The hostname still looks legitimate to users, but the backend may no longer belong to the organization. In multi-tenant platforms, another customer may be able to claim the abandoned target and effectively inherit traffic for that DNS name.
The anatomy of a stale mapping
Different record types dangle in different ways. The common thread is lost ownership of the destination while the DNS answer remains valid.
Alias left behind
A CNAME still points at a SaaS hostname after the workspace, site, or distribution behind it was deleted.
Address reassignment
An A or AAAA record references an IP or service endpoint that is later reissued, recycled, or controlled by someone else.
Mailbox drift
An MX record can become stale after a mail migration, creating delivery confusion or a path to interception if the old provider name is claimable.
Delegation residue
NS or glue data may remain after a hosted zone move, sending resolvers toward servers that no longer represent the intended owner.
How a dangling record turns into abuse
A service is retired
The organization deletes or abandons a cloud resource, vendor tenant, or temporary environment.
DNS stays published
The hostname remains in the zone because decommissioning and DNS ownership are handled by different people or tools.
The target becomes claimable
Another tenant can register the hostname, provision the same service name, or receive traffic for the released endpoint.
Attackers probe for leftovers
They scan DNS names and service error messages for signs that a resource is unclaimed but still referenced.
A new backend is attached
Once claimed, the attacker can host web content, collect requests, or otherwise impersonate the intended service.
Trust is borrowed from the hostname
Users and systems continue to treat the DNS name as legitimate because the record never changed.
What defenders should evaluate first
| Check | Example | Why it matters |
|---|---|---|
| Resource ownership | Does the team still control the bucket, app, CDN distribution, or provider tenant named by the record? | Loss of backend ownership is the core takeover condition. |
| Business intent | Is this hostname still supposed to exist after the migration or project shutdown? | A surprising number of stale records remain simply because nobody asked whether the name still had a purpose. |
| Service behavior | Does the destination return an unclaimed-site banner, vendor error page, or TLS mismatch? | Those responses often reveal whether the target can be hijacked. |
| Deletion workflow | Was the old resource removed before the DNS alias was updated or deleted? | Order of operations often determines whether a brief takeover window appears. |
Cleanup habits that prevent repeat exposure
- Make DNS removal or repointing a required step in every decommissioning runbook.
- Track each externally visible hostname to a service owner, not just a platform team.
- Periodically resolve every published hostname and compare the results with what your asset inventory says should exist.
- Alert on vendor-specific unclaimed-resource banners returned from names in your zones.
- Lower TTL before planned migrations so stale answers disappear quickly after the record changes.
- Avoid deleting a backend until the replacement record is live and verified from recursive resolvers.
- Review old staging, preview, campaign, and acquisition-related subdomains because they are frequent sources of abandonment.
- Include mail and delegation records in hygiene reviews, not just web-facing CNAMEs.
Why decommissioning order matters
The safest sequence is usually to repoint or remove DNS first, wait for caches to age out, verify that resolvers no longer direct traffic to the old name, and only then delete the backing service. Reversing that order can create a silent exposure window even in well-managed environments.
DNS hygiene is therefore not just a naming issue. It is lifecycle management for Internet-facing trust.
The practical takeaway
A dangling DNS record is a live pointer to something you no longer control. That can turn ordinary cleanup debt into a subdomain takeover opportunity.
The fix is straightforward but operationally strict: keep a hostname inventory, pair every resource deletion with DNS review, and assume that any Internet-facing name left behind may eventually be tested by an attacker.
Related security terms
A Record
A direct IPv4 mapping can become dangerous when it still references an address or service that changed hands.
CNAME Record
CNAMEs commonly dangle when a SaaS hostname or cloud endpoint is deleted but the alias remains.
Subdomain
A dangling record often exposes a specific subdomain to takeover rather than the entire parent domain.
Domain Shadowing
A different path to subdomain abuse that comes from account compromise instead of stale infrastructure.
Glue Record
Parent-side address data must also be reviewed so outdated delegation helpers do not misdirect traffic.
Frequently asked questions
What is a dangling DNS record in simple terms?
It is a DNS record that still exists even though the server, cloud app, or vendor endpoint it points to has already been removed.
Why are dangling DNS records risky?
If an attacker can claim the abandoned destination, they may serve content or receive traffic for the still-trusted hostname.
Are CNAME records the only ones that can dangle?
No. CNAMEs are common, but A, AAAA, MX, NS, and other records can become stale too when infrastructure ownership changes.
Is every stale record exploitable?
Not always. Exploitability depends on whether the destination can be reclaimed by another tenant or reissued to someone else.
How do teams usually create dangling records?
They decommission a cloud resource, vendor integration, or temporary environment without removing the DNS record that referenced it.
How do you find dangling DNS records?
Compare your current DNS inventory against live infrastructure ownership, watch for service-specific error banners, and review deletion workflows for unpaired DNS cleanup.
What is the fastest way to fix one?
Remove the record if it is no longer needed, or repoint it immediately to a resource you control before deleting the old backend.
References
Explore authoritative guidance and frameworks related to dangling dns record.
Explore every security definition
Return to the glossary to search by term, alias, starting letter, or security category.