A subdomain takeover happens when one of your DNS records still points at an external service that you no longer own. The classic case is a CNAME aimed at a cloud host, a storage bucket, or a SaaS endpoint that has been deleted. The DNS record survives the teardown, the target becomes claimable again, and an attacker registers that same resource on the provider. From that moment they control content served on your subdomain, complete with a valid TLS certificate, because to the outside world the traffic really is arriving at your name. This is a record-level compromise of one orphaned hostname, which is different from a registrar-level hijack of an entire domain.
How a dangling record becomes a takeover
The pattern is consistent across providers. Consider a marketing team that spins up a landing page:
promo.example.com. 3600 IN CNAME example-promo.hostingprovider.net.Months later the campaign ends and someone deletes the hosting project. The CNAME in the zone is forgotten. Now promo.example.com resolves through the CNAME to example-promo.hostingprovider.net, which returns a provider error page saying the resource is unclaimed. An attacker who understands this creates a new project on the same provider and claims the exact target name example-promo.hostingprovider.net. The dangling CNAME now delivers the attacker's content under your subdomain.
Why this matters more than a random phishing page:
- It carries your reputation. Visitors see a real subdomain of a trusted brand, and links, bookmarks, and search results still point there.
- It can obtain a valid certificate. Because the attacker controls what the name serves, they can pass domain-validation checks and get a legitimate certificate, so the browser shows a padlock.
- It can steal cookies and tokens. Cookies scoped to the parent domain, and OAuth or SSO flows that trust any subdomain, may be exposed to the attacker's page.
Any record whose value resolves to a claimable third-party resource is a candidate: CNAME and ALIAS records are the usual culprits, but a dangling NS delegation or an A record pointing at a released cloud IP can be abused the same way.
Detecting dangling DNS
Detection is about proving that every external target still belongs to you. Three techniques cover most of the ground.
Audit every CNAME and ALIAS target
Enumerate your zone and resolve each record's target, then check what the target actually returns. A dangling target typically shows one of these signals:
- An
NXDOMAINfor the target hostname, meaning it no longer exists. - A provider-specific "no such app," "bucket not found," or "domain not configured" error page.
- An HTTP fingerprint that matches a known unclaimed-resource response for that provider.
You can start manually with dig. Resolve the chain and inspect the endpoint:
dig promo.example.com CNAME +short
example-promo.hostingprovider.net.
dig example-promo.hostingprovider.net A +short
;; (empty answer, or an address that returns a provider error page)An empty answer or a fingerprinted error page on a target you no longer manage is the warning sign. Community fingerprint lists exist for many providers and are what automated scanners use under the hood.
Watch Certificate Transparency logs
Every publicly trusted certificate is logged in Certificate Transparency (CT) logs. That gives you two things. First, CT logs are a near-complete inventory of subdomains that have ever had a certificate, including old projects, former employee experiments, and staging hosts that were never documented. Query a CT search service for %.example.com and you will often find names you forgot existed, which are exactly the ones most likely to dangle. Second, monitoring CT for new certificates on your names can reveal a takeover in progress, because an attacker who claims your subdomain will usually trigger issuance of a fresh certificate you did not request.
Scan continuously, not once a year
A dangling record can appear the day any service is decommissioned, so an annual audit leaves a window that can stay open for months. Run detection on a schedule, ideally tied to your change process, and re-scan whenever a cloud resource, SaaS integration, or hosting project is removed. Continuous checking turns takeover from a latent risk into a short-lived, quickly caught mistake.
Preventing takeover with the correct decommission order
Almost every takeover traces back to the same mistake: the cloud resource was deleted before the DNS record was removed. That ordering opens the exact window an attacker needs. The fix is to reverse it. The DNS record must go first, and only after it is gone and cached copies have expired should the underlying resource be released.
Why deleting the resource first opens the window
The instant you delete the target resource, its name becomes claimable on the provider while your DNS record still points to it. Between that deletion and the moment someone finally cleans up the record, anyone can grab the target. On a busy provider that gap can be exploited within minutes. Keeping the record until last means there is never a moment when your live DNS points to a resource somebody else can claim.
Safe-teardown checklist
- Remove or repoint the DNS record first. Delete the CNAME, ALIAS, or A record, or repoint it to a name you fully control.
- Wait out the TTL. Give resolvers time to drop the cached record. If the record used a long TTL, wait at least that long. Lowering the TTL a day ahead of a planned teardown makes this step quick.
- Verify the record is gone everywhere. Confirm with
dig promo.example.com CNAME +shortagainst your authoritative nameserver and a public resolver such as 1.1.1.1. An empty answer from both means the record is clear. - Only now release the cloud resource. Delete the bucket, app, or project. With no DNS pointing at it, a reclaim by anyone else is harmless.
- Record the change. Log the removal so the subdomain-to-service inventory stays accurate.
Bake this order into your runbooks. Tie service cancellation to DNS cleanup in your change-management process, keep an inventory that maps each subdomain to the service behind it, and make "remove the DNS entry first" a written rule rather than tribal knowledge. The OWASP guidance on this topic reaches the same conclusion: eliminate the dangling reference before the resource is freed.
What to do if a subdomain is already taken over
- Remove the offending DNS record immediately so your name stops resolving to the attacker.
- Revoke trust. Rotate any cookies, session secrets, or OAuth client settings that trusted the subdomain, and review SSO configurations that treat subdomains as trusted origins.
- Check certificates. Look in CT logs for certificates issued for the name during the exposure and revoke any you can.
- Find the root cause. Identify the decommission that skipped DNS cleanup and fix the process so it cannot recur.
Frequently asked questions
Is a subdomain takeover the same as domain hijacking?
No. Domain hijacking is an attacker gaining control of your registrar account or the whole domain. A subdomain takeover is narrower: one orphaned subdomain whose DNS record points to a reclaimable third-party service. The fix is at the record level, not the registrar level.
Which record types are vulnerable?
Most commonly CNAME and ALIAS records pointing at external providers. Dangling NS delegations and A records aimed at released cloud IP addresses can be abused in the same way.
Can an attacker really get a valid certificate for my subdomain?
Yes. Once they control what the subdomain serves, they can pass domain-validation checks and obtain a legitimate certificate, so the browser shows no warning. That is what makes these attacks convincing.
How often should I scan for dangling records?
Continuously, or at minimum after every decommission. Annual audits leave a long window during which an orphaned record can be claimed.
What is the single most effective prevention?
Always remove the DNS record before releasing the resource it points to, and confirm the record is gone before you delete anything on the provider side.
Dangling DNS is a cleanup problem, and cleanup problems are solved by visibility and discipline. Keep an accurate inventory of what each record points at, remove records before you free the resources behind them, and re-check on a schedule. If you want one place to review every CNAME target, manage TTLs ahead of a teardown, and keep your records tidy, you can manage your DNS with Valla DNS.