A subdomain takeover starts with a DNS record nobody remembered to delete. A marketing team spins up a landing page on a third party host, points promo.example.com at it with a CNAME, runs the campaign for six weeks, and tears the host down. The CNAME stays. Six months later a researcher notices that promo.example.com still resolves to a provider where the underlying resource no longer exists, claims that resource under their own account, and now controls whatever loads at your subdomain. This is not an exotic bug. It is the single most common finding in external attack surface reports, and it exists because DNS cleanup is nobody’s job by default.
How a Dangling Record Is Born: The Service Is Gone, the CNAME Stays
DNS and infrastructure lifecycles are decoupled by design, and that gap is where the vulnerability lives. Creating a subdomain touches two systems: the DNS zone, usually managed by a network or platform team, and the destination service, usually provisioned by a product or marketing team through a third party console. Decommissioning almost never touches both. A typical sequence looks like this:
- A team provisions a resource on a SaaS or PaaS platform (a static site host, a CDN endpoint, a support desk, a status page, a form builder).
- DNS is updated with a CNAME, and sometimes an A record pointing at a provider owned IP, so the subdomain resolves to that resource.
- The project ends. Someone deletes the S3 bucket, deprovisions the Heroku app, cancels the Zendesk trial, or lets the free tier expire.
- Nobody files a ticket against DNS, because the person closing the project does not have zone access, and the person with zone access was never told the resource existed.
The result is a CNAME that still points somewhere, but the somewhere no longer belongs to you. Cloud platforms make this worse because most of them use shared, multi tenant namespaces: an S3 bucket name, a GitHub Pages project, an Azure endpoint, or a Heroku app name is available to any customer the moment the previous owner releases it. Your DNS record becomes a pointer to a name slot that anyone can claim, and claiming it costs an attacker nothing more than a free tier signup.
The Anatomy of a Takeover: What an Attacker Actually Gains
Once an attacker claims the vacated resource and it starts answering for your subdomain, they inherit whatever trust your organization built into that hostname. The concrete impact depends on scope, but four categories show up repeatedly:
- Cookie and session abuse. Cookies scoped with a leading dot, such as
Domain=.example.com, are readable and writable from every subdomain. If your session cookie is scoped that broadly, a page served from the hijacked subdomain can read or set cookies that your main application later trusts. - SSO and OAuth redirect abuse. Redirect URI allowlists are frequently configured at the domain or wildcard level. A claimed subdomain that matches an approved redirect pattern lets an attacker complete an OAuth flow and receive tokens intended for your application.
- Phishing with a trusted host header. Security awareness training tells users to check the domain in the address bar. A credential harvesting page served from a legitimate subdomain of your company passes that check, and it also survives many secure email gateway domain reputation filters.
- Content Security Policy and CORS bypass. If your CSP or CORS configuration allowlists
*.example.com, a hijacked subdomain becomes a valid script source or a valid cross origin caller, which turns a DNS hygiene issue into a direct path around browser side defenses.
None of this requires a vulnerability in your application code. The application never gets a chance to defend itself, because the attacker is answering DNS queries with content you never approved, on infrastructure you have no visibility into.
Record Types That Get Hijacked: CNAME, NS Delegation, MX, and Leftover TXT Verification
Most write ups focus on CNAME records because they are the most common vector, but they are not the only one. Each record type carries a different blast radius.
| Record type | How it becomes exploitable | What the attacker gets |
|---|---|---|
| CNAME | Points to a deprovisioned PaaS or CDN resource whose name is available for re-registration | Full control of content served on that hostname |
| NS (delegation) | A subdomain’s zone is delegated to a third party DNS provider, then the hosted zone is deleted there while the NS records still point to it | Control of the entire delegated zone, including any record the attacker chooses to create under it |
| MX | Mail routing points to a decommissioned email or marketing platform whose domain claim can be re-registered | Ability to receive mail sent to that subdomain, including password reset links and internal notifications |
| TXT (verification) | Leftover SPF includes or domain verification strings reference a provider account you no longer control | Spoofed mail that passes SPF alignment, or fraudulent re-verification of domain ownership in a third party console |
NS delegation takeover deserves particular attention because it is under reported and more severe than a single CNAME. If legacy.example.com was delegated with NS records to a cloud DNS provider for a project that later shut down, and the hosted zone at that provider was deleted without also pulling the NS delegation from your parent zone, anyone can create a new hosted zone for that exact subdomain name at the same provider. Because DNS resolution follows the NS records, that new zone now has full authority to answer any query under legacy.example.com, including for hostnames you never created, such as vpn.legacy.example.com or mail.legacy.example.com.
Inventory Signals That Reveal a Dangling Record
Detection does not require exotic tooling, but it does require checking the right signal, not just whether a name resolves. A record that returns an answer is not the same as a record that is safe.
- Unresolved or orphaned target. Run
dig CNAME subdomain.example.comand then resolve the target the CNAME points to. If the target itself returns NXDOMAIN, or resolves to a generic parking page, that is the clearest signal. - Provider specific error fingerprints. A live HTTP response from the CNAME target that still returns a 200 or 404 is not automatically safe. Providers return distinctive body text for an unclaimed resource:
NoSuchBucketfor S3 static hosting, “There isn’t a GitHub Pages site here” for GitHub Pages, “project not found” for Heroku, “Fastly error: unknown domain” for Fastly. Any scanner that only checks status codes will miss these, because most of them return HTTP 404 with a body that says the name is free. - Certificate transparency drift. Query crt.sh or another CT log search for your apex domain and diff the result against your current DNS zone weekly. A subdomain that appears in issued certificates but no longer exists in your zone file, or resolves to infrastructure your inventory does not recognize, is worth investigating even if nothing looks obviously broken.
- Delegation without a matching owner record. Walk every NS record in your zones and confirm each delegated zone is still active at the named provider and still under an account your organization controls. A delegation with no corresponding entry in your cloud asset inventory is a candidate for the NS takeover pattern above.
The operational failure mode here is not a lack of scanning, it is scanning that stops at “does this resolve.” Attack surface management platforms, including SITEY, resolve every hostname in the inventory on a recurring schedule and match the response against a library of provider specific not claimed fingerprints, so a dangling CNAME surfaces as a finding automatically instead of depending on someone manually running dig against every subdomain in the zone file.
Cleanup Order: Delegation First, Then the Record, Then Certificate Revocation
Fixing a dangling record in the wrong order can leave a window open even after you think it is closed. Work through it in this sequence.
- Audit and correct delegation first. Before touching an individual record, confirm the parent zone’s NS delegations are all pointing to providers and accounts you currently control. If you find an NS delegation to a provider where the hosted zone is gone, either reclaim that hosted zone under your own account immediately or remove the NS delegation from the parent zone. Fixing the leaf record while a stale delegation still exists upstream does not help, because the delegated provider still has full authority over that namespace.
- Remove or repoint the dangling record itself. Delete the CNAME, A, or MX record, or repoint it to a resource you currently control. Do not leave it pointing at a “temporary” placeholder on the same third party platform; that placeholder is subject to the identical reclaim risk.
- Revoke and reissue affected certificates. Any TLS certificate whose SAN list included the retired subdomain should be revoked through your CA, not just left to expire. CT logs are permanent, so the fact that the name was once certified for a hostname you controlled is public forever. Revocation limits how long a previously valid certificate could be replayed or trusted by a misconfigured client, and it forces a clean reissue tied to your current infrastructure.
Skipping straight to step two is the most common mistake, because it is the most visible symptom. But an attacker who already holds the delegated zone from step one does not need your CNAME at all; they can create their own records under the entire delegated namespace.
A Decommission Checklist That Stops the Cycle Repeating
Cleaning up one dangling record fixes one finding. Making decommissioning a required step, not an afterthought, fixes the recurrence. A practical checklist:
- DNS record removal is a blocking line item on the service decommission ticket, not a follow up task assigned after the resource is already deleted.
- Ephemeral environments (review apps, feature branch previews, staging instances tied to a pull request) get their DNS record removed by the same automation that tears down the underlying infrastructure, not by a separate manual step someone might skip.
- Every team that can create a subdomain must also be able to, and be required to, delete it. If provisioning a subdomain requires a ticket to the network team but decommissioning does not, the asymmetry guarantees drift over time.
- A weekly automated sweep resolves every record in every zone the organization owns and flags anything matching a known “unclaimed” fingerprint, an NXDOMAIN target, or a delegation with no active owner.
- Certificate transparency monitoring runs continuously against the organization’s registered domains, not just at renewal time, so a reissued certificate for a subdomain nobody currently manages gets caught within hours instead of being found by an outside researcher.
- Every subdomain in the inventory has an assigned owner and a review date. A record with no named owner after a defined grace period, for example ninety days, gets flagged for removal rather than left in place indefinitely.
The pattern that keeps this problem alive is treating DNS hygiene as a one time cleanup project instead of a standing control. Platforms that automate this phase, such as SITEY, re-test the specific finding after a ticket is marked resolved, confirming the CNAME chain no longer points to an unclaimed resource and the certificate has actually been revoked, instead of trusting that the assigned engineer’s status update matches reality. That closing step matters because a dangling record fixed on paper but not verified in DNS is exactly the gap a bug bounty report or a red team engagement will find next.
Subdomain takeover will keep showing up in external assessments for as long as provisioning and decommissioning stay disconnected processes. The fix is not a smarter scanner alone, though continuous attack surface management that resolves every hostname and matches provider fingerprints on a schedule closes the detection gap. The fix is also organizational: a current asset inventory that ties every subdomain to an owner, a decommission process where DNS removal blocks resource deletion rather than following it, and recurring scan management that runs the DNS sweep on a cadence instead of only after an incident. Get the sequence right, delegation, then record, then certificate, and the finding closes for good instead of reappearing under a slightly different hostname next quarter.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.