A dangling DNS record is one that points somewhere that no longer exists. Someone spun up a cloud resource, created a CNAME to it, and later deleted the resource without deleting the record. The name still resolves. What it resolves to is now available for anyone to claim.
Silent Push's counts give a sense of how common that is:
| Record type | Dangling worldwide |
|---|---|
| CNAME | 2.7 million |
| NS | 300,000+ |
| MX | 3.9 million (less readily taken over) |
Roughly three million records that are, in their phrasing, ripe for the picking.
The number that makes it concrete
Aggregate figures are easy to skim past. This one is not.
Across 12,500 apex domains, Silent Push isolated 16,000 dangling subdomains and automated the takeover of 4,000 of them.
Automated. Not "identified as theoretically vulnerable" — actually claimed, by a script, at a rate of roughly one subdomain successfully taken over for every three apex domains examined.
A further 7,000 required additional steps to determine whether they met the conditions for takeover. On review, 5,000 of those were safe, because the cloud provider had safeguards in place preventing a stranger from claiming a previously-used name.
That provider-side detail is worth holding on to: whether an abandoned record is exploitable depends heavily on which service it pointed at, and some providers have closed this off while others have not.
Why the real risk is cookies, not defacement
The obvious harm is the boring one: an attacker serves phishing or malware from a hostname that genuinely belongs to your organisation, with your name in the URL and, depending on setup, a valid certificate.
That is bad. It is not the worst case.
The worst case is session cookies. Cookies are frequently scoped to a parent domain rather than a single host, which means a cookie set for example.com is sent to anything.example.com — including a subdomain an attacker now controls.
Silent Push's framing is that compromised session cookies can let an adversary use hashed credentials stored in cookies to authenticate as a user, with exposure potentially reaching company-wide SSO.
Follow that through. The attacker did not phish anyone, did not exploit a vulnerability in your application, and did not need to touch your infrastructure. They claimed a name you abandoned, and the browser handed them a session on the way past.
The other consequences on the list — cross-site scripting, email spoofing, traffic redirection — are all real, and all secondary to that one.
Why this keeps happening
Dangling records are not a failure of skill. They are a failure of sequence.
Creating a DNS record and creating a cloud resource are two actions in two systems, usually with two owners. Deleting the resource is a single action, and it is the one that gets taken when a project ends, a campaign finishes, or an experiment is abandoned. Deleting the record is a separate action, in a separate console, that nothing forces and nobody is reminded about.
The asymmetry is structural: creation is deliberate, deletion is partial. And the resulting record is invisible in normal operation, because nothing points to it and nobody visits it. It sits there resolving quietly for years.
Marketing campaign subdomains, staging environments, retired products, acquisitions whose DNS was never fully reconciled — that is where the three million live.
What to do
- Enumerate your own DNS, not your website. The exposure is in records nothing links to. An attack-surface exercise that starts from your homepage will not find them.
- Look for CNAMEs pointing at cloud services, then verify each target still exists and still belongs to you. That is the specific check.
- Scope cookies to hosts where you can. If a session cookie does not need to be valid across every subdomain, the takeover of one becomes an inconvenience rather than an authentication bypass.
- Make record deletion part of decommissioning. The reason these accumulate is that nothing in the teardown checklist mentions DNS. Adding one line is the whole fix, prospectively.
- Check what your providers do. Five thousand of the seven thousand ambiguous cases were safe because the provider prevented reclaiming a used name. That is worth knowing per-service rather than assuming either way.
The framing worth keeping
Most attack-surface work asks what is exposed. This asks something narrower and more awkward: what did we point at, and is it still ours?
Those are different questions, and only the second one finds a subdomain that has been quietly resolving to somebody else's server since a project ended three years ago.
