Dangling CNAME Detection

A dangling CNAME is a record on your domain pointing at a third-party hostname that no longer resolves. The original SaaS account, S3 bucket, Heroku app, GitHub Pages repo, or similar resource was deleted or expired, but the DNS record was left behind. An attacker who can register the abandoned hostname on that provider takes over your subdomain entirely: it serves attacker content under your domain's name, reputation, and cookies. This is the heaviest single check in the catalog (35 points) because the consequences (phishing on a real subdomain of yours, cookie theft, OAuth-flow hijack) are severe and the fix is usually quick once the finding is in front of you.

How the check works

RedScore loads the subdomain list from the Subdomain Resolution check (apex and www are always included as fallback) and queries CNAME records on each host. For every CNAME found, the resolver follows the chain (up to 8 levels deep) looking for an A or AAAA at the end. If the chain has no address, the CNAME is dangling and goes into the evidence. Targets matching well-known takeover-prone suffixes (Heroku, S3, GitHub Pages, Netlify, Vercel, Surge, Shopify, Azure Web Apps, etc.) are tagged with a claimable_provider_hint so you can prioritise reclaim or removal.

How the verdict maps to evidence

• Pass: every CNAME on every checked host resolves to an A or AAAA somewhere in its chain.
• Fail: at least one CNAME points at a target that does not resolve. The dangling_findings array lists each (host, cname_target, claimable_provider_hint). claimable_provider_hint is non-empty when the target is on a provider where new accounts can claim arbitrary subdomains.

Fail: decide reclaim or remove for each finding

Walk every entry in dangling_findings. For each one, the question is: do you still need this subdomain? Two paths.

Reclaim

If the subdomain is still in use (or you want it back), re-register the target hostname on its original provider before anyone else does. The path depends on the provider:

• Heroku (.herokuapp.com): heroku create <app-name> with the exact name from the CNAME target, then attach your custom domain. App names are globally unique; if someone else has already claimed it, reclaim is impossible.
• AWS S3 (.s3.amazonaws.com): create a new bucket with the exact name in the same region. Re-host the static content. Bucket names are globally unique.
• GitHub Pages (.github.io): create a repo at <username>/<repo> matching the CNAME target. Configure Pages on the right branch and add the custom domain.
• Netlify (.netlify.app), Vercel (.vercel.app), Surge (.surge.sh): create a new site or project with the exact subdomain.
• Azure (.azurewebsites.net, .azureedge.net, .cloudapp.azure.com, .trafficmanager.net): create a new resource with the same name in your subscription if the slot is free, otherwise reclaim is not possible.
• Shopify (.myshopify.com), WordPress.com (.wordpress.com), Tumblr (.tumblr.com), Pantheon (.pantheonsite.io), Bitbucket (.bitbucket.io), Ghost (.ghost.io), GitLab (.gitlab.io): each provider's account-creation flow assigns subdomains. Check whether the target name is still available before assuming reclaim works.

Some providers explicitly prevent re-registration of recently-deleted names to deter this attack. If reclaim fails, the only safe option is to remove the DNS record.

Remove

If the subdomain is no longer in use, delete the CNAME from your DNS. In a managed DNS UI (Cloudflare, Route 53, Google Cloud DNS, NS1, Azure DNS, DNSimple), find the record by hostname and remove it. In a BIND zone file, delete the line and reload (rndc reload). Wait one TTL for the deletion to propagate before considering it cleared.

Before pulling, audit anything that might depend on the subdomain: hardcoded references in app code or docs, monitoring checks, OAuth callback URLs, webhook destinations, and email templates.

Prevention

• Add DNS removal to your service-decommission checklist. When you delete a SaaS account or tear down a PaaS app, the CNAME pointing at it must come down at the same time.
• Manage DNS as code (Terraform, OpenTofu, dnscontrol, octoDNS). When a resource is removed in IaC, the CNAME deletion is part of the same diff and review.
• Run a dedicated subdomain-takeover scanner periodically. subjack, subzy, and the public can-i-take-over-xyz wordlist all probe for the well-known takeover-prone suffixes RedScore checks plus many more.
• When provisioning new third-party services, prefer providers that block re-registration of recently-deleted names. AWS S3 introduced a bucket-name reservation period; not every provider has caught up.

Verify the fix

• For each finding, run dig +short CNAME <host> @1.1.1.1 and dig +short A <host> @1.1.1.1. Reclaimed: the chain now resolves to an address. Removed: dig returns nothing.
• If you removed CNAMEs, give DNS one TTL to propagate before re-scanning.
• Re-run the RedScore lookup. The verdict moves to pass only when every CNAME resolves end-to-end.

Common pitfalls

• Removing a CNAME that something still depends on. Audit before pulling. Hardcoded references in app code, OAuth callbacks, webhook destinations, and email templates can break silently.
• Reclaiming on the wrong account. The takeover risk is the target hostname being claimable by anyone. Reclaiming on a different team's account or a personal account leaves the same exposure if that account ever lapses.
• Multi-level CNAME chains. A → CNAME B → CNAME C → A_record. The chain can dangle at any link. Removing only the leaf does not help if a middle link is on a takeover-prone provider.
• Wildcard CNAMEs masking the problem. If *.yourdomain.tld points at a SaaS host, every subdomain appears to resolve, but each one is a separate takeover surface if the wildcard target is claimable.
• Trusting that a provider "takes care of" stale records. The DNS record is at your registrar or DNS provider; the deleted SaaS account is at someone else's. They have no link.
• Re-registering one name and assuming the takeover risk is gone for everyone. The fix is per-record. Walk every dangling_findings entry.