How it works
Many services are attached to a subdomain with a CNAME: shop.example.com points to example.myshopify.com, docs.example.com to example.github.io, app.example.com to an Azure web app. When the service is cancelled or deleted, the CNAME often stays behind, now pointing at a name nobody holds at the provider (a dangling CNAME).
If anyone can register that name at the provider, they get the subdomain with it: they sign up, claim the free name or custom domain and serve their own content at shop.example.com, often with a valid certificate the service issues automatically.
The same pattern applies to NS delegations pointing to DNS zones that were deleted at the provider, and to A records pointing to cloud IP addresses that were released and reassigned to another customer.
Why it matters
A hijacked subdomain looks genuine to visitors, browsers and spam filters: a phishing page at login.example.com is convincing, cookies scoped to the whole domain go to the attacker, and rules that trust every subdomain (CORS, CSP, OAuth redirects) now work for them.
The client’s reputation takes the hit: search engines index spam under their domain, and Google may put the subdomain on its warning list, which unsettles visitors even more.
How to prevent it
- When decommissioning a service, delete the DNS record first and only then the account, app or bucket at the provider.
- Regularly reconcile CNAME, NS and A records against the list of active services; zone backups or exports from the DNS provider make this easier.
- Where the provider supports it, verify the domain with a TXT record (such as verified domains on GitHub Pages or asuid records on Azure) so only your account can claim it.
- Avoid wildcard CNAMEs to external services, and remove staging or dev environments together with their DNS records when a project ends.
- Work through a DNS checklist whenever a client or vendor is offboarded.
How DomainWarn detects it
The Subdomain takeover check examines up to 60 hostnames a day: the domain, the hosts of website monitors, hostnames from the CT logs and common prefixes such as www, staging, dev, shop or api. It follows every CNAME chain authoritatively. If the chain ends in a name that no longer exists (confirmed by a second public resolver), or a known service such as GitHub Pages, Heroku, Amazon S3, Shopify, Netlify or Vercel responds that the name is unclaimed, the finding is critical and opens the “Subdomain can be taken over (orphaned DNS record)” incident. The same applies to a subdomain delegated to name servers that no longer know the zone.
An orphaned CNAME nobody can claim (for example one pointing inside your own domain) is a warning, as is a hostname from the CT logs whose address belongs to a cloud provider and answers on neither port 80 nor 443. DomainWarn only detects: it never creates accounts or claims names anywhere.
DomainWarn checks this for all your domains on a schedule and alerts you when something is missing or changes.