How do you find a dangling CNAME before it becomes a subdomain takeover?

What a dangling CNAME actually is

A CNAME record, defined in RFC 1035, makes one domain name an alias for another — resolvers look up the target name instead of returning an address directly. It’s the standard way to point a subdomain at a service you don’t control the IP address for: a custom domain pointed at a CDN, a SaaS vendor’s hosting, or a marketing platform’s tracking domain are all common cases. A CNAME goes dangling when you stop using the underlying resource — delete the storage bucket, cancel the hosting plan, decommission the CDN distribution — but never remove the CNAME record itself. The alias still resolves; it just points at something that no longer exists on the other end, or that the provider may let a different customer claim.

Why it enables a subdomain takeover

Many cloud platforms let customers claim a hosting slot, bucket or app name on a first-come basis. If your dangling CNAME still points old-promo.example.com at a platform’s generic endpoint for a resource you deleted, anyone who notices and re-registers that same resource name on the provider’s side can start serving their own content from old-promo.example.com — a domain that still visibly belongs to you in the browser’s address bar, with your organization’s name attached. This is why removing the CNAME record at the same time you decommission the underlying resource matters as much as deprovisioning the resource itself. A wildcard DNS record pointed at a shared target carries a related risk: it can silently resolve subdomains that were never explicitly provisioned, masking exactly the kind of orphaned name this check is looking for.

How to check a specific subdomain today

AdminKit’s DNS lookup tool is live and resolves the CNAME record type directly. Look up the subdomain you’re concerned about and check what it currently points at — a target on a recognizable cloud storage, CDN or app-hosting domain that you don’t believe is still in active use is the signal worth chasing down.

Building an inventory, not just checking one name

AdminKit’s DNS lookup checks one name at a time; it doesn’t enumerate every subdomain of a domain automatically. A real review starts with a full list of subdomains you’ve actually published — your DNS provider’s own zone export is the most reliable source for that, since it’s the definitive list of every record you control — then running each CNAME target through the lookup above and comparing it against what you currently have provisioned in the relevant cloud or SaaS account.

Confirming it’s actually exploitable

A CNAME pointing somewhere unfamiliar isn’t automatically takeable — confirming that depends on the specific target provider. Many cloud and CDN providers show a distinctive error page (an explicit “no such bucket,” “domain not configured,” or similar message) when you browse directly to a dangling target, which is a strong signal the underlying resource is gone. Definitively confirming the name is claimable generally means attempting to register that exact resource name yourself with the target provider — AdminKit’s DNS lookup confirms the DNS pointer, not the destination service’s claim state, so treat an unfamiliar target as worth investigating rather than proof of an active risk on its own.

How to fix it

Remove the CNAME record the moment you decommission the resource it points to — make that step part of your deprovisioning checklist, not an afterthought. For CNAMEs you still need, keep an explicit inventory of what each one is supposed to point at so an unexpected target stands out immediately the next time you review it, rather than blending into a long, unreviewed zone file.

Other exposure checks worth running

If you’re reviewing DNS hygiene more broadly, see is your DNS resolver an open resolver; for mail infrastructure, see how to publish and test MTA-STS; and for a ports-focused check, see how to check if port 123 (NTP) is exposed. This guide sits in AdminKit’s DNS cluster alongside the live tools and glossary terms that back it.

This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.