What is a Dangling DNS Record?

A dangling DNS record is an entry in your zone that still points to a target which no longer exists or no longer belongs to you. The record itself is perfectly valid — it resolves and returns an answer — but the resource on the other end has been deleted, cancelled, or released. A common example is a CNAME record on app.example.com still aliasing a hosting platform hostname for an app you removed months ago.

Dangling records are almost always a byproduct of normal lifecycle work where DNS cleanup is forgotten:

• Decommissioned services — a SaaS subscription, support tool, or marketing platform is cancelled, but the custom-domain record that pointed at it stays behind.
• Deleted cloud resources — a virtual machine, load balancer, or storage bucket is removed and its address is released back to the provider, yet the A or CNAME record is never updated.
• Retired hosting apps — a static site or PaaS app is deleted, freeing its hostname for anyone to re-register on that platform.
• Project churn — temporary subdomains spun up for a campaign, demo, or test are left in the zone long after the work is finished.

A dangling record is the root cause of subdomain takeover. When a record points to a platform hostname that is now unclaimed, an attacker can register that same hostname on the platform and serve their own content from your subdomain. Because the subdomain genuinely belongs to your domain, the malicious page inherits your brand's trust:

• Credential-harvesting pages hosted on a real subdomain of your brand.
• Cookies scoped to the parent domain that may become readable from the hijacked subdomain.
• Your domain used to distribute spam or malware, damaging reputation and search standing.

Inventory every record in your zones and confirm each target still answers for you. Pay particular attention to records pointing at third-party platforms:

1. List all subdomains and the records that back them.
2. For each record that points to an external service, check that the resource still exists and is still claimed by you.
3. Treat any record that returns a platform error page — such as a no such app or bucket not found message — as dangling and remove it.

Doing this once is not enough; services are decommissioned continuously, so dangling records keep appearing over time.

• Delete DNS first — when retiring any service, remove its DNS record before you tear down the resource it points to. This single habit closes the most common takeover window.
• Audit regularly — make zone review part of your offboarding and project-closeout checklists.
• Monitor continuously — ZoneWatcher tracks every record in your zones and alerts you when records are added or changed, so orphaned entries do not sit unnoticed and become an easy target.

For the wider context, see DNS security best practices.