How do I know if a subdomain is vulnerable to takeover?

Resolve its CNAME or NS record and check the target. If the record points at a cloud provider hostname that returns an error page like "NoSuchBucket" or "no such app"meaning the resource no longer exists but the DNS record still points at it, the subdomain is dangling and can likely be claimed by an attacker.

Is subdomain takeover really dangerous if it's just a subdomain?

Yes. The attacker serves content on your trusted domain, so they can run convincing phishing, pass domain-validated certificate issuance, and in many browsers read cookies scoped to the parent domain. A dangling NS delegation is worse still, handing over an entire subtree rather than one host.

How often should I scan client domains for takeovers?

Continuously, not once. Dangling records appear whenever a cloud resource is deleted without removing its DNS record, which can happen any day. A scheduled scan that re-enumerates and re-resolves records and alerts on unclaimed targets closes the window between deletion and exploitation.

How to Detect Subdomain Takeover Across Client Domains

VigilDog Team · October 28, 2026 · 7 min read

A subdomain takeover is one of the quietest ways a domain gets compromised. Nobody breaks into your DNS, guesses a password, or exploits your server. Instead, a subdomain keeps pointing at a cloud resource that you long since deleted, and an attacker simply re-creates that resource under their own account. Now blog.client.com or status.client.com serves their content, on your client's trusted domain, with a valid certificate. For an agency holding dozens of client domains, subdomain takeover detection is not a nice-to-have; it is basic hygiene.

What a subdomain takeover is

Most takeovers begin with a CNAME. Say marketing spun up a landing page at promo.client.com and pointed it, via a CNAME, at a hosting provider like a static-site host, a help-desk tool, or a cloud storage bucket. Months later the campaign ends and someone deletes the app at the provider, but nobody removes the CNAME in DNS. The record is now dangling: it points at a hostname the provider no longer has assigned to anyone.

The provider hands that hostname back into its pool. An attacker who claims the same resource name on the same platform now controls whatever promo.client.com resolves to. Because DNS still sends visitors there, the attacker inherits the subdomain's trust: they can host phishing pages, steal cookies scoped to the parent domain, or pass domain-validated certificate checks. The parent domain's owner did nothing wrong on the day of the attack, the vulnerability was created the day the resource was deleted and the record was left behind.

How a domain name resolves to a server

How dangling records happen

The pattern is almost always a lifecycle mismatch: the cloud resource and the DNS record have different owners or different clocks. A developer decommissions a Heroku app; the DNS lives in a registrar account the marketing team manages. A GitHub Pages site is archived; the CNAME stays. An S3 bucket backing a subdomain is emptied and deleted; the alias record survives.

The takeover-prone providers are the ones that let you claim resource names freely and then serve content on a shared hostname. Static hosts, object storage, PaaS platforms, form and help-desk tools, and CDN configurations are the usual suspects, and the community-maintained "can I take over xyz" project catalogs which services are exploitable and what their fingerprints look like.

One variant is worth calling out because it is more dangerous: a dangling NS delegation. If a subdomain is delegated to a nameserver at a provider you no longer control, an attacker who claims that zone controls the entire subtree, not just one host. Those are rarer but far higher impact.

Detecting takeovers by hand

Manual detection has three steps: enumerate subdomains, resolve their records, and check whether any target is unclaimed. Certificate transparency logs are the fastest way to enumerate, every TLS certificate ever issued for a domain is public, so a search on a CT log surfaces subdomains that never appear in your own DNS zone file. Combine that with the records you already publish.

For each candidate, resolve the record and read where it points:

The tell is a CNAME that resolves to a provider hostname which itself returns an error page or fails to resolve. That gap, record present, resource absent, is the vulnerability. Open-source scanners can automate the fingerprint matching, but the underlying logic is exactly the three steps above, and you can spot-check any single record with a DNS checker in a browser.

dig +short CNAME promo.client.com, reveals the target hostname a subdomain aliases to
dig +short NS sub.client.com, reveals any delegation, the higher-risk case
curl -sI https://promo.client.com, the response often contains the provider's takeover fingerprint
Match the body or headers against known fingerprints like "NoSuchBucket", "There isn't a GitHub Pages site here", or a provider's "no such app" page

Scaling detection across many client domains

A one-time scan finds today's dangling records. It does nothing about the CNAME that goes dangling next month when a client's developer deletes an app. Across an agency's full portfolio, new dangling records appear continuously, and the window between "resource deleted" and "attacker claims it" is when you are exposed.

That turns detection into a monitoring problem. You want a recurring job that re-enumerates each client's subdomains, re-resolves every CNAME and NS record, and re-checks each target against the takeover fingerprints, then alerts you the moment a record starts pointing at something unclaimed. The same job naturally catches DNS drift generally: an unexpected record change, a delegation that appeared overnight, a CNAME that moved. If you want a refresher on the record types involved, DNS records explained covers CNAME, NS and the rest.

For agencies specifically, the practical unit is per-client: a clean inventory of every domain, continuous re-scanning, and alerts routed to whoever owns that account. That is the model behind domain and DNS monitoring for agencies.

Remediation and prevention

Fixing a live takeover is immediate: delete the dangling DNS record, or re-claim the resource at the provider so it is under your control again. Deleting the record is almost always the right move, if the subdomain is no longer used, it should not resolve at all.

Preventing the next one is a process change. Decommissioning any cloud resource should include removing its DNS record in the same ticket, so the record and the resource die together. Where you can, prefer records that fail closed rather than dangling. And because human process leaks, back it with monitoring that assumes some records will always slip through, the goal is to catch the gap in hours, not after an attacker has already published a phishing page on your client's domain.