Subdomain takeover: detection and prevention

How a takeover happens

Teams point subdomains at hosted services all the time: docs.example.com to a static site host, shop.example.com to an e-commerce platform, assets.example.com to a storage bucket. The DNS record is usually a CNAME to a name the provider assigned, such as example-docs.hosting.example.net. When the service is cancelled, the resource is deleted, but the CNAME often stays.

That leftover record is called dangling DNS. If the provider lets any customer create a resource with the same name, whoever claims it controls what docs.example.com serves. Browsers show your domain in the address bar, and many providers will even issue a valid TLS certificate for it.

Record types that can dangle

NS delegations are the most severe case. Control of the delegated zone means control of every record under it, including MX, TXT and verification records, not just a single web page. They are also rarer and easier to audit, because delegations to external name servers are unusual in most zones.

Why it matters

Content on a subdomain inherits trust that belongs to your organisation. Users see login.example.com and assume it is yours; security filters and allowlists that trust *.example.com let it through. The damage depends on what else trusts your domain name.

• Phishing with a genuine domain name and a valid certificate.
• Cookie theft when session cookies are set with Domain=example.com, which sends them to every subdomain.
• CSP and CORS bypass when policies allow https://*.example.com.
• OAuth and redirect abuse when allowed redirect URIs include wildcard subdomains.
• Email abuse through dangling MX or NS records, including receiving password reset mail for addresses on that name.
• Reputation damage when malware or spam is served from your domain and ends up on blocklists.

Finding dangling records in your zones

Start from your own authoritative data: zone exports from every DNS provider you use, including zones managed by other teams and by agencies. Scanning only the names you remember misses exactly the records that cause takeovers. Then check each record whose target is outside your control.

1. Export all zones and list every CNAME, NS, MX and A/AAAA record.
2. For CNAMEs, resolve the target. NXDOMAIN for the target, or a target under a domain that is not registered, is a strong signal.
3. For targets at hosting providers, request the subdomain over HTTPS and HTTP and look for the provider's "not found" or "no such site" page.
4. For NS delegations, query the delegated name servers directly for the subdomain's SOA; REFUSED or SERVFAIL suggests the hosted zone is gone.
5. For MX and CNAME targets under other domains, check with the WHOIS lookup whether those domains are still registered.
6. For A records into cloud ranges, confirm the IP is still assigned to your account.

# where does it point?
dig +short CNAME docs.example.com
example-docs.hosting.example.net.

# does the target still exist?
dig +short example-docs.hosting.example.net A
dig example-docs.hosting.example.net A | grep -E 'status: (NXDOMAIN|NOERROR)'

# what does the subdomain serve?
curl -sS -o /dev/null -w '%{http_code}\n' https://docs.example.com/

The DNS Lookup and DNS Lookup tools show the CNAME and its resolution from outside your network, and the HTTP Headers Checker shows the response and server headers of the subdomain. A community-maintained project on GitHub, "can-i-take-over-xyz", documents which providers are known to allow claims of deleted resource names and how their error pages look.

If you find one

Remove the dangling record, or point it at something you control, as the first step. Removing the record ends any takeover immediately once caches expire, whether or not someone has already claimed the resource. Do not try to claim the resource at the provider as a test; fix your own DNS instead.

1. Delete or correct the DNS record.
2. If the subdomain served someone else's content, record what it served and when, for your incident process.
3. Revoke certificates issued for the subdomain if you can identify them, for example through certificate transparency logs.
4. Invalidate sessions if cookies were scoped to the parent domain.
5. Review allowlists, CSP and OAuth settings that trusted the subdomain.
6. Find out how the record was left behind and fix that process.

Tell users if the subdomain was used for phishing or served login pages. A short, factual notice with the dates and what to do, such as resetting passwords entered there, limits the damage more than silence does.

Certificate transparency logs are useful for the investigation: every publicly trusted certificate is logged, so a certificate for your subdomain issued to someone else is visible there. Monitoring CT logs for your domain also gives early warning of takeovers you have not found yet.

Preventing takeovers

Delete DNS first, resources second

When decommissioning, remove the DNS record before deleting the cloud or SaaS resource, and wait for the TTL. Reversing that order creates a window, sometimes permanent, in which the record points at a free name. Put this order into runbooks and infrastructure-as-code pipelines.

Manage DNS as code

When DNS records live in the same repository as the infrastructure they point at, removing a resource and its record happens in one change. Reviews also make it obvious when someone adds a CNAME to an external service, with an owner attached.

Use provider domain verification

Many platforms let you prove ownership of a custom domain with a TXT record before they serve it. Where a provider supports this, a new customer cannot attach your subdomain to their resource without also controlling your DNS. Prefer providers that require it.

Inventory and scan continuously

• Keep an owner and purpose for every externally pointing record.
• Scan all zones on a schedule for the signals in the table above.
• Include expired-domain checks for CNAME, MX and NS targets.
• Watch certificate transparency logs for unexpected certificates on your names.
• Avoid wildcard DNS records that point at shared hosting platforms.

Domain migrations and vendor changes are the moments when dangling records are created most often. The domain migration checklist includes the clean-up step, and the CSP guide explains why wildcard subdomain allowlists deserve a second look.

Automating the scan

A small script run weekly against your zone exports catches most dangling CNAMEs. It resolves each target and flags those that no longer exist. It deliberately makes no requests to claim anything and does not probe other people's systems beyond ordinary DNS lookups.

import dns.resolver

records = [
    ("docs.example.com", "example-docs.hosting.example.net"),
    ("status.example.com", "example.status.example.org"),
]

resolver = dns.resolver.Resolver()
resolver.lifetime = 5
for name, target in records:
    try:
        resolver.resolve(target, "A")
        state = "ok"
    except dns.resolver.NXDOMAIN:
        state = "DANGLING: target does not exist"
    except dns.resolver.NoAnswer:
        state = "check: target has no A record"
    except dns.exception.DNSException as error:
        state = f"check: {error.__class__.__name__}"
    print(f"{name:<28} -> {target:<40} {state}")

A target that resolves is not automatically safe, because many platforms answer for every name under their domain and show an error page for unclaimed ones. Extend the scan with an HTTP request to each subdomain and a list of the error page texts of the providers you use. Treat every hit as a ticket for the record's owner.

Preview environments and wildcards

Modern delivery pipelines create short-lived environments, such as a preview site per pull request at pr-123.preview.example.com. When the pipeline creates DNS records automatically, it must also remove them when the environment is destroyed, including when a job fails half-way. Otherwise records accumulate faster than any manual review can keep up with.

Wildcard records like *.preview.example.com pointing at a shared platform avoid per-environment records but carry their own risk: every name under the wildcard points at the platform, whether or not you created a resource for it. Use wildcards only on platforms that require domain ownership verification for custom hosts, and keep them on a dedicated subdomain rather than your main domain.

Who owns the problem

Takeovers sit between teams: DNS is often run by infrastructure or IT, while the cancelled service belonged to marketing, documentation or a product team. Nobody feels responsible for a record they did not create. Assigning an owner to every external record, and making DNS clean-up part of cancelling any vendor contract, closes that gap.

A lightweight register of external records works well in practice: the record name, the target, the service, the owning team and the contract or ticket that created it. When a contract ends, procurement or the service owner triggers removal of the listed records. The register also answers the first question in any incident, which is who is responsible for the name.

Security teams can help with regular scans and by treating dangling records as vulnerabilities with a severity and a deadline. Bug bounty programs report many takeovers each year, which shows how common the problem is, and how cheap it is to prevent compared with handling a phishing incident on your own domain.

FAQ

Sources

• OWASP Web Security Testing Guide, WSTG-CONF-10: Test for Subdomain Takeover
• Microsoft Learn: Prevent dangling DNS entries and avoid subdomain takeover
• RFC 6265: HTTP State Management Mechanism (cookie Domain attribute)
• RFC 6962: Certificate Transparency
• can-i-take-over-xyz (community list of provider behaviour)