Subdomain Takeover and Dangling DNS: How to Find and Fix Them

Every DNS record pointing at a service you no longer use is a liability. If an attacker can register that abandoned resource, they get to serve content on your domain, with your brand and often with valid HTTPS. After reading this guide you will understand how these takeovers happen, be able to audit your zones for dangling records, and have a cleanup process that stops them from reappearing.

How a takeover happens

A subdomain takeover needs two ingredients:

1. A DNS record in your zone that points to an external resource, such as a CNAME to a hosting platform, or an A record to a cloud IP address.
2. The external resource no longer exists under your control, but the name or address can be claimed by someone else.

The classic sequence:

1. You create shop.example.com as a CNAME to acme-shop.platform.example, a hosted storefront or static site.
2. Later, you cancel the account or delete the project. Nobody removes the DNS record.
3. The record now points to an unclaimed name on that platform.
4. An attacker creates a new account on the same platform and claims acme-shop (or adds your custom domain to their project). Requests to shop.example.com now reach their content.

Variants of the same theme:

• Dangling A records to released IPs. A cloud server or elastic IP is released, and the address is later allocated to someone else's instance. Exploiting this is harder because the attacker must get a specific address, but it is possible where address pools are small or allocation is repeated.
• Dangling NS delegations. A subdomain is delegated with NS records to a DNS service whose zone was deleted. If anyone can recreate that zone on the provider, they control all records under that subdomain. This is among the most severe variants because it gives full control of the subtree.
• Dangling MX and verification records. Mail routed to a decommissioned service can end up received by someone else, and stale verification TXT records can be reused to validate a domain.
• Expired domains in the chain. A CNAME to a domain you do not own that has since expired and can be registered by anyone.

What an attacker can do with it

Because the content is served from a hostname under your domain, the damage goes beyond a defaced page:

• Phishing under a trusted name, with a real-looking URL.
• Cookie theft or fixation: if your main application sets cookies scoped to .example.com, scripts on a hijacked subdomain may read or overwrite them.
• Bypassing allowlists: Content Security Policy rules, CORS configuration or OAuth redirect URIs that trust *.example.com will trust the attacker's content.
• Valid certificates: the attacker can often obtain a publicly trusted TLS certificate for the hijacked name through domain validation, since they control the content at that name.
• Reputation damage: search engine and spam-filter signals attached to your domain can be harmed.

Spotting a dangling record

Whether a record is exploitable depends on how the platform handles unclaimed names, which varies between providers and changes over time. In general terms, a record is suspicious when it meets these conditions:

• The target name returns NXDOMAIN, meaning the CNAME points nowhere.
• The target resolves, but the HTTP response is a generic "not found" or "no such site" page from the provider, rather than your own content. Many platforms show a recognisable message when a custom domain is configured to point to them but no project claims it.
• The target IP does not respond, or now belongs to a different organisation.
• The service referenced in the record (for example a storage bucket, a project, an app name) no longer exists in your account.

Providers publish different error messages, and they are updated, so do not rely on a stale list. The approach that stays valid: request the hostname over HTTP and HTTPS and compare the response with what you expect. A generic provider error, a parked page, or a default server page on a hostname you thought was retired is a red flag.

# Where does the name point?
dig CNAME shop.example.com +short
# acme-shop.platform.example.

# Does the target exist?
dig A acme-shop.platform.example +short
dig A acme-shop.platform.example | grep -i status    # NXDOMAIN?

# What does the web server say?
curl -sI https://shop.example.com/ | head -n 5
curl -s http://shop.example.com/ | head -n 20

Not every provider is vulnerable: some verify domain ownership before attaching a custom domain, which prevents simple takeover. Others have historically been claimable. Treat the answer as "unknown until checked" rather than assuming safety.

The Dangling DNS Checker tests subdomains for these signs, saving you from running the above by hand over hundreds of names.

Auditing your domain

1. Build a complete subdomain inventory

You cannot clean what you cannot see. Sources, from most to least authoritative:

• Your DNS zone export. Ask every DNS host you use for a full export or API listing. This is your ground truth for what you published. Remember that subdomains may be delegated to other zones.
• Certificate transparency logs. Public CAs log every issued certificate, so searching CT logs for %.example.com reveals hostnames that have had certificates, including ones you have forgotten or never knew about. It is excellent for discovering names that exist outside your zone listing, such as delegated subdomains or names managed by other teams. Note that wildcard certificates do not list individual names, so CT is an inventory aid, not a complete one.
• Subdomain discovery tools. The Subdomain Finder combines several passive sources.
• Historic DNS data. DNS History shows records that existed previously, which helps find stale entries and decommissioned services.
• Infrastructure and billing records. Cloud account inventories, SaaS invoices and SSO application lists reveal services that might still have DNS.

2. Classify each record

For every hostname, record the owner, the service, and the purpose. Then check:

• Does the target still exist and is it under your account?
• Is the content correct and current?
• Is the service still needed?

Use the DNS Checker to confirm what the name resolves to and the Website Hosting Checker to identify the provider behind it. The SSL Checker can reveal an unexpected certificate on a hostname, which is a sign someone else controls the endpoint.

3. Prioritise by risk

Fixing and responding

• Delete the DNS record. This is the immediate and complete fix for a dangling record. Do it before re-creating anything.
• If you still need the hostname, recreate the resource under your control first, and then restore the record.
• If someone has already taken it over, treat it as a security incident: remove the record, check for cookies scoped to the parent domain and rotate sessions where that matters, review CSP/CORS/OAuth allowlists, check logs for what the subdomain was used for, and consider whether credentials or tokens were exposed. Revoke any certificates issued to the attacker where the CA offers a process, and notify affected users if warranted. Our incident postmortem guide can help you record what happened and what you changed.

Preventing it for good

Most takeovers are process failures, not technical ones. The durable fixes:

1. Order of operations in decommissioning. Remove the DNS record first, then delete the cloud resource, project or account. When provisioning, do it in reverse: create the resource, verify ownership, then add DNS. Write this into your offboarding checklist.
2. Use ownership verification where the platform offers it. Many services let you prove control of a domain with a TXT record before attaching it. Use it. Avoid platforms that attach custom domains without verification for anything important.
3. Keep a DNS inventory with an owner per record, and a requirement that every new record names a responsible team and a purpose. Use comments or tags where your DNS host supports them.
4. Manage DNS as code. Keeping zones in version control means removals are reviewed and visible, and orphaned records show up in diffs.
5. Avoid wildcard DNS and broad trust. A wildcard CNAME to a third-party platform makes every undefined name claimable. Narrow CSP, CORS and OAuth allowlists to named hosts instead of *.example.com.
6. Scope cookies tightly. Host-only cookies on the application's own hostname limit what a hijacked sibling subdomain can read.
7. Release addresses and delegate carefully. Do not release cloud IPs that are still referenced, and never delegate a subdomain to a DNS provider zone you have not created and verified.
8. Monitor continuously. Schedule recurring scans, since new dangling records appear whenever someone deletes a project. Pair the Dangling DNS Checker with alerts from your uptime tooling when a hostname starts returning an unexpected status.
9. Watch certificate issuance. Certificate transparency monitoring can alert you when a certificate is issued for a hostname you did not request, which is an early warning of a takeover.

A cleanup policy you can adopt

A lightweight policy keeps the problem from returning:

• Every DNS record has an owner and a reason, recorded somewhere searchable.
• Quarterly review: export all zones, run the checks, and delete or reassign anything unexplained.
• Decommissioning checklist: DNS first, resources second, verification records last.
• Any project retired has a ticket that includes "DNS removed" as a closing criterion.
• New third-party services require ownership verification where available.
• Parked and unused domains publish no records that point at external services.

Next steps

• Scan a domain's subdomains with the Dangling DNS Checker and Subdomain Finder.
• Compare current and previous records with DNS History.
• Brush up on record behaviour in DNS explained for website owners.
• Review how certificates tie in with SSL/TLS certificate errors explained.

FAQ

Can a subdomain takeover happen if my main site is secure?

Yes. A takeover exploits a forgotten DNS record, not a flaw in your main application. However, the impact depends on how much your main site trusts sibling subdomains through cookies, CORS, CSP or OAuth settings.

Is a CNAME to a deleted service always exploitable?

No. It depends on whether the provider lets someone else claim that name or attach your domain without proving ownership. Some do verification and are not claimable, while others have been. Treat every such record as a risk until you remove it or confirm otherwise.

Does a wildcard certificate protect me?

Not against this. A wildcard certificate secures the connection but does not prevent someone else from serving content on a hostname you have abandoned. A wildcard certificate that you share across subdomains can also be a larger problem if its private key reaches a service you no longer control.

How often should I audit my DNS?

At least quarterly, and whenever you retire a service, change vendors or complete an acquisition. Automated scheduled scans are better than relying on memory, since records are created and forgotten continuously.

How does certificate transparency help?

CT logs list certificates issued for your domain, including for subdomains that are not in your own zone export. Searching them gives you a second inventory source and an alerting channel for certificates you did not request.

This page is general information written by our editorial team and updated when documentation changes. Servers and providers differ, so test changes safely first. See our editorial policy and disclaimer.