← Back to the Subdomain Takeover Checker

Why CNAMEs end up dangling

A dangling CNAME only becomes a takeover risk once someone else claims the name it points at. There are a few common, independent ways the record is left behind in the first place. Fixing one does not fix the others.

1. Decommissioning the resource doesn't touch DNS

Deleting an S3 bucket, a Heroku app, or a GitHub Pages repository is usually a one-click action in that provider's own dashboard — and it does not touch your DNS zone at all. The CNAME record you created when you first set the subdomain up keeps pointing at a name that now belongs to nobody, until someone remembers to remove it separately, in a different system.

# Wrong: delete the S3 bucket and stop there
aws s3 rb s3://old-marketing-page-bucket --force
# blog.example.com's CNAME still points at old-marketing-page-bucket.s3-website-us-east-1.amazonaws.com

# Right: remove the DNS record in the same change
aws s3 rb s3://old-marketing-page-bucket --force
# then, in your DNS provider: delete the CNAME for blog.example.com

2. It's not on the offboarding checklist

The fix is procedural, not technical: whatever runbook or ticket template your team uses for decommissioning a service, add "remove the DNS record pointing at it" as a required step, in the same place as "revoke the API key" and "delete the database". A resource that still exists is not takeover-prone; the dangling record left behind after it's deleted is.

3. Nobody audits the zone on a recurring basis

A team that migrates providers, retires a marketing campaign's landing page, or sunsets an old product line accumulates dangling records the same way — each individually easy to miss, and each dangling indefinitely until someone claims it, maliciously or otherwise. A recurring pass over your own DNS zone's CNAME records, checked against what's still actually provisioned, catches what any one migration's checklist did not.

If this checker already found a confirmed finding

Two ways to close it, and you usually want one or the other rather than both:

• Still using it: reclaim the exact name on the provider (recreate the S3 bucket with that name, recreate the Heroku app, re-add the GitHub Pages custom domain) before anyone else can.
• Not using it anymore: remove the CNAME record from your DNS zone entirely — the subdomain then stops resolving, which is safe, rather than continuing to point at a name someone else could still claim.

Run the Subdomain Takeover Checker again afterward to confirm the fix. Only run it against a hostname you own or are authorised to test.