Subdomain takeover prevention: find dangling DNS records

Subdomain takeover prevention comes down to one habit: never leave a DNS record pointing at something that no longer exists. When a record still points at a deleted cloud resource, someone else can claim that resource and serve their own content on your subdomain. OWASP calls it consistently one of the most reported findings in bug bounty programs, and says it stays common because it is an operational problem, not a clever one.

Building or testing something that has to be safe? Book a meeting with whitehatstoic: it builds web and mobile apps, tests web apps and AI systems for weak spots, and gives independent advice.

Subdomain takeover prevention starts with how a record goes stale

The OWASP Subdomain Takeover Prevention Cheat Sheet describes the basic mechanism in five steps.

1. A team creates a DNS record, for example blog.example.com as a CNAME to example-blog.herokuapp.com.
2. Months later the team removes the app but forgets the record, so the CNAME still points at a name that no longer exists.
3. An attacker creates a new app named example-blog, claims the hostname and controls what appears on blog.example.com.

OWASP puts the root cause in the gap between provisioning and DNS. Cloud resources are temporary and DNS records persist. The team that built the resource may not run DNS, and nothing links the two automatically.

The damage goes beyond a defaced page. The sheet lists what an attacker on your subdomain can do: steal session cookies scoped to the parent domain, get around a Content Security Policy that trusts *.example.com, host phishing pages on a domain your users trust, break OAuth and single sign-on flows that allow the subdomain as a redirect, get a valid TLS certificate for it, and receive email for it.

Which DNS records are at risk

Do not stop at CNAMEs. The sheet names four record types.

• CNAME records are the most common route. If the target name can be claimed, the subdomain can be taken.
• A records that point at a released IP address are at risk if the address is given to someone else, which happens when cloud IPs go back to the provider's pool.
• NS records that hand a subdomain to a third-party DNS provider are especially dangerous. If the account at that provider is closed, someone who opens a new account may be able to claim the zone and control every record under the subdomain.
• MX records that point at a retired mail service can let an attacker receive mail for the subdomain. That includes password reset mail, and the validation mail that some certificate authorities accept, so it can lead to a valid certificate for your subdomain.

Not every cloud service can be claimed. What matters is whether a new customer can take a name that a previous customer used. OWASP calls its provider table a snapshot and points to the community can-i-take-over-xyz repository for current behavior.

Retire services in the right order

The sheet is specific about the order for decommissioning a service. The common mistake is deleting the cloud resource first, which opens a window that lasts until someone notices the record.

The DNS record goes before the cloud resource.

The safe sequence is to redirect the subdomain or serve a maintenance page, update or remove the DNS record, wait for DNS to propagate (at least the TTL, which OWASP puts at typically 300 to 3600 seconds), and only then delete the cloud resource.

Deleting the record at once can cause trouble when other pages link to the subdomain or users bookmarked it. OWASP says pointing the record at a server you control that redirects to the main domain, or shows a maintenance page, removes the takeover risk while the move settles.

Keep an inventory and scan for dangling records

You cannot clean up records you do not know about. The sheet asks for a documented link between each DNS record and the resource it points to: what the record resolves to, which team owns it, which project it belongs to, when it was created and when it should end, and why the subdomain exists. A spreadsheet is enough for a small team.

Then check the records on a schedule. OWASP suggests three layers.

• Scheduled scans, daily or weekly, that confirm every target still resolves and answers with expected content rather than a provider error page.
• Pipeline checks in deployment and teardown, so a removal is not finished until its DNS records are gone.
• Change alerts when a new CNAME appears, and when a target returns a 404, an NXDOMAIN or a provider default error page.

The sheet's fingerprint table lists the error pages that show a resource has gone while its record remains, such as NoSuchBucket from S3 and No such app from Heroku. For tooling it names dnsReaper, nuclei with its takeover templates, and the can-i-take-over-xyz reference.

Use domain verification and restrict wildcards

Some providers let you prove you own a domain before anyone can attach it to an account. The sheet's examples:

• Azure App Service supports a verification TXT record such as asuid.subdomain. Keep it in place after you remove the App Service, so another tenant cannot claim the domain.
• GitHub Pages lets you verify the domain in the account or organization settings. OWASP says this protects the verified domain and its immediate subdomains, not deeper names covered by a wildcard.

Where no verification exists, the DNS record is your only control, and removing it promptly is the only reliable protection.

Wildcard records need extra care. A record for *.example.com resolves for every name, including names of services that are gone, so you may not even know which subdomains are in use. Avoid wildcards unless you must. If you need one, scope it narrowly (*.staging.example.com rather than *.example.com), put a reverse proxy or load balancer in front that allows only known hostnames.

Limit the damage if one gets through

Assume a record will slip through one day, and scope your controls so a taken subdomain gets little. The sheet gives five rules.

• Cookies: do not scope session cookies to the parent domain unless you must. Set them on the exact subdomain, and use the __Host- prefix where you can. See the session cookie settings.
• Content Security Policy: list trusted subdomains by name instead of *.example.com. A taken subdomain that matches a wildcard can inject scripts without breaking the policy. See writing a Content Security Policy.
• CORS: check origins against an explicit allow list, not a wildcard pattern. See checking CORS settings.
• OAuth and single sign-on: use exact-match redirect URIs and never allow a whole subdomain pattern, since a taken subdomain in the list enables token theft. See the OAuth 2.0 checks.
• Email: if an SPF record matches the taken subdomain's IP address, the attacker can send mail that passes SPF as your domain.

A decommissioning checklist you can copy

OWASP recommends a formal checklist for any externally facing service. Here is the one from the sheet, in order, as a worked example for retiring the blog above.

1. List every DNS record tied to the service: CNAME, A, MX, NS and TXT.
2. Point the record at a maintenance page or redirect if removal would break users.
3. Remove or update the record.
4. Wait at least the TTL.
5. Remove the cloud resource.
6. Revoke or let expire any certificates issued for the subdomain.
7. Update the DNS inventory.
8. Remove the subdomain from OAuth redirect lists, CSP directives and CORS settings.
9. Check that the name no longer resolves or serves the old content, then run a takeover scan against it.

Signs that a takeover already happened, from the sheet: the subdomain serves unexpected content or a parking page, a certificate for it was issued to an unknown party (visible in Certificate Transparency logs), users report phishing that appears to come from it, or DMARC reports show mail from it that you did not send.

If you find one, remove the DNS record first, because that breaks the link to the attacker's resource. Then request revocation of certificates issued during the takeover, work out the impact, notify affected users if sensitive data may have been exposed, find the process gap and scan every zone you own for more dangling records.

Frequently asked questions

What is a subdomain takeover?

It happens when a DNS record points at a cloud resource or third-party service that no longer exists, and an attacker claims that resource. They then serve their own content on your subdomain.

Is deleting the DNS record enough?

It is the fastest fix and the one OWASP puts first in incident response. To prevent the problem, remove the record before you delete the resource, wait at least the TTL, and also clean up certificates, allow lists and the inventory.

How often should I scan for dangling records?

OWASP suggests daily or weekly scheduled checks of every record, plus checks in your deployment and teardown pipeline. Scanning for the provider error pages in its fingerprint table should run at least weekly.

Does a checklist prove my subdomains are safe?

No. It catches the common mistakes. Records you do not know about, or a service that behaves differently from the sheet's snapshot, need a review of your actual DNS zones.

Get started

List every record in your DNS zones, match each to a resource and an owner, and remove the ones that point at nothing. whitehatstoic builds web and mobile apps and tests web apps and APIs for weak spots, with a written report and a retest after fixes. Book a meeting with whitehatstoic and tell us about your app, your deadline and your biggest worry; work is scoped after a short call.