Subdomain Takeover: What It Is and How to Prevent It

Subdomain takeover is one of the most common and preventable security vulnerabilities on the internet. It happens when a DNS record points to a service that no longer exists -- and an attacker claims that service before you notice. Here is how it works, why it is dangerous, and how to protect your domains.

What Is a Subdomain Takeover?

A subdomain takeover occurs when a DNS record -- typically a CNAME -- points to an external service that has been deprovisioned or deleted. The DNS record still exists, but the service it points to no longer belongs to you. An attacker can then register that same service and take control of your subdomain.

Here is a concrete example. Your marketing team sets up a landing page at promo.yourcompany.com using a service like Heroku, GitHub Pages, or Netlify. They create a CNAME record:

promo.yourcompany.com.  CNAME  yourcompany.herokuapp.com.

Six months later, the campaign ends. Someone deletes the Heroku app but forgets to remove the DNS record. Now promo.yourcompany.com is a dangling CNAME -- it points to yourcompany.herokuapp.com, which no longer exists.

An attacker discovers this, creates a new Heroku app with that exact name, and now controls what appears at promo.yourcompany.com. They can serve phishing pages, steal cookies set on your parent domain, or host malware -- all under your trusted domain name.

Why Subdomain Takeover Is Dangerous

The impact goes far beyond a rogue web page. Here is what an attacker can do once they control a subdomain:

Which Services Are Vulnerable?

Not every external service is vulnerable to subdomain takeover. The risk depends on whether a deprovisioned service name can be re-registered by someone else. Here are common services and their takeover risk:

Service Risk Level Why
GitHub Pages High Anyone can create a repo matching the CNAME target
Heroku High App names are globally unique and re-registrable
AWS S3 High Bucket names are globally unique and re-creatable
Azure Medium Some services allow name re-registration
Shopify Medium Custom domains can be claimed by new stores
Cloudflare Low Requires domain ownership verification
Google Cloud Low Requires domain verification for custom domains

How to Detect Dangling DNS Records

The key to preventing subdomain takeover is finding dangling DNS records before attackers do. Here is how:

1. Audit your DNS records regularly

Use a DNS lookup tool to enumerate all records for your domain. Look for CNAME records that point to external services. For each one, verify that the target service is still active and under your control.

2. Check for NXDOMAIN responses

If a CNAME target returns NXDOMAIN (the domain does not exist), that is a dangling record. You can check this with a simple dig command:

dig promo.yourcompany.com CNAME +short
# Returns: yourcompany.herokuapp.com

dig yourcompany.herokuapp.com A +short
# If this returns NXDOMAIN or no result, the record is dangling

3. Use automated scanning

Manual audits do not scale. If you manage more than a handful of domains, you need automated DNS monitoring that continuously checks your records and alerts you when a CNAME target becomes unreachable. Scanward's DNS scanner checks for dangling CNAMEs as part of every scan and flags them as critical findings.

4. Monitor certificate transparency logs

If an attacker takes over your subdomain and requests an SSL certificate for it, that certificate will appear in public Certificate Transparency (CT) logs. Monitoring CT logs for certificates issued to your subdomains can catch takeovers that have already happened.

How to Prevent Subdomain Takeover

Prevention is straightforward once you have the right processes in place:

Delete DNS records when deprovisioning services

This is the most important step. Every time you remove an external service, delete the corresponding DNS record immediately. Do not leave it for later. Make DNS cleanup part of your decommissioning checklist.

Use a DNS change management process

Treat DNS records like infrastructure code. Use version control for zone files, require approval for changes, and maintain an inventory of which records map to which services. If you use DNSSEC, changes are already going through a more controlled process.

Restrict wildcard DNS records

A wildcard record (*.yourcompany.com) means every possible subdomain resolves -- even ones you never created. If the wildcard points to a service that accepts any hostname, attackers can use arbitrary subdomains. Avoid wildcard records unless you have a specific need and understand the implications.

Set restrictive cookie scoping

Do not set cookies with Domain=.yourcompany.com unless absolutely necessary. Use the most specific domain possible for cookies, especially session and authentication cookies. This limits the damage if a subdomain is compromised.

Implement continuous DNS monitoring

The gap between deprovisioning a service and an attacker claiming it can be as short as hours. Continuous monitoring catches dangling records before attackers scan for them. Scanward checks for dangling CNAMEs, missing records, and DNSSEC configuration on every scan -- free for your first domain.

Scan your domain for dangling DNS records

Scanward's free scanner checks for dangling CNAMEs, DNSSEC status, and other DNS security issues. Get results in 30 seconds.

Scan Your Domain Free →

What to Do If You Have Been Taken Over

If you discover that one of your subdomains has been taken over, act immediately:

  1. Delete the DNS record. This is the fastest way to stop the attack. Remove the CNAME (or A record) that points to the attacker-controlled service.
  2. Check for issued certificates. Search Certificate Transparency logs (crt.sh) for certificates issued to the affected subdomain. If any were issued to the attacker, report them to the certificate authority for revocation.
  3. Review cookie exposure. If your application sets cookies on the parent domain, rotate session secrets and force re-authentication for all users.
  4. Check email authentication. Review your SPF records and DMARC policy to ensure the compromised subdomain was not able to send authenticated email.
  5. Audit all other DNS records. If one subdomain was dangling, others might be too. Run a full DNS audit immediately.

Key Takeaways

Subdomain takeover is a preventable vulnerability that stems from a simple operational gap: forgetting to clean up DNS records when you decommission a service. The fix is equally simple -- delete the record when you delete the service, and monitor your DNS continuously to catch any that slip through.

For organizations managing multiple domains and subdomains, automated external attack surface monitoring turns this from a manual checklist item into a continuous, automated process. Scanward's DNS scanner flags dangling CNAMEs and other DNS security issues on every scan, so you find them before attackers do.

Monitor your domains for subdomain takeover risks

Scanward continuously scans your DNS records for dangling CNAMEs, missing DNSSEC, and other security gaps. Free for your first domain.

Start Monitoring Free →