Subdomain Takeover: When Dangling DNS Records Become Attack Surface

A DNS record is a statement of intent: this subdomain resolves to this resource. When the resource disappears but the record remains, the statement becomes a lie — and in that gap between what DNS says and what exists, an attacker can insert themselves.

Subdomain takeover is not a sophisticated attack. It requires no zero-days, no social engineering, and often no special access. It requires only a dangling DNS record and the ability to claim the external resource it points to. The result is an attacker serving content from a subdomain that belongs to someone else, under a domain name the browser fully trusts.

How DNS Records Create Takeover Opportunities

The typical case involves a CNAME record. A CNAME is an alias: when a browser queries staging.example.com, the DNS resolver follows the CNAME to its target — perhaps example-staging.somecloud.io — and resolves that instead. The browser then connects to somecloud.io while the address bar shows staging.example.com.

This indirection is useful. It lets organizations deploy to cloud platforms, CDNs, and SaaS services without managing IP addresses directly. It lets them update where a subdomain points without touching their own infrastructure.

The problem appears at teardown. When the team decides they no longer need the staging environment, they delete the example-staging.somecloud.io resource — the cloud instance, the bucket, the CDN distribution. They do not always delete the DNS record.

The CNAME remains. It still resolves. But the external resource it pointed to is now unclaimed.

Many cloud providers allow any customer to claim a resource name. If example-staging.somecloud.io is unregistered, an attacker can create an account and register it. Now when a browser follows the CNAME from staging.example.com, it reaches the attacker's cloud resource. The attacker controls what the browser receives. But the domain name in the address bar — staging.example.com — belongs to the victim.

Common Takeover Vectors

Cloud Storage Buckets

Storage services like S3, GCS, and Azure Blob issue globally unique bucket names. When an organization creates example-assets.s3.amazonaws.com and points assets.example.com at it via CNAME, then later deletes the bucket, the CNAME persists. The bucket name is now available to anyone.

S3 makes the unclaimed state explicit. Querying a CNAME that resolves to a nonexistent bucket returns:

<Error>
  <Code>NoSuchBucket</Code>
  <Message>The specified bucket does not exist</Message>
  <BucketName>example-assets</BucketName>
</Error>

An attacker who sees this response knows the bucket is claimable. They create an S3 bucket with the same name, enable static website hosting, and begin serving content from assets.example.com.

PaaS and Hosting Platforms

Platform-as-a-service providers typically assign unique subdomains to each application. Heroku assigns appname.herokuapp.com. GitHub Pages uses org.github.io. Netlify uses sitename.netlify.app.

When an application is deleted or a Pages site is removed, the external subdomain becomes unregistered. Any attacker can create a new application with the same name and receive traffic that was meant for the deleted application.

Heroku's indicator: There is no app configured at this URL.
GitHub Pages: a 404 served from GitHub's own infrastructure rather than the expected content.
Netlify: Not Found - Request ID: responses when the site record no longer exists.

Each platform has its own unclaimed state signature. Knowing these signatures is how testers quickly identify vulnerable subdomains at scale.

CDN Distributions

Content delivery networks often assign customer-specific endpoints: d123456789.cloudfront.net, contoso.azureedge.net, customer.fastly.net. Organizations point their subdomains at these endpoints via CNAME.

If the CDN distribution is deleted without removing the DNS record, the CNAME points to a former endpoint. Depending on the CDN provider's policies, an attacker may be able to create a new distribution that claims the same endpoint hostname, or the provider's edge nodes may allow any customer to serve on unclaimed CNAMEs.

SaaS Platform Tenants

Many SaaS platforms support custom domains. A customer configures support.example.com to point at their Zendesk tenant at example.zendesk.com. If they cancel the subscription without removing the custom domain configuration and DNS record, the CNAME persists.

Depending on the platform, a new customer who registers example.zendesk.com may begin receiving traffic intended for support.example.com.

The Impact of a Successful Takeover

Why does it matter that an attacker controls content on someone else's subdomain? The answer lies in how browsers enforce the same-origin policy.

Trusted domain, attacker content. The address bar shows staging.example.com. The browser displays no warning. To a visitor, this is indistinguishable from a legitimate page. Phishing pages under the organization's own domain are far more effective than lookalike domains — there is no typosquatting to notice, no certificate mismatch, no unusual TLD.

Cookie access. Cookies can be scoped to a domain (.example.com) rather than a specific subdomain. JavaScript running on a subdomain can read cookies scoped to the parent domain if HttpOnly is not set. An attacker who controls staging.example.com can potentially harvest session cookies from authenticated users who visit that subdomain.

Content Security Policy bypass. Organizations often configure CSP to trust their own subdomains: script-src 'self' *.example.com. A compromised subdomain satisfies this rule. Scripts loaded from cdn.example.com after a takeover are permitted by a CSP that was written to be permissive only within the organization's own infrastructure.

SameSite bypass. The SameSite cookie attribute restricts cross-site requests. Requests from attacker.example.com to app.example.com are same-site — they originate from the same registrable domain. This means SameSite protections do not apply to cross-subdomain attacks.

OAuth and SSO abuse. Authorization servers often whitelist redirect URIs by domain. A wildcard like *.example.com in a redirect URI allowlist means a subdomain takeover provides a valid OAuth callback endpoint. An attacker can construct authorization flows that redirect tokens to stolen.example.com.

Finding Vulnerable Subdomains

Subdomain takeover assessment follows a methodical process:

Step 1: Enumerate subdomains. Certificate transparency logs (available through public search interfaces) record every certificate issued for a domain, including SANs that expose subdomains. DNS brute-forcing with common wordlists discovers subdomains that were not captured in certificates. Passive DNS databases maintain historical records of what a domain's subdomains resolved to.

Step 2: Resolve each subdomain. For each discovered subdomain, check whether it resolves and what it resolves to. CNAME chains should be followed to their final destination.

Step 3: Identify dangling records. A subdomain that fails to resolve (NXDOMAIN on the CNAME target), returns an HTTP error specific to the external service, or displays a known unclaimed-state page is a candidate.

Step 4: Assess claimability. Not every dangling record is exploitable. Some platforms do not allow arbitrary customers to claim specific resource names. Some require domain verification. Others freely permit first-come-first-served registration of any unclaimed name. Claimability must be confirmed for each finding before claiming impact.

# Check if a CNAME target resolves
dig CNAME staging.example.com
# Returns: staging.example.com. CNAME example-staging.somecloud.io.
 
# Check if the CNAME target itself resolves
dig A example-staging.somecloud.io
# Returns NXDOMAIN — the target no longer exists

A CNAME that resolves to NXDOMAIN is a strong indicator. The next step is to manually visit the subdomain over HTTP/HTTPS to observe what response the provider returns.

CNAME vs. NS Delegation Takeovers

While CNAME-based takeovers are the most common, NS delegation presents an even more severe variant.

When an organization delegates a subdomain to a third-party DNS provider — using NS records like ns1.cloudprovider.io — and later terminates that account without removing the NS delegation, the subdomain's DNS resolution is entirely under whoever claims that provider account.

An attacker who registers the abandoned account can create any DNS records they want for the delegated subdomain: A records, MX records, TXT records. They can configure custom hostnames, create mail servers that receive email on the subdomain, and perform domain verification for any service that accepts DNS-based proof of ownership.

NS delegation takeovers are rarer than CNAME takeovers but higher impact. They grant complete control over all DNS for the affected subdomain tree.

Prevention and Remediation

Include DNS in teardown checklists. Every time an external service is deprovisioned — a cloud resource deleted, a SaaS subscription cancelled, a CDN distribution removed — the corresponding DNS records must be audited. This should be a mandatory step, not an afterthought.

Remove records before deprovisioning the resource. If the DNS record is removed first, there is a brief window during propagation where the subdomain is unresolvable but no window where an attacker can claim the external resource and serve content. Removing the external resource first and then the DNS record later creates the vulnerability gap.

Conduct periodic DNS audits. Enumerate all DNS records and verify that each one resolves to a resource that the organization controls or legitimately uses. CNAME chains should be followed to their endpoints. Records pointing to expired or unrecognized external resources should be investigated.

Monitor for unclaimed state responses. Automated monitoring that checks subdomains for known takeover fingerprints — NoSuchBucket, There is no app configured, Heroku's 404 page — can detect the condition before an attacker does.

Avoid wildcard NS delegations. Delegating entire subdomain trees to third-party DNS providers increases the blast radius if those accounts are ever cancelled or compromised. Prefer granular delegation and maintain records of what was delegated where.

Key Takeaways

Subdomain takeover is an infrastructure hygiene problem dressed up as a security vulnerability. The technical mechanism is simple: DNS points to a resource; the resource disappears; an attacker claims it. The consequences scale with what that subdomain was trusted to do.

Organizations that build on cloud services accumulate DNS records over time. Subdomains get created for staging environments, marketing campaigns, third-party integrations, and internal tools. When those things end, the infrastructure is torn down — but DNS is often forgotten. The record outlives the resource it described.

Regular DNS audits and teardown checklists that include DNS record cleanup are the primary defenses. The vulnerability cannot be exploited if the dangling record does not exist.

Want your DNS infrastructure assessed for takeover-vulnerable records? Get in touch.