Subdomain Takeover: The Forgotten DNS Record That Hands Over Your Domain

Somewhere in your DNS zone there may be a CNAME pointing at a cloud service you cancelled a year ago. The record still resolves, the service name is up for grabs, and whoever claims it gets to publish content on your subdomain. Dangling records like this exist in far more DNS zones than their owners expect — because subdomains get created for a week and remembered never.

What a dangling DNS record is

A CNAME record is an alias: promo.yourcompany.com → yourapp.herokuapp.comtells the world “the content lives over there.” The pattern is everywhere — Heroku apps, S3 buckets, Azure websites, GitHub Pages, Netlify and Vercel deployments, status pages, help desks.

A record becomes dangling when the thing it points at is deprovisioned: the Heroku app deleted, the S3 bucket removed, the trial cancelled — while the CNAME stays in DNS. Your subdomain is now an alias for a name that nobody owns.

How a takeover happens

Names on most cloud platforms are first-come, first-served. If yourapp.herokuapp.com is deleted, someone else can register that same app name — or claim the matching bucket or site name on whichever platform your record points to. From that moment, promo.yourcompany.comresolves to infrastructure they control. Visitors see your domain in the address bar and someone else’s content on the page.

Nobody finds these by hand. Automated scanners continuously sweep DNS at internet scale for CNAMEs that answer with the telltale error pages deprovisioned services return — “no such app,” “NoSuchBucket,” “there isn’t a site here.” A forgotten record on a small company’s domain gets found by the same automation that sweeps everyone else’s.

Why it matters more than it sounds

• Phishing with your name on it.A fake login page or “invoice portal” hosted on a real subdomain of your real domain defeats the one piece of advice users actually follow — “check the domain.” Some platforms will even provision a valid HTTPS certificate for the hijacked name automatically.
• Cookie scope abuse. If your app sets cookies scoped to the parent domain (Domain=.yourcompany.com), a controlled subdomain can receive those cookies from visiting users — and set cookies that your main app will trust.
• Inherited trust. Anything configured to trust *.yourcompany.com— CORS allowlists, OAuth redirect lists, content security policies — now trusts the attacker’s content too. This is one of the quiet reasons wildcard origins are risky; see our CORS guide.
• Reputation damage.Search engines index whatever is served there, so spam or malware hosted on your subdomain becomes part of your domain’s history.

Why this keeps happening

Subdomains are cheap and disposable; DNS records live forever unless someone deletes them.

• Marketing spins up promo. on a landing-page builder for a campaign, then closes the account when it ends.
• Engineering creates staging. and demo. on a PaaS, then migrates the project elsewhere.
• An agency builds careers. on their favorite platform, and the contract ends.
• A hackathon deploy on a free tier quietly expires.

The service is decommissioned in one system, the DNS record lives in another, and no single person owns the mapping between them. If you ship fast with AI tools — a Vercel preview here, a Railway app there — the number of these mappings grows weekly. Our vibe-coding security guide is about exactly this kind of drift.

How to check your own domain

1. Export your DNS zone. From your DNS provider (Cloudflare, Route 53, your registrar), list every record — especially CNAMEs.
2. Resolve each CNAME. dig CNAME sub.yourcompany.com +short, then open the target in a browser.
3. Look for provider error pages.“No such app,” “NoSuchBucket,” “There isn’t a GitHub Pages site here” — these are the signature of a dangling record.
4. Ask whether each record should exist at all. The safest stale record is a deleted one.

While the zone is open, verify your SPF, DKIM, and DMARC records too — email authentication is the other half of DNS hygiene. Then put a quarterly reminder on the calendar, or let a scanner do the sweep for you.

How to fix and prevent it

The fix is one line:delete the stale record — or re-claim the service name yourself if you still need the subdomain. That’s genuinely it.

Prevention is a habit:

• Keep DNS as code, or at least as inventory. A Terraform file — or even a spreadsheet — that says what each record is for and who owns it.
• Decommission in the right order: DNS first, then the service. Delete the CNAME, let the TTL expire, then delete the app or bucket. The reverse order is what creates the takeover window.
• Add “remove DNS records” to your offboarding checklist for every tool and vendor you cancel.

Two related smells worth fixing while you’re in there

• Subdomains served without HTTPS. Any live subdomain answering on plain HTTP undermines the padlock users expect from your brand and invites interception on hostile networks.
• Sensitive-looking names. staging., admin., dev., test.— publicly resolvable names like these advertise internal surfaces to anyone who enumerates your DNS. If they must exist, they should be access-controlled; often they don’t need public DNS at all.

How BoringSec checks this

BoringSec’s subdomain scanner — one of 24 runtime scanner modules — enumerates your subdomains and checks each one for takeover risk using dangling-CNAME fingerprints of known cloud services. We are deliberately evidence-first here: a dangling record is reported with the evidence we captured, while candidates that need manual verification are flagged separately — we don’t claim a takeover we haven’t confirmed, because we don’t sell fear. The same scan lists sensitive-looking subdomains (staging, admin, dev, and friends) and flags any subdomain served without HTTPS. How findings roll up into your A++ to F Security Score — including the rule that any confirmed critical finding caps the score at 30 — is documented in our methodology.

FAQ