Subdomain takeover and dangling DNS records

A subdomain takeover happens when one of your own DNS records still points at a cloud resource that no longer exists, and an attacker claims that resource to serve their content on your real subdomain. Because it lives on your legitimate domain, it bypasses lookalike detection entirely. Here is how it works and how to shut it down.

What is a subdomain takeover?

A subdomain takeover is the result of a dangling DNS record. A DNS record, usually a CNAME but sometimes an A record, still points at a third-party cloud resource that has been deprovisioned. Common examples include an Amazon S3 bucket, an Azure App Service or Traffic Manager profile, a Heroku app, a GitHub Pages site, or a SaaS endpoint that has been deleted. The DNS entry survives, but the thing it points to is gone.

An attacker who notices the dangling record simply re-registers or claims that resource: they create an S3 bucket with the same name, register the same GitHub Pages repository, or spin up the same Azure resource in their own subscription. The provider now routes your subdomain to their content. From that moment, blog.yourcompany.com or promo.yourcompany.com serves whatever the attacker wants.

Why a dangling CNAME is so dangerous

This is not a lookalike domain. It is your real domain, so the consequences are severe:

• It bypasses lookalike detection. Tools that hunt for typosquats and confusingly similar names never flag it, because the spelling is exactly correct. See what typosquatting is for the contrast.
• It inherits full trust. Customers, employees, and email filters already trust your domain. Links look authentic because they are.
• It gets valid TLS. The attacker can request a publicly trusted certificate for your subdomain through normal domain validation, so the browser shows a padlock and no warning.
• It can steal scoped cookies. Content served from a subdomain can read or set cookies scoped to the parent domain, enabling session theft and convincing single-sign-on phishing.

How it happens

The root cause is process, not a software flaw. Teams spin up cloud resources for a campaign, a demo, a staging site, or a vendor integration, point a subdomain at the resource, and later tear the resource down. The DNS record is the step everyone forgets. Marketing closes a campaign, an engineer deletes a Heroku app, a contractor offboards, and the CNAME quietly lives on. The larger and faster-moving the organization, the more orphaned records accumulate.

How to find dangling records

• Inventory your CNAMEs. Pull a full list of DNS records and flag every CNAME and A record that points at a third-party service rather than your own infrastructure.
• Fingerprint the responses. Request each subdomain and look for the provider error pages that indicate an unclaimed resource, such as S3's NoSuchBucket or GitHub's "There isn't a GitHub Pages site here." A 404 from a known SaaS host on a record you still publish is the tell.
• Check for deprovisioned targets. If the CNAME target itself no longer resolves, the record is dangling and should be removed regardless of provider.
• Monitor DNS for change. Watch your own zones so a record added during a project surfaces for review later, instead of being forgotten.

Common vulnerable services and their fingerprints

Fingerprints change over time and providers add their own protections, so treat the table as a starting point rather than a fixed list.

How to fix and prevent it

• Remove or repoint the record. If the resource is genuinely retired, delete the DNS entry. If it should still exist, repoint it at a resource you control.
• Reclaim the resource first if needed. Where possible, re-create the bucket or app under your own account before deleting DNS, so no window exists for an attacker.
• Tear down in the right order. Make "remove the DNS record" a required step when decommissioning any cloud resource, and ideally remove DNS before deleting the resource.
• Prefer provider domain locking. Many platforms let you verify domain ownership before serving content, which closes the takeover window.

How this differs from typosquatting

Typosquatting and other lookalike attacks are external: someone else registers a confusingly similar domain you do not own. Subdomain takeover is internal DNS hygiene: the vulnerable record is in your own zone. The defenses are different too. For lookalikes you monitor the outside world for new registrations and certificates. For subdomain takeover the primary fix is keeping your own DNS clean and removing stale records promptly.

VigilDNS focuses on external lookalike monitoring, so it is not a dedicated subdomain takeover scanner. That said, watching your own DNS records for changes and additions, which our platform records with full change history, helps you notice the orphaned records that lead to takeovers. The primary remedy remains removing the stale record. If a record's resource is gone, delete it today.

Frequently asked questions

Can a subdomain takeover get a valid TLS certificate?

Yes. Once an attacker controls the content served on your subdomain, they can pass domain-validation checks and obtain a publicly trusted certificate, so the browser shows a normal padlock with no warning.

Is an A record vulnerable, or only a CNAME?

Both can be. CNAMEs to third-party services are the most common case, but an A record left pointing at a released cloud IP address can be claimed by whoever next receives that IP from the provider.

How often should I audit for dangling records?

Treat DNS hygiene as continuous. At minimum, review records whenever a cloud resource is decommissioned, and run a periodic full audit of every CNAME and A record that targets an external service.

Keeping your own DNS clean stops takeovers, and watching the outside world stops lookalikes. Start with our free typosquat checker to see what is registered against your brand, then explore certificate transparency monitoring to catch new certificates as they appear.