Subdomain Takeover: How Dangling DNS Records Make Retired Entries Dangerous

Answer First

Definition: Subdomain takeover is a security attack in which an attacker gains control of the content served on one of your subdomains because its DNS record still points at a destination you no longer control. The record — usually a CNAME — survives after the destination is deprovisioned: a retired SaaS host, a deleted cloud bucket, a canceled app. The attacker claims that abandoned destination at the provider, and traffic to your subdomain starts resolving to attacker-controlled content.

Why: because the last step of an entry’s lifecycle is the easiest to skip. An entry can be archived, its status flipped to retired, the hosting plan canceled — but the DNS record lives at your DNS provider and keeps resolving silently. Nothing about the record changes when the destination disappears, and a DNS record carries no status or owner — no “destination gone” flag. Attackers scan for exactly this state. OWASP documents it as a standard test (WSTG-CONF-10), and it is a staple of bug-bounty disclosures — a dangling record is not a theoretical risk.

Example: A marketing team runs a campaign subdomain that forwards to a landing page hosted on a third-party page builder. The campaign ends; the team marks the entry retired in the Console, cancels the plan, and moves on. But the CNAME record still points at the vendor’s endpoint. The vendor recycles that endpoint name, an attacker registers it, and the subdomain — still in old ads and emails — starts serving the attacker’s content.

Key Facts

• A takeover needs three conditions: a DNS record that still resolves, a destination that has been deprovisioned, and a provider that hands that destination to whoever claims it next.
• The vulnerable state is often the residue of a completed retirement: the entry work was done, the DNS cleanup was not.
• Providers only serve content on a custom hostname when the resource exists and is claimed. The moment a destination is deprovisioned, it becomes claimable by anyone — “abandoned” and “dangerous” are the same state.
• OWASP’s Web Security Testing Guide (WSTG-CONF-10) covers the attack and its detection; the HackerOne bug-bounty guide treats subdomain takeover as a widely reported vulnerability class.
• The impact goes beyond embarrassment: attacker content on a brand subdomain enables phishing, credential and session-cookie theft, malware, and abuse of user trust.

Expert Explanation

The attack chain. Trace one vulnerable subdomain end to end and the attack is a five-step chain, every step mundane:

1. Creation. Your team stands up a subdomain (offers.example.com) and points it at a destination — a SaaS landing page, a bucket, a hosted app — usually via a CNAME.
2. Deprovisioning. Later, the entry is retired. The destination is canceled or deleted. The DNS record is not.
3. Discovery. The attacker enumerates subdomains, resolves each, and looks for a target that answers with a provider error: a “NoSuchBucket” response, a “no site here” page, an account-not-found screen. These fingerprints are cataloged and automated.
4. Claiming. The attacker registers or recreates the abandoned destination — the same bucket name, the same app name — and proves control.
5. Serving. The provider starts serving the attacker’s content on your subdomain: users’ browsers resolve your hostname, send an HTTP request to whatever server it points at (RFC 9110 defines how requests target an origin server), and receive attacker content.

No system of yours was compromised — the chain runs entirely on configuration left behind.

Where the entry lifecycle breaks. An entry has four stages: creation, active use, retirement, and decommission. The failure mode behind “old CNAMEs are risk” is that the first three stages are well supported — teams create entries, monitor them, and mark them done — while the fourth stage, actually removing the record from the DNS zone, is where discipline collapses. It shows up in two recurring places: entries retired after a campaign or acquisition, and entries whose destination changed mid-flight. Both leave subdomains whose records outlive their purpose. A workflow that treats “mark the entry” as the finish line produces dangling records; our acquisition entry-consolidation playbook covers the same problem at larger scale.

How to detect dangling records. Detection is a comparison between two sources of truth: what you believe should exist and what DNS actually says.

• Check what each entry’s DNS actually resolves to. For every entry, resolve the subdomain from outside your network (using a public resolver or dig) and follow the CNAME chain to its final target — write down the target, not the friendly label. Most teams find dangling records by doing this once, on purpose.
• Watch for destinations that go dark. Fetch the subdomain with a plain HTTP request: a live destination returns your content or a redirect (the 301 vs 302 choice is a separate decision); a deprovisioned one returns a provider error page — the exact fingerprints attackers use. A subdomain that started erroring after a destination change needs a decision, not a shrug (we covered it).
• Correlate status against DNS. Every retired or archived entry should have no live record pointing at an external destination — if the status says retired but the record still resolves, it is dangling by definition.
• Make the audit repeatable. Your entry list is available through the Console and the OpenAPI, so the check can be scripted and scheduled, and the status/change trail doubles as audit documentation.

Why retirement workflows are the prevention. The attack is prevented at the lifecycle level, not the provider level. Three habits close the gap:

1. Mark entries with status. Retired, archived, active — an entry without status is an entry nobody can reason about.
2. Record the destination. At creation time, store where the subdomain points. At retirement time, it tells you which DNS record to remove and which provider account to cancel — without it, cleanup starts with archaeology.
3. Confirm DNS cleanup after decommission. Once the destination is gone, re-resolve the subdomain until it no longer points at the old target, or until it has been deliberately repointed. Do the same after acquisitions and migrations.

This is the same discipline as the evidence trail we describe for compliance audits: what gets recorded, reviewed, and confirmed is what gets done.

Decision Framework

Treat a subdomain as at risk when all three are true: its DNS record still resolves; its destination is no longer under your control; and the provider would serve content to a new claimant. If any one is false, the subdomain is not currently takeover-able — which is why the fix is a workflow, not a panic.

Retirement checklist — run it for every entry you decommission:

• Set the entry’s status to retired/archived before touching anything else
• Record the destination (hostname, provider, account, record type) in the entry notes
• Cancel or delete the destination at the provider
• Remove or repoint the DNS record at your DNS provider
• Wait out the record TTL, then re-resolve to confirm it no longer points at the old target
• Add the subdomain to the next scheduled DNS audit

Practical limits. Resolution checks are point-in-time snapshots: DNS state changes between audits and cached resolvers lag after a deletion, so verification should wait out TTLs. Error-page fingerprints are heuristic — some providers return responses that look like other providers’ errors, so expect false positives and negatives and confirm manually. The records live at your DNS provider or registrar: entry-management tooling can track, document, and verify, but only someone with DNS access can delete them. And no audit catches an attacker who claims a destination minutes after you deprovision it — speed at retirement time is the actual defense.

Key Takeaways

• A subdomain takeover happens when DNS still points at a destination that no longer belongs to you — a configuration failure, not a breach of your systems.
• The vulnerable record is usually the leftover of a completed retirement: the entry was archived, the DNS record was not.
• Detect it by checking what each entry’s DNS resolves to and by watching for provider error pages when destinations go dark.
• Prevent it with a retirement workflow: mark status, record the destination, confirm DNS cleanup after decommission.

FAQ

Q: What is a subdomain takeover, in plain terms? A: An attack where a DNS record for your subdomain still points at a service you abandoned — a canceled SaaS host, a deleted bucket, a deprovisioned app. The attacker claims that destination at the provider, which then serves the attacker’s content on your subdomain.

Q: How do I check whether one of my subdomains has a dangling record? A: Resolve the subdomain from outside your network and follow the record to its final target, then request that target over HTTP. If the response is a provider error page — a “NoSuchBucket” response or a “no site here” page — the destination is unclaimed and the record is dangling. Cross-check against your entry list: any retired entry whose subdomain still resolves is a candidate.

Q: Why isn’t deleting the old forwarding entry enough? A: Because the forwarding entry and the DNS record are two different things in two different systems. Archiving the entry changes nothing at your DNS provider: the record keeps resolving until someone removes it. Entry management tells you what should exist; DNS is what actually exists.

Q: What are the practical limits of these checks? A: Resolution checks are point-in-time snapshots, so state can change between audits. Fingerprints produce false positives and negatives, so confirm manually. DNS caching means deletions take time to propagate. And only someone with access to your DNS provider can delete a record — tooling tracks and verifies, but the deletion is on the DNS admin.

Sources

• OWASP Web Security Testing Guide — WSTG-CONF-10, “Test for Subdomain Takeover”: https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/02-Configuration_and_Deployment_Management_Testing/10-Test_for_Subdomain_Takeover
• HackerOne — “A Guide to Subdomain Takeovers”: https://www.hackerone.com/blog/Guide-Subdomain-Takeovers
• RFC 9110, HTTP Semantics (IETF): https://www.rfc-editor.org/rfc/rfc9110
• MDN Web Docs — Redirections in HTTP: https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
• Amazon Web Services — “Tutorial: Configuring a static website using a custom domain”: https://docs.aws.amazon.com/AmazonS3/latest/userguide/website-hosting-custom-domain-walkthrough.html