Dangling CNAMEs typically appear when:
A normal CNAME record: blog.yourcompany.com CNAME yourcompany.github.io — works because yourcompany.github.io is an active GitHub Pages site controlled by you.
A dangling CNAME: blog.yourcompany.com CNAME yourcompany.github.io — is dangling if yourcompany.github.io has been deleted from GitHub. The CNAME record exists; the target does not.
If the GitHub Pages namespace yourcompany.github.io is claimable by an attacker (by creating a new GitHub account or repository with that name), the CNAME now points to an attacker-controlled site — making it a subdomain takeover vulnerability.
Remove the dangling CNAME record from your DNS. If the service is still needed, restore the underlying service first before removing the CNAME record. Audit all CNAME records in your DNS zone against the external services they point to — particularly for services like Heroku, GitHub Pages, Netlify, Vercel, and S3 where namespace is claimable.
Dangling CNAME describes a security concept that affects how teams understand, monitor, and reduce external exposure across internet-facing assets.
It matters because attackers continuously inspect public assets. Tracking this concept helps teams reduce exploitable exposure before it becomes a breach path.
VeilScan discovers public assets, validates findings with proof, prioritises issues by business impact, and explains remediation in reports built for engineering and leadership.