Subdomain takeover: the dangling DNS record

Someone deletes a Heroku app, an S3 bucket or a SaaS trial account. The DNS record that pointed at it stays. For a while nothing happens: the name resolves to a provider that returns a 404, and a monitoring check that only looks for HTTP 200 has nothing to say about it. Then someone registers that provider resource name, and the 404 becomes their content, served from your domain, over a valid certificate.

What makes a record dangling

Three shapes account for almost all of it.

CNAME to a deprovisioned resource. docs.example.com points at example-docs.s3.amazonaws.com, myapp.herokuapp.com, org.github.io, site.azurewebsites.net, or a custom-domain slot on a SaaS product. The resource is deleted; the name becomes available again; the provider hands it to whoever asks next.

A record to a released IP. An elastic or floating IP is returned to the provider pool while the A record still points at it. The next tenant to allocate from that pool receives your traffic. This one is less reliably exploitable but needs no takeover step at all.

NS delegation to a zone nobody owns. A subdomain delegated to a nameserver on an account that has been closed. This is the worst case: the attacker controls the entire subtree, not one host, including its TXT and MX records.

The tell is consistent — the record resolves fine, and the thing at the other end does not exist any more.

Why it is worse than a defacement

A page on a subdomain you forgot about sounds cosmetic. The damage comes from everything else that trusts the parent domain.

• Cookies. Anything scoped to .example.com is sent to every subdomain, including the taken one. Session cookies without a host-only scope leak directly.
• OAuth and SSO redirects. Allowlists written as *.example.com accept a redirect to the attacker's subdomain, which turns an authorisation code into their authorisation code.
• Content Security Policy. A policy permitting *.example.com for scripts now permits theirs, on your real pages.
• Certificates. HTTP validation runs against whatever answers on the name, so the attacker gets a publicly trusted certificate for a name on your domain.
• Email and phishing. A phishing page on a genuine corporate subdomain passes every check a careful reader performs, and an inherited SPF include: or a takeover of a delegated zone extends it to mail.

None of that requires touching your production infrastructure.

Finding them before somebody else does

The work is enumeration plus resolution, and both halves are needed. Your zone file is where you start, not where you finish — records get added through different consoles by different teams, and certificate transparency logs will show names that no one remembers requesting. Pull the full list of names, then resolve each one and look at what actually answers:

• A CNAME whose target does not resolve at all is the clearest signal.
• A CNAME that resolves to a provider returning a known unclaimed-resource page — "There isn't a GitHub Pages site here", the S3 NoSuchBucket error, a Heroku no-such-app page — is the same finding with an extra hop.
• A name pointing into an IP range belonging to a cloud provider you no longer use is worth checking by hand.

This is exactly the gap between the inventory and the reality described in what counts as your external attack surface: the record is in DNS, which means it is yours, whether or not it is on anybody's asset list.

Fixing and preventing

Remediation is one action: delete the record. Reclaiming the provider resource to hold the name works too, but it leaves you paying for something to stop a problem that deleting a line solves permanently.

Prevention is an ordering rule in your decommissioning process, and it is worth writing down because the intuitive order is the wrong one. Remove the DNS record first, then delete the resource. Done that way there is never a moment where a live name points at an unclaimed target. Done the other way, the window between the two steps is the vulnerability, and if the second step never happens the window is permanent.

CyberSpec scans the assets you register — domains, IPs and CIDR ranges — and tracks findings across repeated scans with first-seen and last-seen dates, so a host that appears on a subdomain nobody expected shows up as new rather than blending into the existing list. Ownership verification runs by DNS TXT record or a well-known file before any scan starts. See network scanning.

The useful question is not whether you have dangling records. It is when anyone last enumerated the zone and resolved every name in it.