DNS records outlive the things they point at. Somebody deletes a cloud resource, and the hostname that referenced it keeps right on answering, because nothing ever told DNS the other end was gone.
That becomes a security problem if the provider later lets someone else claim the abandoned resource. The organization’s own hostname then starts directing users to infrastructure a stranger controls, and in the usual case nobody had to touch the organization’s DNS to make it happen.
DNS doesn’t know whether the service still exists
A zone stores records. It doesn’t track the lifecycle of the application, cloud resource, or hosting account behind them. Take a CNAME for a hosted app:
docs.example.com. 300 IN CNAME old-project.hosting.example.net.DNS keeps publishing that long after old-project.hosting.example.net is deleted from the platform. The CNAME is still syntactically valid, the authoritative server is still answering correctly, and only the state of the external resource has changed. That mismatch is what people mean by a dangling DNS record.
A dangling record doesn’t have to look broken
The intuitive picture is a lookup that fails, where the target returns NXDOMAIN and a scanner flags it. That picture is misleading, and it’s where automated takeover reports go wrong in both directions.
A dangling record is one whose destination has left the lifecycle that created it. Whether resolution still succeeds depends on the provider and the record type. A CNAME pointing into a shared SaaS or CDN endpoint often keeps resolving perfectly, because the endpoint still exists and serves many customers. What was released is your custom-hostname binding on it. An address record pointing at a returned cloud IP resolves fine too, and can now reach whoever holds that IP next.
So a failed lookup is one symptom, not the definition, and a successful lookup rules out nothing.
Exploitability is decided by the provider
For a takeover to become possible, the external platform has to let an untrusted party create a resource satisfying the stale reference, or bind your hostname to a resource they control. Whether that’s possible is a provider-side fact DNS can’t tell you. A platform may reserve deleted names permanently, require proof of domain ownership before binding a custom hostname, or refuse to attach one hostname to two accounts.
Real platforms differ, and they differ service by service, even within one vendor. Microsoft documents claimable-name scenarios for particular Azure resource types, along with service-specific protections such as deletion-time name reservation and the asuid domain verification record. GitHub Pages runs its own ownership model and documents domain verification to stop other GitHub users claiming a custom domain whose DNS still points at Pages.
A dangling record is always configuration debt, and it becomes a vulnerability only when the thing it references is claimable by someone else.
Usually, the attacker never touches your DNS
This is what separates hosted-service takeover from cache poisoning or a registrar compromise. Your authoritative DNS is untouched and nobody forges anything.
status.example.com. IN CNAME customer-123.hosting.example.net.If the provider lets a new account take control of customer-123.hosting.example.net, ordinary resolution does the rest. The resolver receives the same CNAME it always did and follows it to the same target. Only the ownership behind that target changed.
The exception is a captured delegation, below, where the attacker does end up serving DNS. Even there your own zone is untouched. What changes is who answers for the child.
Provider verification can make a mapping unclaimable
Many hosted platforms demand proof before binding a custom hostname, whether through a DNS TXT record, an account-level verification ID, or another mechanism. Support varies by service, resource generation, and when the hostname was first attached, so it has to be confirmed for the exact service rather than assumed.
Verification doesn’t repair the stale record or unbreak any DNS chain. It limits what the provider will let an account bind, so an unrelated account can’t make the platform serve content for a hostname it hasn’t proven it owns. It also only protects while the required verification state is retained, and its scope varies, with GitHub for example covering the verified domain and its immediate subdomains rather than arbitrary deeper names.
Address records dangle quietly
Cloud IP addresses go back into a pool. An A or AAAA record pointing at a released address keeps resolving with a perfectly normal answer, and can eventually reach whichever tenant is allocated that address next.
legacy.example.com. 300 IN A 203.0.113.42Nothing here fails. There’s no NXDOMAIN, no broken alias, and nothing for a naive scanner to catch, which makes this class easy to miss and worth auditing on its own. The related case is a target sitting under a registrable domain that expires. Register the domain and you capture whatever the CNAME, MX, or NS pointed at, without claiming any cloud resource at all.
Delegations dangle with the highest stakes
A parent zone delegates a child with NS records:
dev.example.com. 3600 IN NS ns-1.provider.example.net.
dev.example.com. 3600 IN NS ns-2.provider.example.net.Delete the child hosted zone while the parent delegation survives, and the parent still tells every resolver to go ask those name servers about dev.example.com. With a large provider the risk isn’t that someone takes ownership of those shared nameserver hostnames but that another account is later assigned a hosted zone whose delegation set overlaps your stale one, so those same servers begin answering authoritatively for your child zone.
That gives this class the widest blast radius, because the attacker gains DNS authority over an entire namespace rather than one hostname. Route 53 protects the ordinary deleted-zone case, and AWS documents several cases it explicitly can’t protect.
Wildcards widen the surface
A wildcard can hand many otherwise-nonexistent names to the same external service:
*.example.com. IN CNAME hosting.example.net.Wildcard synthesis follows closest-encloser rules, so existing names and delegations still take precedence, but everything left over lands on that one external target. Whether that creates takeover risk depends on how the platform binds customer hostnames. GitHub Pages warns against wildcard records for exactly this reason within its own model, and that warning shouldn’t be generalized to every wildcard everywhere.
Caching outlives the cleanup
Removing a dangling record from your zone doesn’t erase the copies resolvers already hold. A CNAME published with a 3600-second TTL can keep being served from a cache that picked it up seconds before deletion, and the same applies to cached NS delegations. Resolvers may also serve stale data past expiry when they can’t reach the authoritative servers.
That makes caching part of any decommissioning plan, and the order matters more than people expect. Deleting DNS first and the resource immediately after isn’t enough, because a resolver that cached the record just beforehand can keep using it for the full remaining TTL, and the resource may become claimable inside that window. The safer sequence is to lower the TTL in advance, remove the record, wait out the previously published TTL, and only then release the resource.
Finding them
A pass over your own zone data surfaces many dangling references quickly. For an alias, check both the alias and where it lands:
dig docs.example.com CNAME
dig docs.example.com A
dig old-project.hosting.example.net AFor a delegation, ask the parent’s authoritative server directly, since a recursive query may return the child’s own apex NS records or simply fail:
dig @<parent-authoritative-server> dev.example.com NS +norecurse
dig @ns-1.provider.example.net dev.example.com SOA +norecurseTest every delegated server, because partial and lame delegations produce resolver-dependent results.
A zone audit only covers names you publish. The Domain Dependency Mapper works from the other direction, scanning a page, resolving every third-party domain it loads, and flagging NXDOMAIN targets and dangling CNAMEs among them, which catches stale references that live in someone else’s DNS.
All of that establishes DNS state and stops there. The next question is administrative. Does the organization still own the referenced service, and could an unrelated account claim the missing resource or hostname binding? That provider-side check is exactly what a DNS-only scanner can’t infer, which is why takeover reports built purely on failed lookups both miss real exposure and invent plenty that isn’t there.
Summary
A dangling DNS record can remain valid-looking long after the resource behind it is gone. In some cases, that can let another party take control of the destination or even an entire delegated namespace.
Preventing that depends on keeping DNS changes tied to the lifecycle of the resources they reference. DNS itself will keep publishing whatever records remain in the zone.