Subdomain takeover and dangling DNS

1 Introduction

Your marketing team launches a campaign site on a hosting platform and points promo.example.com at it. Months later the campaign ends and the hosting account is closed. Nobody touches the DNS: the record still points at the platform, but now at a name nobody owns.

Anyone can open an account on that platform and claim the same name. From then on, they decide what promo.example.com shows: a phishing page under your own domain, with a valid HTTPS padlock, able to read cookies scoped to .example.com. That is a subdomain takeover, and the forgotten record behind it is called dangling DNS.

Forgotten DNS record is all it takes, no server to break into

HTTPS

The attacker can get a valid certificate, because they now control the name

.example.com

Cookies set for the parent domain are sent to the hijacked subdomain too

2 How It Works

A takeover always follows the same four steps. The root cause is an order of operations: the resource was deleted before the DNS record pointing at it.

promo.example.com CNAME example-promo.hosting.app

The hosting project is deleted. The CNAME stays.

An attacker finds it (certificate logs, DNS scans) and registers example-promo on the platform.

Your subdomain now serves the attacker's content.

How scanners spot it

Each platform answers an unclaimed name with a recognisable page or error: NoSuchBucket on Amazon S3, "There isn't a GitHub Pages site here", "No such app" on Heroku, and so on. A scanner follows your CNAMEs, compares the answer with these fingerprints, and only flags the services where claiming a free name is still possible. The community project can-i-take-over-xyz tracks which providers are still exploitable.

3 Detailed Analysis

A domain scan reports three related findings. They differ in how close they are to a working attack.

Subdomain takeover: a CNAME to an unclaimed service

What it means

A subdomain points to a cloud or SaaS resource that no longer exists, on a platform that lets anyone claim the name. This is the most urgent of the three: exploitation takes minutes.

What to do now

Delete the DNS record, or reclaim the resource yourself if the service is still needed. Then check the subdomain's recent content and access logs, if any, in case someone got there first.

Commonly affected

Storage buckets, static hosting and app platforms (S3, Azure App Service and Cloud Services, GitHub Pages, Heroku), shop and helpdesk builders. Several providers now ask for ownership verification, which is why a scanner checks the provider before flagging.

Dangling delegation: NS or MX pointing at something you do not control

Delegation to a deleted DNS zone

dev.example.com NS ns-123.awsdns-45.com once handed the subdomain to a hosted zone at a DNS provider. If that zone was deleted, an attacker can create a new one there for the same name and, on some providers, land on the same name servers. They then control every record under that subdomain, mail included.

Records pointing at an expired domain

A name server, MX or CNAME target like ns1.old-agency.com is only as safe as old-agency.com. If that domain expires, whoever re-registers it inherits your delegation. Check the registration of every external domain your zone relies on.

What to do

Remove the delegation or the record, or point it back at infrastructure you control. Treat it with the same urgency as a takeover: the impact is often larger.

Ghost subdomains: names that used to exist

What it means

Every TLS certificate is published in public Certificate Transparency logs. A ghost is a subdomain that appears in those logs but no longer resolves or no longer answers. On its own it is not a vulnerability.

Why it is reported

Ghosts are where decommissioned services lived, which is exactly where dangling records are usually found, and they are the first list an attacker builds. They can also reveal internal names (vpn-old, jira-staging) you would rather not publish.

What to do

Review the list once: confirm no record still points anywhere for each name, and that nobody plans to re-create it pointing at a third party. Nothing to fix if the name is fully gone.

Preventing it for good

Delete DNS first, the resource second. Put it in your decommissioning checklist. The reverse order is what opens the window.

Keep DNS in code (Terraform, OctoDNS) next to the resources it points at, so deleting one deletes the other.

Scan regularly. Teams create subdomains faster than anyone reviews them; a periodic scan catches the record left behind.

Find dangling records on mlab.sh

A domain scan enumerates your subdomains, follows their records and flags takeovers, dangling delegations and ghost subdomains.

Scan your domain on mlab.sh

4 Red Flags

A subdomain that shows a provider's "not found" page

"NoSuchBucket", "There isn't a GitHub Pages site here", "No such app": if one of your names answers like this, assume someone else can claim it today.

NS records for a subdomain nobody remembers

A delegated subdomain is a whole zone outside your main DNS. If no team owns it, check that the zone still exists at the provider.

Records that depend on an agency's or supplier's domain

When the contract ends, their domain may lapse. Your records pointing at it become someone else's to answer.

Session cookies scoped to the whole domain

A cookie set for .example.com is sent to every subdomain, hijacked ones included. Scope session cookies to the exact host that needs them.

No decommissioning procedure

If closing a cloud project does not include "remove its DNS records", takeovers will keep coming back, whatever you clean up today.

Related Modules

What is DNS?

The Internet's phone book: how DNS translates domain names into IP addresses.

What is a domain?

Human-readable names: how domains translate IP addresses into easy-to-remember names.

HTTP security headers explained

HSTS, CSP, X-Frame-Options, cookie flags: what each header blocks, what a missing one means in a scan, and a safe configuration to start from.