What is subdomain takeover, and is one of yours dangling right now?

Run dig against every subdomain you've ever published and you'll find a few that still point somewhere. A status page on a SaaS you canceled. A docs site on a host you migrated off. A try.yourdomain.com for a launch two years ago. The apps are gone. The DNS records that pointed at them are, in many cases, still sitting in your zone.

So does any of those still have a CNAME aimed at a service you no longer use? Because if the service freed that name, a stranger can claim it, and then they own a page that loads under your domain, behind your name, with your padlock in the address bar.

How a dangling CNAME becomes someone else's page

A CNAME record is a pointer. status.yourdomain.com doesn't host anything itself, it says "go ask yourcompany.statuspage.io." Your browser follows the pointer and loads whatever that target serves. While you're a paying customer of that service, the target is yours and everything works.

Then you cancel. You delete the app on the provider, or the trial lapses, and the provider releases the name yourcompany.statuspage.io back into its pool. Most people stop here and assume it's done. But the CNAME in your DNS still points at that now-unclaimed name. The pointer is dangling: it aims at an address that no longer belongs to anyone.

A stranger comes along, signs up for the same provider, and claims yourcompany.statuspage.io, the exact name your record still references. Now your CNAME points at their account. They control what loads at status.yourdomain.com. It's the real subdomain, serving their content, and nothing about the URL gives it away.

What they do with it

A subdomain of your real domain is worth a great deal to someone running a scam, precisely because it isn't a fake. Browsers trust it. So do your customers, who have no way to know status.yourdomain.com is no longer yours.

The obvious play is phishing. They stand up a login page that matches your branding, email your users a link to "verify your account at status.yourdomain.com," and harvest credentials from people who checked the domain and saw it was genuinely yours. They can also get a valid TLS certificate for the subdomain, because certificate authorities will issue one to whoever currently controls it, so the padlock is real. That padlock is doing the opposite of protecting your users here. This is one of the reasons a missing CAA record matters: without one, any CA will mint that cert.

There's a session-cookie angle too. If you set cookies on .yourdomain.com with a leading dot, they're sent to every subdomain, including the one a stranger now controls. Depending on how your cookies are scoped, a hostile subdomain can be a path to reading or setting them.

Where they hide

Takeover-prone records cluster around services you provision by pointing a CNAME and forget when you leave. The usual suspects, by the target you'd see in the record:

• Heroku apps (*.herokuapp.com) from a prototype you long since shut down.
• Status pages on Statuspage, marketing sites on a builder, docs on a docs host.
• S3 website endpoints and storage buckets where the bucket got deleted but the alias didn't.
• Cloud front-ends, GitHub Pages (*.github.io) for a project repo you archived.
• Old CDN or app-platform endpoints from a stack you migrated away from.

The common thread is the same every time: the DNS record outlived the thing it pointed at, and the platform recycles names.

How to check, then close it

This one is genuinely checkable from the outside, which is both the good news and the reason it's exploitable. The provider's response is public. Walk your DNS:

dig CNAME status.yourdomain.com +short
# -> yourcompany.statuspage.io
curl -sI https://status.yourdomain.com
# 404 "There is no such app" / "NoSuchBucket" -> dangling, claimable

Pull every CNAME across your zone and follow each one. A target that returns a provider's "no such app," "project not found," or NoSuchBucket page, rather than your content or a clean error you recognize, is a dangling pointer. Treat it as claimable until proven otherwise.

The fix is short, and it lives in your DNS rather than on the dead service: delete the record. If the subdomain still does a job, repoint the CNAME at the live target. If it doesn't, remove it entirely so there's no pointer left to dangle. The rule that prevents the next one is to make DNS cleanup part of decommissioning. When you cancel a service, the record that pointed at it gets deleted in the same sitting.

SurfaceCheckr enumerates your subdomains and follows the CNAME targets from outside, the same lookup an attacker runs, and flags the ones resolving to an unclaimed provider name. We see what's publicly visible. We can't tell you about a subdomain you've never published anywhere, and we don't claim names to prove a takeover is possible. But the dangling pointer that's been sitting in your zone since that launch two years ago is exactly the kind of thing an external scan surfaces fast.