Subdomain takeover: how a forgotten DNS record becomes someone else's website

A subdomain takeover happens when a DNS record on your domain still points to an external service you no longer use. If that service lets anyone claim the name you left behind, a stranger can register it and start serving their own content on promo.yourcompany.com. Visitors see your domain in the address bar, so they have no reason to doubt the page.

The root cause is almost always the same: a record called a "dangling DNS" entry. Someone launched a campaign site, a help center or a test app on a cloud platform, pointed a subdomain at it, and later deleted the app but not the DNS record. Microsoft describes exactly this sequence for Azure, and the same pattern applies to many hosting, storage and SaaS platforms.

The good news: this is a bookkeeping problem, and you can check for it yourself with a few DNS lookups.

How a dangling record turns into a takeover

The usual life of the problem has 3 steps:

1. Creation. A team creates yourcompany-promo.azurewebsites.net (or a bucket, a Pages site, a CDN endpoint) and adds a CNAME so that promo.yourcompany.com points to it.
2. Deprovisioning. The campaign ends, the app is deleted, but nobody removes the CNAME. The subdomain now points to a name that no longer belongs to you.
3. Takeover. Someone notices the dangling name, creates a resource with the same name on the same platform, and from that moment controls what promo.yourcompany.com shows.

Not every platform allows the last step. The community project can-i-take-over-xyz keeps a list of services, marks which ones are vulnerable, and records the error text each one shows for an unclaimed name, for example "The specified bucket does not exist" for Amazon S3.

Why it matters more than a defaced page

A taken-over subdomain is not just an embarrassing page. According to Microsoft's guidance, the risks include:

• Cookie theft. Many web apps scope session cookies to *.yourcompany.com, so any subdomain can read them.
• A valid certificate for the attacker. Whoever controls the subdomain can obtain a TLS certificate for it, so the padlock appears too.
• Convincing phishing. A login page on your real domain is far harder to spot than one on a lookalike domain.
• Mail interception. A dangling MX record can let someone receive mail sent to that subdomain.

The OWASP Web Security Testing Guide adds the most serious variant: an NS record that delegates a subdomain to nameservers on a domain that is no longer registered. Whoever registers that domain controls the whole delegated zone.

How to check your own DNS

Start with a list of every subdomain you have. Your DNS provider's zone export is the best source. Certificate history is a useful second source, because almost every certificate issued for your names is recorded in Certificate Transparency logs.

For each subdomain, look at where it points:

dig +short CNAME promo.yourcompany.com
dig +short NS dev.yourcompany.com
dig +short MX shop.yourcompany.com

Then check that each target still exists and still belongs to you:

dig promo.yourcompany.com
curl -sI https://promo.yourcompany.com

Warning signs:

• the CNAME target returns NXDOMAIN (the name no longer exists),
• the page shows a platform error such as "No such app", "Repository not found" or "There isn't a GitHub Pages site here",
• an NS record points to nameservers on a domain you do not recognize or that has expired,
• nobody in the company can say what the subdomain was for.

Only test names on your own domain. Do not try to claim a resource to "prove" the issue; removing the record is enough.

How to fix it

1. Delete the dangling record from your DNS zone. This is the fix in both the Microsoft and OWASP guidance.
2. If the subdomain is still needed, recreate the resource under your own account before you point traffic at it again.
3. Check whether anything happened while the record was dangling: unusual certificates for that name, links in your app or emails that still use it, OAuth redirect URLs that include it.
4. Use ownership verification where the platform offers it. Azure App Service, for example, supports an asuid.<subdomain> TXT record so that no other subscription can validate the custom domain.
5. Fix the process, not just the record. Add "remove the DNS entry" to the checklist for shutting down any service, and keep a simple inventory of which subdomain points to which platform and who owns it.

A short checklist

• Export your DNS zone and list every CNAME, NS and MX record.
• For each one, confirm the target exists and belongs to your company.
• Remove records for services that were shut down.
• Compare your zone with the names in Certificate Transparency logs to find subdomains nobody documented.
• Review again whenever a campaign, product or vendor ends.

Dangling records often sit next to other forgotten pieces, such as old staging and test servers. Cleaning both at the same time is usually the quickest win.

Where Datahorses fits

Datahorses watches your company from the outside every day: it builds the list of your subdomains, checks where each CNAME points and flags records that lead to services that no longer exist. We do not enter your systems and need no access, and each finding comes with the exact steps for your developer. You can see the full list of what we guard or look at the example dashboard.