A dangling DNS record points to a resource that no longer exists — a deleted web app, storage account or SaaS site. If someone else can create a resource with the same name, they control what appears on the client’s subdomain. This is a subdomain takeover.
How it happens
- A client sets up
shop.example.comas a CNAME to a cloud service, for exampleexample-shop.azurewebsites.net. - Months later the app is deleted. The CNAME stays in DNS.
- An attacker creates a new app with the same name.
shop.example.comnow serves the attacker’s content — on the client’s real domain, often with a valid certificate.
The result can be phishing pages, malware downloads or stolen cookies, all under a trusted name. Microsoft describes the same risk for Azure in Prevent dangling DNS entries and avoid subdomain takeover.
Why it happens so often
- Projects end, test sites are removed, but DNS is managed by someone else.
- Clients change agencies and the old agency’s records stay.
- DNS sits at a registrar nobody logs into.
Finding dangling records
- Know the subdomains. Public Certificate Transparency logs list hostnames that ever had a certificate — a good starting inventory.
- Follow every CNAME to its end. A target that returns “name does not exist” (NXDOMAIN) is a red flag.
- Check the target service. A default “site not found” page from a cloud provider is another sign.
Clean-up checklist
- Add “remove DNS records” to every decommissioning checklist, before the resource is deleted.
- Review each client’s DNS zone at least every quarter.
- Use provider domain-verification records (such as a TXT record) where the provider supports them.
- Remove records you cannot explain — after checking with the client.
Watchvera discovers subdomains from Certificate Transparency logs, tracks CNAME and other record changes for every client domain, and flags hosts that stop resolving for review.
See how Watchvera handles this: DNS change monitoring.