The subdomain you forgot points at a service anyone can claim

A couple of years ago you ran a campaign. Marketing spun up a landing page on a hosted service — promo.yourdomain.com, pointed at a cloud bucket or a website builder — it did its job, and when the campaign ended someone cancelled the service. What nobody did was remove the DNS record that pointed your subdomain at it. Why would they? A leftover line of DNS aiming at nothing seems harmless.

It isn’t quite nothing. That record still says promo.yourdomain.com lives at a particular cloud address — but the resource that used to answer there is gone, and the name it used is now free for anyone to register. If a stranger claims it, they inherit your subdomain: they can serve whatever they like from promo.yourdomain.com — a phishing page, a fake login, malware — and to a visitor, and often to a browser, it’s genuinely your domain, with your name in the address bar and your reputation behind it. This is called a subdomain takeover.

That’s the quiet failure: not a break-in, but a signpost you left pointing at an empty plot that someone else can now build on, in your name.

Why it stays invisible

A dangling DNS record breaks nothing you’d ever notice. The subdomain isn’t one you use any more, so no colleague hits an error, no customer complains, nothing bounces. The record just sits in your DNS quietly advertising a vacancy.

The reason it’s dangerous is the way cloud services hand out names. When you use a hosted bucket, a static-site host or an app platform, you claim a name on their system — and when you stop paying, that name usually goes back into the pool for the next customer. Your DNS record still points at it. So the takeover doesn’t need to break your account or guess a password; the attacker simply registers the now-free name on the cloud provider, and your still-live CNAME does the rest, quietly routing anyone who visits your subdomain to their content.

And these accumulate exactly the way forgotten things do. Every campaign, every retired app, every “let’s try this host,” every supplier you moved away from can leave a pointer behind. Nobody owns the list, because the services they pointed at are long gone from everyone’s mind — which is precisely why the record outlives the thing it named.

The cloud side of this is slowly improving. In March 2026, AWS began letting you create its S3 storage buckets in a namespace reserved for your account alone, so that a deleted bucket name can never be claimed by anyone else. However, that’s opt-in and only applies to new buckets — an existing bucket with an old-style global name still goes back into the shared pool the moment it’s deleted, ready for the next customer. For everything already out there, the fix still sits at your end, in the DNS record.

Find it yourself

You can audit your own DNS in about ten minutes. The harder part is simply getting the full list in front of you.

1. Export every DNS record. Log in to wherever your DNS lives — your domain registrar, or a provider such as Cloudflare or Route 53 — and export or open the full zone. You’re after every CNAME record, and any A record pointing at a cloud service rather than your own server.
2. For each one, ask: does this still point at something we own? Go down the list. For every subdomain, either open it in a browser or, if you’re comfortable at a command line, run dig +short CNAME promo.yourdomain.com to see its target and then curl -sI https://promo.yourdomain.com to see what answers. The tell-tale sign of danger is a cloud provider’s “no such bucket,” “there isn’t a GitHub Pages site here,” or “no app configured” error — that means your name points at a vacancy.
3. Flag anything you don’t recognise. Old campaign subdomains, staging and test names, a service you know you stopped paying for — these are the usual suspects. If you can’t say what a record is for, treat it as suspect until proven otherwise.
4. No command line? Just visit them. Type each subdomain into a browser. A page that clearly isn’t yours, or a hosting provider’s error page saying the resource doesn’t exist, is your answer. It’s slower than a script but needs nothing installed.

The usual reaction is finding two or three names for services the business hasn’t touched in years — still pointing hopefully at the cloud.

The fix

Closing this is mostly a matter of deleting things, which is satisfyingly simple.

Remove the record for anything you no longer use. If a subdomain points at a service you’ve retired, delete the DNS record. That single deletion removes the signpost, and with it the takeover — there’s nothing left to claim.

Fix the order when you decommission. The reason these appear is that services get cancelled while their DNS is left behind. From now on, when you retire anything hosted, remove or repoint its DNS record first, before you release the resource — so there’s never a live pointer aimed at a vacancy.

Reclaim the ones you still want. If a dangling subdomain is one you’d like to keep, don’t just leave it — re-create the resource on the provider so you hold the name again, then decide whether to keep or retire it deliberately.

Keep an inventory, and look again. The root cause is that nobody owns the DNS list. A simple record of what each subdomain is for, revisited a couple of times a year, turns “the record everyone forgot” into “the record we check” — and new campaign subdomains get retired properly instead of piling up.

None of this needs a security team. It needs someone to open the DNS zone, once, and decide that every name pointing out of your domain is worth being able to account for.