Subdomain Takeover: Find and Fix Dangling DNS Records

A client emails you: "we shut down that old microsite last year, but someone's serving crypto-scam content from promo.yourdomain.com." Nobody touched your DNS. Nobody got hacked in the traditional sense. What happened is a subdomain takeover — and if you've ever pointed a CNAME at a third-party service and later cancelled that service, you might be sitting on one right now.

What a subdomain takeover actually is

Most teams point subdomains at external platforms at some point — blog.example.com to a hosted CMS, app.example.com to a PaaS like Heroku or Render, cdn.example.com to a storage bucket, status.example.com to a status-page vendor. That's done with a CNAME record in your DNS zone, something like:

promo.example.com.  CNAME  random-name-8231.herokudns.com.

As long as that Heroku app, S3 bucket, GitHub Pages repo, or Azure resource exists and is claimed by you, the CNAME just quietly does its job. The problem starts when the project ends, the app gets deleted, the trial expires, or someone forgets to renew the resource — but nobody removes the CNAME pointing at it.

The resource name on the other end (that random-name-8231.herokudns.com, or an S3 bucket named promo-example-assets) becomes free for anyone to register on that platform. An attacker finds your dangling CNAME with a routine subdomain scan, signs up for the same service, claims the exact same resource name, and suddenly their content is being served under your domain — with your domain's reputation, your cookies, sometimes even your SSL certificate scope if you're using a wildcard.

Why this matters more than it sounds like

It's easy to shrug this off as "just an old marketing subdomain, who cares." But the impact is real:

• Phishing that looks legitimate. A page at login.yourbrand.com or app.yourbrand.com passes the eyeball test — the URL bar shows your domain, not a lookalike.
• Cookie and session theft. If your main site sets cookies scoped to the parent domain (domain=.example.com), a takeover on any subdomain can read or set those cookies, opening the door to session hijacking on your primary site.
• Content Security Policy bypass. If your CSP or CORS rules whitelist *.example.com, the attacker's page inherits that trust.
• SEO and reputation damage. Search engines and blocklists (Google Safe Browsing, corporate proxies) flag the whole domain, not just the subdomain, once malicious content is found.

None of this requires breaching your server, your hosting account, or your registrar. It's purely a DNS hygiene gap.

Symptom: how you usually find out

Takeovers rarely announce themselves. Common ways they surface:

• A visitor or partner reports "your subdomain is showing something weird."
• A security researcher emails you (sometimes asking for a bug bounty) with a screenshot.
• Your domain gets flagged in Google Search Console under Security Issues, or a browser starts showing a malware/phishing warning.
• You run a subdomain enumeration tool during an audit and one entry resolves somewhere unexpected.

The giveaway in the browser is usually a platform-specific error page instead of your content — things like "There isn't a GitHub Pages site here," "No such app," or an S3 NoSuchBucket XML error. Those error pages are actually good news: they mean the resource is currently unclaimed, not yet weaponized.

How to check your own domain

You don't need fancy tooling for a first pass. Start by pulling every CNAME in your zone.

1. Export your DNS zone

In cPanel, go to Domains → Zone Editor, pick the domain, and export the zone file. Or from the command line against any nameserver:

dig +nocmd example.com axfr @ns1.example.com   # only works if zone transfer is open, usually isn't
dig CNAME promo.example.com +short
dig CNAME app.example.com +short
dig CNAME cdn.example.com +short

If you don't have a full list of subdomains handy, brute-force common ones or check certificate transparency logs, which log every SSL cert ever issued for your domain — including subdomains you may have forgotten about:

curl -s "https://crt.sh/?q=%.example.com&output=json" | python3 -m json.tool | grep -o '"name_value":"[^"]*"' | sort -u

2. Resolve each CNAME target and see what answers

For every CNAME pointing off your own infrastructure, load it in a browser or curl it:

curl -sI https://promo.example.com

Look for these tell-tale "nobody's home" responses:

If a CNAME target is unreachable at the DNS level (NXDOMAIN) rather than reachable-but-empty, that's an even more dangerous flavor — the DNS zone the target lives in has expired or been deregistered, so anyone can potentially claim that whole domain.

Fix: closing the door once you find one

The remediation order matters. Do it in this sequence:

1. Remove the DNS record first. In cPanel's Zone Editor, delete or repoint the CNAME immediately. This is the actual fix — everything else is cleanup. Don't wait to "investigate more" while the record is still live and resolvable.
2. Check for active exploitation. Use the Wayback Machine (web.archive.org/web/*/promo.example.com) and Google's cache to see if the subdomain was ever indexed with content you didn't put there. Check Search Console's Security Issues report.
3. Reclaim the resource yourself, if you still want to use the subdomain. Register a new app/bucket/site under your own account on that platform with a fresh, non-guessable name, then re-point the CNAME to it.
4. Rotate anything that subdomain could have touched. If it shared a parent-domain cookie scope, rotate session secrets and force a re-login for your main app as a precaution.
5. Audit for repeats. One dangling CNAME rarely travels alone — teams that spin up a subdomain per campaign or per client tend to have several.

If you're on Getwebup's DNS and unsure which records are safe to remove, open a support ticket with the subdomain name before deleting anything you didn't create yourself — sometimes an old CNAME still routes internal tooling nobody documented.

Prevention: making this a non-issue going forward

• Keep a DNS inventory. A simple spreadsheet or a comment in your zone editor noting "why this record exists and who owns it" saves hours later. cPanel's Zone Editor lets you add TXT comments alongside records for exactly this.
• Tear down DNS as part of offboarding a service, not as an afterthought. When a project ends, decommissioning the subdomain record should be a checklist item alongside cancelling the vendor subscription.
• Prefer scoped, non-guessable resource names on third-party platforms when possible, and avoid wildcard cookie scoping (domain=.example.com) unless every subdomain is tightly controlled.
• Run a quarterly DNS audit. Pull the zone, resolve every external CNAME, and flag anything returning a "not found" style response.
• Watch certificate transparency logs for subdomains you don't recognize being issued certs — that's often the first sign someone else has claimed a resource under your name.

The takeaway

Subdomain takeover isn't a server compromise, a weak password, or a missed patch — it's an orphaned DNS record nobody remembered to clean up. The fix costs five minutes in Zone Editor. The habit that prevents it costs even less: treat every CNAME to a third-party service as a resource with an owner and an expiry, not a "set it and forget it" entry.