What Is a Subdomain Takeover and How to Prevent It
You cancel a cloud service but leave the DNS record pointing at it. Someone else claims that service name and now controls a subdomain of your domain, with a valid certificate and your cookies.
September 21, 20267 min readSecurity · DNS · Subdomains
The short answer. A subdomain takeover happens when a DNS record still points at a cloud service you no longer use. Anyone who claims that service name inherits your subdomain, complete with a valid certificate. The fix is a rule rather than a tool: when you decommission a service, delete the DNS record in the same change.
How it happens
The sequence is mundane, which is why it is common.
- You set up a service on a subdomain. Say docs.example.com, pointing via CNAME at a hosted documentation platform.
- A year later the team moves to something else and cancels the account.
- Nobody removes the CNAME. It is one line in a DNS zone nobody reviews.
- The platform releases the project name back to its pool.
- Someone signs up and claims that name.
- Your CNAME now resolves to their content.
Nothing was hacked. You published a signpost to an address, then stopped renting the building, and someone else moved in while your signpost stayed up.
The same pattern applies to NS records delegating a subdomain to a DNS provider you stopped paying, and to A records pointing at cloud IPs that have been released back into a shared pool.
Why it is worse than it looks
A takeover on a subdomain of your domain is not equivalent to a stranger's website. The domain is doing work for the attacker.
Cookies. Cookies scoped to the parent domain are sent to every subdomain. If your application sets cookies on .example.com, a subdomain under someone else's control can read them. That can include session tokens.
Certificates. The attacker controls the subdomain, so they can obtain a publicly trusted certificate for it in minutes. Visitors see a valid padlock on a hostname under your brand.
Phishing that passes every check. A login page on a genuine subdomain of your real domain defeats every instinct users are taught. The domain is correct, the certificate is valid, the padlock is present.
Trust bypasses. Allowlists, CORS policies, OAuth redirect URIs and content security policies frequently trust entire domains by suffix. A controlled subdomain can inherit all of it.
Reputation. Content published under your brand, indexed under your domain.
Where dangling records come from
Retired marketing campaigns. Landing pages on hosted builders, launched fast and forgotten.
Documentation and status pages. Moved between providers over the years, old records left behind.
Staging and preview environments. Created per branch, pointed at hosting, deleted from the host but not from DNS.
Storage buckets. A subdomain pointed at object storage, the bucket deleted, the name reclaimable.
Acquisitions and team changes. The person who created the record left, and nobody knows what it was for, so it stays out of caution. That caution is the vulnerability.
The shared cause is that creating a DNS record and provisioning a service are two actions, while decommissioning is usually only one.
Finding yours
Enumerate your DNS records. Export the full zone for every domain you own, including the ones nobody thinks about. You cannot audit records you have not listed.
Check certificate transparency logs. Every publicly trusted certificate is logged, so CT searches reveal subdomains you have forgotten, including ones created by teams who never told you.
Resolve everything and look at the answers. For each record, what does it actually point at now? The signature of a dangling record is a CNAME resolving to a provider hostname that returns a generic error page, a not-found message, or a prompt to claim the name.
Pay closest attention to NS records. A delegated subdomain at a provider you no longer pay is a full DNS takeover rather than a single hostname, and it is the worst version of this.
Include your parked and defensive domains. They get the least attention and often have the oldest records.
Our Domain Hub stores DNS snapshots and raises events when records change, which catches the related problem of records being altered. The dangling case needs the audit above, because nothing changes at the moment it becomes exploitable, which is exactly what makes it hard to notice.
Preventing it
Delete DNS records as part of decommissioning. The single rule that solves this. Cancelling a service and removing its DNS record are one task, not two. Write it into whatever checklist governs shutting things down.
Prefer records that fail closed. Pointing at infrastructure you control, which then proxies, means losing the upstream produces your error page rather than someone else's opportunity.
Use CAA records. A CAA record limits which certificate authorities may issue for your domain. It does not prevent a takeover, but it narrows how easily an attacker obtains a trusted certificate.
Do not scope sensitive cookies to the parent domain. If cookies are set on example.com rather than www.example.com, every subdomain can read them. Scope them as narrowly as the application allows.
Audit DNS on a schedule. Quarterly is enough for most organisations. Our portfolio audit checklist includes it alongside the rest of the review.
Treat subdomains as part of your attack surface. They usually are not, because they are created by whoever needed one and owned by nobody thereafter.
If you find one
Reclaim the name first if you can. If the service still has the project name unclaimed, claim it yourself immediately. That removes the exposure while you clean up.
Otherwise delete the DNS record. Removing the record ends the takeover immediately, whatever the attacker has set up on the far side.
Then check what trusted it. Search for the hostname in OAuth redirect URIs, CORS allowlists, CSP directives, firewall rules and internal documentation. The record was removed, but the trust it accumulated may still be configured somewhere.
Rotate anything it could have seen. If parent-domain cookies were in scope, treat sessions as potentially exposed.
Common questions
What is a subdomain takeover?
It is when an attacker gains control of a subdomain because its DNS record still points at a third-party service that has been decommissioned, allowing them to claim that service name and serve their own content from your subdomain.
What is a dangling DNS record?
A DNS record pointing at a resource that no longer exists or is no longer yours, most often a CNAME aimed at a cancelled cloud service, or an NS record delegating to a provider you stopped using.
How do attackers find vulnerable subdomains?
They enumerate subdomains at scale using certificate transparency logs and DNS data, resolve them, and look for responses indicating an unclaimed service name. It is automated and continuous rather than targeted.
Can a subdomain takeover get a valid SSL certificate?
Yes. Control of the subdomain is all that domain validation requires, so an attacker can obtain a publicly trusted certificate within minutes and present a valid padlock on your hostname.
How do I prevent subdomain takeovers?
Delete DNS records when you decommission the service they point at, audit your zones periodically against certificate transparency logs, and avoid scoping sensitive cookies to the parent domain.
Does DNSSEC prevent subdomain takeover?
No. DNSSEC proves a DNS answer is authentic. A dangling record is an authentic answer pointing somewhere you no longer control, so it validates perfectly.
Put the research to work.
Check your shortlist across the extensions that matter, then save the strongest names to a project.
Check a domain