How do I know if a DNS record is dangling?

Resolve the record's target and check whether it still exists and still belongs to you. A CNAME pointing at a hostname that returns NXDOMAIN or a provider's generic 'no such site' page, or an A record aimed at an IP you've released, is dangling.

Is a dangling DNS record always exploitable?

Not always, but you can't easily tell in advance. It becomes exploitable the moment the target resource can be re-claimed by someone else on a provider that allows it. Treat every dangling record as a takeover candidate and remove it.

What's the fastest fix for a dangling record?

Delete the record if the subdomain is no longer needed, or repoint it at a resource you currently control. Then add DNS cleanup to your service-decommissioning checklist so the problem doesn't recur.

What Is a Dangling DNS Record and Why It's a Subdomain Takeover Risk

VigilDog Team · October 25, 2026 · 7 min read

A dangling DNS record is one of those quiet risks that sits in your zone file for months, doing nothing visible, until an attacker claims the resource it points to and suddenly owns a subdomain of your brand. Here's exactly how a dangling DNS record becomes a subdomain takeover, and how to find and close them before someone else does.

What is a dangling DNS record?

A dangling DNS record is a DNS entry that still points to a resource you no longer control or that no longer exists. The record is live and resolving, but the thing on the other end, a cloud host, a SaaS account, an IP address, has been decommissioned, cancelled, or released back into a shared pool.

The classic shape is a CNAME. Say you set up status.example.com as a CNAME pointing to your-app.some-saas.com while trialing a status-page service. You later cancel the service, but nobody removes the CNAME. The DNS record now dangles: it faithfully points visitors to a hostname on a provider where your account no longer exists. It's the DNS equivalent of a forwarding address to an apartment you've moved out of, one anyone can now rent.

How dangling records become subdomain takeover

The danger is that many providers let anyone claim a hostname that isn't currently in use. When your CNAME points at your-app.some-saas.com and that name is now unclaimed on the provider, an attacker simply signs up, claims that exact hostname, and hosts whatever they like. Because your DNS still routes status.example.com there, their content is served under your subdomain, with your domain in the address bar.

That's a subdomain takeover, and it's serious. The attacker can host convincing phishing pages that look unquestionably legitimate because they genuinely live on your domain. Worse, if you set cookies at the parent-domain level, they may be readable across the subdomain, and any OAuth or SSO flow that trusts your domain can be abused. The victim did nothing wrong today; they just forgot to delete a record years ago.

The common flavors of dangling records

It isn't only CNAMEs, though those are the most exploited. Watch for several patterns.

The specifics vary but the root cause is identical every time: DNS outlived the resource it referenced. Cloud environments make this especially easy because IPs and hostnames are ephemeral by design, spun up and torn down constantly, while DNS records are set once and forgotten.

CNAME to a deprovisioned SaaS (status pages, help desks, CDNs, hosting platforms) whose hostname can be re-registered
A/AAAA record pointing at a cloud IP you released, which the provider later reassigns to another customer
NS records delegating a subdomain to a nameserver or zone that no longer exists (lame delegation)
MX records aimed at a mail host you've stopped paying for

How to find dangling records

Finding them is a matter of reconciling two lists: every DNS record in your zones, and every resource you actually still operate. Start by exporting your full zone from each DNS provider. For every CNAME, resolve it and check whether the target still exists and still belongs to you; a target that returns NXDOMAIN or a provider's generic 'no such app' page is a red flag. For A/AAAA records, confirm the IP is still allocated to you. For delegated subdomains, verify the nameservers still answer authoritatively.

Provider-specific fingerprints help: many SaaS platforms serve a recognizable error page when a hostname is unclaimed ('There isn't a GitHub Pages site here', 'NoSuchBucket', and similar), and those signatures are exactly what takeover scanners look for. You can spot-check any record's current target with our DNS checker, then trace whether that target still resolves to something you own.

How a domain name resolves to a server

Fixing and preventing them

The fix for a confirmed dangling record is simple: delete it. If the subdomain is still needed, repoint it at a resource you currently control. The harder part is prevention, and it comes down to process. Whenever you decommission a service, cancel a SaaS account, or release cloud infrastructure, removing the DNS record must be part of that teardown, not an afterthought. Tie DNS cleanup to your offboarding checklist for every tool.

But process fails, because the record and the resource are managed by different people at different times, sometimes years apart. That's why the reliable defense is continuous detection: something watching your zones from the outside that notices when a record starts pointing at an unclaimed or dead target and raises it before an attacker does.

Monitoring closes the window

The window between 'resource decommissioned' and 'attacker claims it' can be minutes or months, and you have no way to predict which. Manual audits catch dangling records once a quarter if you're disciplined; attackers scanning for takeover targets run continuously.

VigilDog's DNS monitoring watches your records for exactly this kind of drift, flagging entries that resolve to dead or unclaimed targets so a forgotten CNAME becomes an alert instead of a phishing page on your domain. For agencies juggling dozens of client zones, that continuous coverage is what makes subdomain takeover a non-event rather than an incident report.