how to prevent subdomain takeover

TL;DR

Subdomain takeover happens when a DNS record points at an external service (a cloud bucket, a SaaS app, a CDN) that you stopped using, and an attacker claims that name on the service to serve content from your subdomain. Prevention is an inventory habit: list every DNS record, flag any CNAME or A record pointing outside your infrastructure, verify each one is still claimed by you, and delete the record the moment the service is decommissioned. Automate the check so drift gets caught.

how to prevent subdomain takeover

Use this when

• You are auditing DNS for a domain you own
• You just migrated off a SaaS, PaaS, or cloud provider and old records may linger
• A bug-bounty hunter reports a dangling record (fix it, then thank them)
• You manage DNS across many subdomains or acquired domains

Not for

• Configuring DNSSEC or DNS performance
• Taking over someone elses subdomain (out of scope, obviously)
• General domain registration management

Steps

1. Export a full inventory of DNS records. Pull the zone file or list records via your DNS providers API for every domain you own, including acquired or legacy domains people forgot about.

Expected output: a complete list of A, AAAA, CNAME, and NS records with their targets.

1. Flag every record pointing at a third party. Any CNAME to an external hostname (SaaS domains, cloud provider endpoints, CDN hostnames) or A record to an IP you dont control is a candidate. Sort by 'do we still use this service'.

Expected output: a shortlist of external-pointing records, each labeled active or unknown.

1. Verify each external target is still yours. For each candidate, check that the service account, bucket, or app behind it still exists under your control. A CNAME to a deleted cloud bucket or an unclaimed SaaS subdomain is the classic takeover setup.

Expected output: every external record is confirmed claimed by your team, or marked dangling.

1. Delete dangling records immediately. If the service is gone, remove the DNS record; dont leave it 'just in case'. If you might return, keep a note outside DNS, not a live record pointing at nothing.

Expected output: a second inventory run shows zero records pointing at unclaimed services.

1. Reclaim where deletion isnt an option. If a record must stay (a partner integration in progress), re-register or re-claim the target name on the service so nobody else can.

Expected output: the target name is registered under your account on the external service.

1. Automate the check. Run the inventory monthly (or on every DNS change via webhook) and alert on new external-pointing records or on targets that stop resolving to your infrastructure.

Expected output: a scheduled job that pages or tickets when a new dangling record appears.

Variant phrasings

• "dangling CNAME record security risk"
• "how do subdomain takeovers work (defense)"
• "audit DNS records for takeover risk"
• "subdomain takeover cloud bucket"

Edge cases and pitfalls

• Acquired companies bring DNS you never audited; inventory their domains on day one of the acquisition.
• Wildcard DNS records can mask dangling subdomains from naive scans; enumerate subdomains from certificate transparency logs too.
• Some services let anyone claim any subdomain-style name; treat every external CNAME as guilty until verified.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstcsa3O1P09ylibpXKtA9vg