Subdomain Takeover: the DNS Record You Forgot
A dangling CNAME to a dead service hands your subdomain to whoever claims it. How takeovers happen, how to find dangling records, the cleanup habit.
Short answer
A dangling CNAME to a cloud service you no longer control lets an attacker claim the resource and serve content on your subdomain. Inventory DNS and delete dead records the day you decommission a service.
How it happens
You cancel a Heroku, Azure, or GitHub Pages project but leave the CNAME. The name becomes claimable.
Attackers automate hunting for dangling records. This is not rare edge trivia.
Readers skimming subdomain takeover often stop at definitions. The part that prevents incidents is the verification step after the change - and the habit of re-checking after the next deploy that touches the same layer.
Cleanup habit
Same-day DNS deletion when services die. Monthly DNS review for dangling targets.
Couple decommission tickets with a DNS checklist so the record cannot outlive the service.
Common failure mode for subdomain takeover: staging looks fine, production still serves the old config because a CDN, load balancer, or second vhost was never updated. Always verify the hostname customers hit.
Detection
Watch CT logs and HTTP responses on forgotten subdomains. Brand-abuse reports often arrive late - your inventory should arrive first.
If a subdomain returns a provider "claim this app" page, treat it as urgent.
If this section on subdomain takeover becomes a recurring ticket, automate the check. Manual one-offs rot; a post-deploy assertion or weekly grade keeps the control honest.
What to do this week
- Export all DNS records for production domains.
- Flag CNAMEs to third-party hosts; verify each service still exists.
- Delete dangling records the same day.
- Add DNS cleanup to the decommission checklist.
Dead SaaS plus live DNS equals someone else's site on your name.
Update log (1)
2026-07-04Editorial form rewrite for length and uniqueness.
Sources + verification
Practical guidance based on mainstream browser behavior, common reverse-proxy configuration, and widely published RFCs and vendor docs. Verify on your own stack with curl, browser devtools, and a re-scan after each change.
