What is a subdomain takeover?

A DNS record still points at a third-party resource that has been deleted. Anyone who can create that resource name on the same platform then serves content from your subdomain — with a valid certificate they can obtain themselves.

High. It enables convincing phishing on your own domain, cookie theft where cookies are scoped to the parent domain, and bypass of same-site protections. It is a routine high-severity bounty finding.

How do I fix a dangling record?

Delete the DNS record, or reclaim the resource on the provider so the name resolves to something you control. Deleting the record is the safer default.

Can this happen with A records too?

Yes, when an address is released back to a cloud provider's pool and reassigned to another tenant. CNAMEs to named services are the more common and more easily exploited case.

TLS & Email🌐 YAS server-sideAPI availableadvanced

Dangling CNAME Takeover Checker

Inspects DNS CNAME records for dangling pointers to unclaimed cloud services (AWS S3, GitHub Pages, Vercel, Azure) to prevent subdomain takeover.

Processed by YAS · not stored

Ready to runInstant execution

All tools →

Result

—

What does this tool do?

Inspects DNS CNAME records for dangling pointers to unclaimed cloud services (AWS S3, GitHub Pages, Vercel, Azure) to prevent subdomain takeover.

Why would I use it?

You decommissioned a cloud service (e.g. S3 bucket, Vercel app) but forgot to delete the DNS CNAME record.
You want to prevent attackers from claiming the dangling resource and hosting phishing attacks on your domain.
You are conducting external perimeter security hygiene audits.

Real-life example

Input

Domain: assets.example.com, CNAME: my-bucket.s3.amazonaws.com

Output

Status: VULNERABLE (CRITICAL) · Fingerprint: NoSuchBucket · Provider: Amazon Web Services (S3)

Action needed: Claim the S3 bucket or remove the DNS CNAME record immediately.

Input → Process → Output → Next

Input: Enter domain name or specific CNAME target hostname.
Process: Queries DNS, resolves CNAME target, and inspects HTTP response signatures against known takeover patterns.
Output: Risk level (CRITICAL / HIGH / SAFE), provider identification, and remediation instructions.
Next action: Remove the dangling CNAME from your DNS control panel.

Common mistakes

Leaving orphaned CNAME records pointing to third-party services after canceling subscriptions.
Assuming internal subdomains cannot be taken over if the root domain is secure.
Not monitoring DNS records continuously for configuration drift.

What the result means

An assessment of whether a subdomain's DNS pointer can be hijacked by unauthorized third parties.

Privacy & security

Your input is sent to YAS infrastructure because the tool requires server-side processing or public network queries. Input is not stored.

API

Endpoint

POST https://yas.sh/api/v1/tools/dangling-cname-checker

Request Header

Content-Type: application/json

cURL

curl -X POST "https://yas.sh/api/v1/tools/dangling-cname-checker" \
  -H "Content-Type: application/json" \
  -d '{"domain":"assets.example.com","cnameTarget":"my-bucket.s3.amazonaws.com"}'

JavaScript

const res = await fetch("https://yas.sh/api/v1/tools/dangling-cname-checker", {
  method: "POST",
  headers: { "Content-Type": "application/json" },
  body: JSON.stringify({
  "domain": "assets.example.com",
  "cnameTarget": "my-bucket.s3.amazonaws.com"
}),
});
const data = await res.json();

Python

import requests

r = requests.post("https://yas.sh/api/v1/tools/dangling-cname-checker", json={"domain":"assets.example.com","cnameTarget":"my-bucket.s3.amazonaws.com"})
data = r.json()

Field	Type	Required	Description
domain	string	Yes	Domain name
cnameTarget	string	No	Optional CNAME target hostname

Success response

{ "slug": "dangling-cname-checker", "isDangling": false, "riskLevel": "SAFE" }

Inspect DNS CNAME records for dangling pointers to S3, GitHub and Vercel.

Error responses

400 VALIDATION_ERROR — invalid input or unsupported option.
413 PAYLOAD_TOO_LARGE — input exceeds the 64 KB limit.
429 RATE_LIMIT_EXCEEDED — rate limit exceeded (60 req/min).

Limits

Maximum input: 64 KB per request.
Rate limit: 60 requests/min per IP address.
Authenticated accounts benefit from higher tier quotas.

How Dangling CNAME Takeover Checker works

Subdomain takeover happens when a DNS record points at a third-party service that no longer claims the name. The classic pattern is a CNAME to a cloud provider — an S3 bucket, a Heroku app, a GitHub Pages site, a Vercel or Azure endpoint — that has since been deleted. The DNS record survives the resource, and anyone who can register that resource name on the same platform then controls content served at your subdomain.

Detection resolves the CNAME chain to its target and looks for provider-specific fingerprints in the response: the distinctive 404 body S3 returns for a missing bucket, GitHub Pages' unclaimed-domain page, Heroku's no-such-app response. Each platform has its own signature, and each has its own claim policy — some now require domain verification, which closes the vulnerability, while others still allow first-come registration.

When to use it: real-world scenarios

Auditing DNS after decommissioning a service

Deleting the cloud resource without deleting the DNS record is the exact sequence that creates the vulnerability, and it happens on every cleanup.

Checking inherited or acquired domains

Domains obtained through acquisition carry years of records for services nobody currently operates or remembers.

Triaging a bug bounty report

Subdomain takeover is among the most commonly reported findings. Verifying the fingerprint confirms whether it is genuinely claimable.

Continuous monitoring of a large zone

In an organisation where many teams create records, periodic scanning is the only way to keep pace with decommissioning.

Pro tips

Delete the DNS record before the resource, not after. Reversing the order is what creates the window.
Treat this as high severity: an attacker serving content on your subdomain can obtain a valid TLS certificate for it, receive cookies scoped to the parent domain, and abuse your brand for phishing.
Scope cookies to the exact host, never to the parent domain, so a compromised subdomain cannot read sessions from the main site.
Keep an inventory of records mapped to owning teams. Most dangling records exist because nobody knew who created them.

Limitations and edge cases

What this tool deliberately does not do, and where it will disagree with other implementations.

Fingerprints cover common providers; a service not in the signature set may be missed.
Some platforms now require domain verification before claiming, so a dangling record there is stale rather than exploitable — the tool flags it either way.
A positive result should be confirmed manually before being reported as exploitable.
Records inside private or split-horizon DNS are not visible to a public checker.

Frequently asked questions

What is a subdomain takeover?: A DNS record still points at a third-party resource that has been deleted. Anyone who can create that resource name on the same platform then serves content from your subdomain — with a valid certificate they can obtain themselves.
How serious is it?: High. It enables convincing phishing on your own domain, cookie theft where cookies are scoped to the parent domain, and bypass of same-site protections. It is a routine high-severity bounty finding.
How do I fix a dangling record?: Delete the DNS record, or reclaim the resource on the provider so the name resolves to something you control. Deleting the record is the safer default.
Can this happen with A records too?: Yes, when an address is released back to a cloud provider's pool and reassigned to another tenant. CNAMEs to named services are the more common and more easily exploited case.