A dangling CNAME points to a service you no longer control — letting attackers claim it and hijack your subdomain.
What is a dangling CNAME?
A dangling CNAME is a DNS record that points to a third-party service or domain endpoint that has been deprovisioned, deleted, or abandoned by the domain owner.
Dangling CNAMEs are the silent killers of domain reputation. They represent a broken trust link. Your authoritative DNS continues to tell the world that a specific service is authorized to host content on your behalf, but because you no longer own that service endpoint, the authorization is essentially open for anyone to grab.
If you are already working through , this topic gives you the missing layer between the raw signal and the decision you have to make.
The vulnerability lifecycle of a dangling CNAME is surprisingly simple.
Provisioning: You create a blog on a cloud platform. The platform gives you an endpoint like mybrand.provider.com.
DNS Mapping: You create a CNAME record in your DNS zone: blog.yourdomain.com CNAME mybrand.provider.com.
Deprovisioning (The Mistake): A year later, you delete the blog from the cloud platform to save money, but you forget to delete the CNAME record in your DNS.
Exploitation: An attacker signs up for the same cloud platform, creates a new project, and claims the endpoint mybrand.provider.com.
Takeover: Because your DNS still points to that endpoint, the attacker now controls what is displayed when users visit blog.yourdomain.com.
Vulnerable platforms list
This risk shows up anywhere a third-party platform lets customers bind subdomains and later release them. Common vectors include:
GitHub Pages (username.github.io)
Heroku (appname.herokuapp.com)
Netlify (sitename.netlify.app)
Azure (appname.azurewebsites.net)
Amazon S3 (bucketname.s3.amazonaws.com)
Shopify (storename.myshopify.com)
Ghost (blogname.ghost.io)
Fastly (service.global.fastly.net)
Step-by-step attack demonstration
Let's look at a real-world scenario. Your DNS zone has the following stale record:
DNS Record / Config
support.example.com. 3600 IN CNAME example-help.zendesk.com.
If the attacker runs a DNS query against your subdomain, they see it resolves to the Zendesk endpoint:
The attacker then queries the Zendesk endpoint directly. If the account was deleted, the provider will return an NXDOMAIN (or a provider-specific 404):
DNS Record / Config
$ dig +short A example-help.zendesk.com.
# No answer, NXDOMAIN returned
Seeing this, the attacker immediately goes to Zendesk, registers a new trial account, and sets their subdomain to example-help. Now, any visitor to support.example.com lands on the attacker's phishing portal.
What attackers do with a hijacked subdomain
Once an attacker controls the content served on your subdomain, the damage can be catastrophic.
Phishing & Brand Damage: They can host pixel-perfect login pages to steal credentials from your users. The URL looks completely legitimate because it is your domain.
Cookie Theft: If the hijacked subdomain is part of your main site's cookie scope (e.g., cookies set to *.example.com), the attacker can read session cookies and hijack active user sessions.
CSP Bypass: Content Security Policies (CSP) often whitelist *.example.com for loading scripts. Attackers can host malicious JavaScript on the hijacked subdomain and use it to execute XSS on your main web application.
Important
Dangling CNAMEs are permanent once exploited. If an attacker takes over your subdomain, they can issue a valid Let's Encrypt SSL certificate for it because they control the HTTP response. The browser will show a secure padlock, making the attack indistinguishable from legitimate traffic.
How to find dangling CNAMEs in your zone
Detection requires scanning your entire zone file and actively testing every CNAME target.
You can manually check individual records using dig:
DNS Record / Config
$ dig support.example.com
Look at the status field in the response. If it says NXDOMAIN, the target does not exist, and the record is dangling.
However, some providers don't return NXDOMAIN; they return an A record that points to an error page. You must inspect the HTTP response to confirm if it's an "unclaimed" service.
Automated scanning approaches
To protect a large enterprise, you must automate this checking. Security teams use continuous monitoring tools that:
Ingest all zone files across all registrars.
Resolve every CNAME target daily.
Compare the HTTP responses of targets against known platform signatures (e.g., GitHub's "404 There isn't a GitHub Pages site here").
Alert immediately when a signature matches.
Remediation: remove record vs. renew service
The remediation is straightforward but requires operational discipline.
Remove the record: This is the cleanest fix. If the service is no longer needed, delete the CNAME from your DNS zone immediately.
Renew the service: If the deprovisioning was accidental, immediately go back to the provider and re-claim the endpoint before an attacker does.
CNAME lifecycle policy best practices
The root cause of dangling CNAMEs is broken offboarding. To fix it permanently:
Infrastructure as Code (IaC): Manage DNS via Terraform or similar tools. When tearing down a cloud resource, the accompanying DNS record should be destroyed in the same pull request.
Periodic Audits: Enforce quarterly reviews of all DNS records pointing to external domains.
Continuous Monitoring: Implement tools like CyberFurl to catch mistakes that slip past manual processes.
Tools to check your Dangling CNAME
Use the CyberFurl subdomain review when you want to see the live signal on a real domain, and then step back to the See the DNS posture feature page when you need the wider workflow around posture, monitoring, or remediation. That combination is usually much more useful than reading the standard in isolation.
CF
How CyberFurl Helps
Automated monitoring. Zero manual work.
CyberFurl automatically scans your entire DNS zone for CNAME records pointing to services that no longer exist — the root cause of subdomain takeover attacks. When a CNAME target returns NXDOMAIN or a platform-specific unclaimed response (GitHub Pages 404, Heroku 'no such app', Netlify 'not configured'), CyberFurl raises an immediate alert so you can remove the stale record before attackers register the dangling target and hijack your subdomain.
Is a dangling CNAME the same as subdomain takeover?
Sometimes, but the better question is under what conditions it is true. With Dangling CNAME, the answer usually depends on the live configuration, the surrounding protocol behavior, and whether the systems on the other side actually honor the signal the way the documentation suggests.
How do I find dangling CNAMEs in bulk?
Start with the live public evidence, not the config file you hope is in production. Once you know what the domain is actually publishing or sending, compare that with the intended posture, make one controlled change, and then validate it again from the outside.
Why do they happen?
The right next step is usually evidence first: inspect the live public behavior, identify the dependency or exposure that matters, and then decide whether to implement, tighten, monitor, or clean up. Dangling CNAME is most useful when the answer is anchored in what production is actually doing rather than in documentation alone.
Which providers are most affected?
The right next step is usually evidence first: inspect the live public behavior, identify the dependency or exposure that matters, and then decide whether to implement, tighten, monitor, or clean up. Dangling CNAME is most useful when the answer is anchored in what production is actually doing rather than in documentation alone.
What is Dangling CNAME?
A dangling CNAME points to a service you no longer control — letting attackers claim it and hijack your subdomain. In practice, teams care about Dangling CNAME because it changes a real trust boundary somewhere in the stack and gives them a concrete signal they can validate on the live domain or application.
Can a dangling CNAME be fixed automatically?
No, remediation requires manual removal of the record from your DNS zone or reclaiming the lost service endpoint to prevent exploitation.
Are dangling CNAMEs limited to web hosting platforms?
No, they affect any third-party service that provisions a unique endpoint, including email services, support portals, CDN distributions, and cloud storage buckets.
