Guide
Subdomain Security: Dangling Records and Takeover Prevention
Every subdomain you've ever created is a potential attack surface if you didn't clean up the DNS when you were done. Here's how subdomain takeover works, which services are vulnerable, and how to find your exposure.
Subdomains are cheap to create and expensive to forget. A CNAME to a SaaS host you no longer own is a dangling record — attackers can claim the target and serve content on your domain. This guide explains dangling DNS, takeover mechanics, and cleanup. Core term: subdomain takeover; CNAME mechanics.
What is a dangling DNS record?
A record that still points to a resource you deleted — commonly a CNAME to github.io, azurewebsites.net, herokuapp.com, or similar. The cloud name is still delegatable; your DNS still routes traffic to it.
How subdomain takeover happens
Attacker enumerates your subdomains (cert transparency, search engines, brute force). They see a CNAME to a provider they can control. They claim the app name on the provider. Traffic intended for your subdomain now hits their content — often phishing or malware. Real cases: subdomain takeover cases.
Which services are vulnerable
Common: GitHub Pages, S3 static hosting, Heroku, Netlify, Azure App Service — any platform where a name can be (re)registered after you release it. Your DNS record is the permanent switchboard.
How attackers use taken subdomains
Phishing against your customers, malware distribution, credential harvesting, and SEO abuse. The domain trust is yours; the payload is theirs.
How to find your dangling records
Inventory subdomains, resolve each CNAME, check if the target exists and is yours. Automate with DomainPreflight Dangling Records — discovery via certificate logs plus fingerprint checks.
The fix — delete the record
Remove the CNAME or replace it with a controlled service. If you still need the hostname, provision the service first, then point DNS. No half measures.
Defensive DNS hygiene
Deprovisioning checklist: cancel SaaS, delete app, remove DNS, verify resolution. Quarterly audits. Read dangling CNAMEs for patterns.
Engineers rotate projects faster than DNS ages out. A marketing microsite on Netlify abandoned in 2023 can still have a CNAME in 2026 — and certificate transparency keeps the hostname discoverable forever. Treat DNS like code: review diffs, blame owners, remove dead routes.
Combine this guide with brand protection — takeover undermines customer trust even when DMARC is perfect on the root domain.
Tool: Discover subdomains and flag CNAMEs that point to abandoned services.
Step by step
FAQ
What is subdomain takeover?
When a CNAME points to a deleted external service, an attacker can claim that service and serve content on your subdomain.
Which cloud services are most vulnerable to subdomain takeover?
GitHub Pages, AWS S3, Heroku, Netlify, and Azure are the most common targets.
How do I find my dangling DNS records?
Run DomainPreflight Dangling Records — it discovers subdomains via certificate logs and checks each CNAME against known takeover fingerprints.
What should I do if I find a dangling record?
Delete the DNS record immediately. If you still need the subdomain, recreate the service first.
How often should I audit my DNS for dangling records?
Every 3-6 months, and every time you decommission a service or subdomain. Run Dangling Records as part of your offboarding checklist.