Subdomain takeover
An attacker claims a deleted service that your DNS still points to, then serves their content from your trusted subdomain.
See it
What it is
A subdomain takeover starts with a DNS record that still points to a resource you deleted, such as a retired GitHub Pages site or cloud app. If that platform lets someone else claim the missing resource name, the attacker can serve their content from your trusted subdomain. The DNS record still belongs to you; the thing at its destination does not.
Look for it whenever a hosted site, storage bucket, CDN distribution, or SaaS integration is retired or renamed. Inventory CNAME records, follow each target, and treat provider messages such as 'site not found' as evidence to investigate, not proof by themselves. Remove the DNS record before deleting the resource, then confirm the old hostname no longer resolves.
The trap is checking only whether the subdomain still answers. A dangling target that returns a normal provider error page rather than NXDOMAIN can still be claimable, while another error page may not be claimable at all. Confirm the provider's ownership rules, and use domain verification features such as GitHub Pages custom-domain verification where they exist.
Ask AI for it
Audit every DNS record in this repository and its exported zone files for subdomain takeover risk. Resolve every CNAME target and compare it with the configured resources in GitHub Pages, AWS CloudFront, and Azure App Service. Flag records whose target returns a provider missing-resource response, but do not label one exploitable from its error text alone. For each candidate, identify the exact DNS record, the former service, whether that provider still allows the resource name to be claimed, and the safe removal order. Generate a runbook that removes the DNS record before deleting the hosted resource, waits for the record's DNS TTL, verifies NXDOMAIN or the intended replacement, and enables GitHub Pages custom-domain verification for every GitHub organization domain.