A team sets up shop.example.com on a cloud service: a DNS record (a
CNAME) points it at example-shop.azurewebsites.net. Months later the cloud
resource is deleted, but nobody removes the DNS record. The record now
points at a name that doesn't exist, a dangling record.
On many cloud services, anyone can create a resource with any free name.
Whoever creates example-shop.azurewebsites.net now serves their own
content on shop.example.com, under your domain, with a valid certificate
they can get for it. That's a subdomain takeover.
Why it matters
A taken-over subdomain is more convincing than any lookalike domain: it is your domain. Attackers use them for:
- Phishing pages that pass every "check the address bar" test.
- Scam and spam redirects that borrow your domain's reputation in search results.
- Cookie theft, if your site sets cookies for the whole domain
(
.example.com), since the subdomain receives them.
In 2025 researchers described a group, nicknamed Hazy Hawk, that took over subdomains of well-known organisations through exactly these abandoned cloud resources and used them for scam redirects.
Which services are affected
The risk exists wherever a deleted resource's name can be claimed again. For some services that's visible from DNS alone, because the name stops resolving once the resource is gone:
| Service | Target looks like |
|---|---|
| Azure App Service | *.azurewebsites.net |
| Azure Cloud Services, VM DNS names | *.cloudapp.net, *.cloudapp.azure.com |
| Azure Traffic Manager | *.trafficmanager.net |
| Azure Blob Storage | *.blob.core.windows.net |
| Azure API Management, CDN, Container Instances | *.azure-api.net, *.azureedge.net, *.azurecontainer.io |
| AWS Elastic Beanstalk | *.elasticbeanstalk.com |
Others, such as S3 buckets and GitHub Pages, keep resolving after the resource is deleted and only show an error page; spotting those takes an HTTP check. The community project can-i-take-over-xyz keeps the full list.
Find dangling records
For each subdomain, check where it points and whether the target exists:
dig +short CNAME shop.example.com
dig +short A example-shop.azurewebsites.net
A CNAME with an empty answer for its target is dangling. The hard part is the list of subdomains: DNS zones are rarely complete documentation. Public Certificate Transparency logs help, because almost every subdomain that ever served HTTPS has a certificate in them. The certificate finder lists them.
Fix it
- Delete the DNS record if the service is gone for good. That's the whole fix.
- Recreate the resource under the same name if the subdomain is still needed, before someone else does.
- If it's already been taken over: delete the DNS record first (that ends it immediately), then report the resource to the cloud provider's abuse team.
Prevent it
- Remove DNS before deleting the resource, not after. Put it in the decommissioning checklist.
- Use the provider's protection where it exists: Azure, for example, can verify domain ownership with a TXT record so only your subscription can bind your custom domain, and documents how to prevent dangling DNS.
- Monitor every subdomain, not just the ones in your documentation.
Check your domain
The subdomain takeover checker looks up every subdomain in the public certificate logs and flags any whose record points at a missing resource, and Nameward's monitoring alerts you when a new one appears.