Subdomain Takeover: How Dangling DNS Records Become Security Vulnerabilities

Subdomain takeover is a vulnerability that sits at the intersection of DNS management and cloud infrastructure. When a company provisions a cloud service (a CDN, a hosting platform, a SaaS tool) and points a subdomain at it via a CNAME record, then decommissions the service without removing the DNS record, they create a "dangling DNS" entry. An attacker can claim the abandoned service resource and begin hosting content under the company's own subdomain — with a valid TLS certificate.

How It Happens

The typical sequence:

1. Company creates staging.example.com pointing to example.github.io via CNAME
2. Company finishes using GitHub Pages for staging and deletes the GitHub Pages repository
3. Company forgets to remove the DNS CNAME record for staging.example.com
4. Attacker scans for dangling records, finds that staging.example.com → example.github.io but example.github.io returns a 404 from GitHub
5. Attacker creates a GitHub account named example and enables GitHub Pages — now controlling example.github.io
6. staging.example.com now serves the attacker's content, under the legitimate company domain, with a valid TLS certificate issued by GitHub Pages

Why This Is Serious

Subdomain takeover under a legitimate domain means:

• Phishing credibility: A login page served from login.yourcompany.com with a valid TLS certificate is indistinguishable from legitimate to most users — and passes most email security filters that check domain reputation
• Cookie theft: Cookies set with Domain=.yourcompany.com are sent to all subdomains — including one an attacker controls. An attacker who can receive requests to old-staging.yourcompany.com receives your session cookies.
• CSP bypass: If your CSP allowlists *.yourcompany.com, an attacker-controlled subdomain can serve malicious scripts that your application will execute
• Brand damage: Malicious or embarrassing content served under your domain reflects on your organization

Commonly Vulnerable Services

Platforms that are frequently involved in subdomain takeover due to their DNS-based provisioning model:

• GitHub Pages (*.github.io)
• Heroku (*.herokuapp.com)
• AWS S3 (*.s3.amazonaws.com, *.s3-website-*.amazonaws.com)
• AWS Elastic Beanstalk (*.elasticbeanstalk.com)
• Azure App Services (*.azurewebsites.net)
• Shopify (*.myshopify.com)
• Fastly, Zendesk, Surge.sh, Netlify

Detecting Dangling DNS Records

A CNAME record is dangling when it resolves to a hostname, but that hostname returns an error indicating the resource is not provisioned (as opposed to a legitimate 404 or 500).

Platform-specific indicators:

• GitHub Pages: Returns "There isn't a GitHub Pages site here"
• Heroku: Returns "No such app"
• AWS S3: Returns "NoSuchBucket"
• Shopify: Returns "Sorry, this shop is currently unavailable"

To audit your DNS:

# List all CNAME records for your domain
dig +short CNAME staging.yourcompany.com

# Check if the target is claimed
curl -sI https://staging.yourcompany.com | head -5

For large organizations with many subdomains, use dedicated tools like subjack, nuclei, or can-i-take-over-xyz (a public reference of known-vulnerable service signatures).

Prevention and Remediation

Remove DNS Records When Decommissioning

This is the most important practice. Make DNS record cleanup a required step in any decommissioning checklist. When you tear down a cloud service, remove the DNS record first — or immediately after.

Regular DNS Audits

Export all DNS records for your domains and periodically verify that every CNAME target is a live, provisioned service. Any that return "not found" or "not configured" responses are dangling and should be removed.

Avoid Wildcard CNAMEs

A wildcard CNAME (*.yourcompany.com → yourapp.someplatform.com) means that any subdomain that does not have a more specific record will inherit the CNAME. If the target becomes dangling, every unconfigured subdomain of your domain is potentially takeable.

Use TXT Record Verification

Some platforms (Heroku, Microsoft Azure) now require a TXT record verification step before allowing a custom domain to be added. This prevents an attacker from claiming your subdomain on those platforms even if your CNAME is dangling. Prefer platforms that implement this verification.

Monitor Subdomain Certificates

Certificate Transparency logs are public. Subscribe to CT log notifications for your domain at crt.sh or via a service like Facebook's Certificate Transparency monitoring. An unexpected certificate issued for one of your subdomains is a strong indicator that something has gone wrong.