Dangling DNS Record / Subdomain Takeover

What’s actually happening

A subdomain like `blog.example.com` or `assets.example.com` returns the hosting provider's generic 404 instead of your content. The CNAME (or A/NS) still resolves and points at a service endpoint, but the resource behind it was deleted. The danger isn't the broken page, it's that the namespace at the provider is now unclaimed. Whoever registers that bucket/app/repo name next controls everything served on your subdomain, including cookies scoped to it.

Common causes

• A CNAME pointing to an S3 bucket, GitHub Pages repo, Heroku/Azure/Fastly/Shopify app that was decommissioned but never removed from DNS
• Marketing or staging subdomains spun up on a SaaS, then the SaaS account closed while the record stayed
• A retired Azure resource (App Service, Traffic Manager, Storage) whose hostname is now claimable by another tenant
• NS delegation pointing to a DNS provider zone that was deleted, allowing zone re-registration
• Bulk DNS imports that carried over records for services long gone

How to fix it

1. Inventory every external-pointing recordExport the full zone and flag records whose targets are third-party (`*.s3.amazonaws.com`, `*.github.io`, `*.herokudns.com`, `*.azurewebsites.net`, `*.fastly.net`, `*.myshopify.com`). For each, confirm the resource still exists and belongs to you.
2. Probe for the takeover fingerprintsHit each subdomain and look for the tell: `NoSuchBucket`, `There isn't a GitHub Pages site here.`, `No such app`, etc. Tools like subzy or nuclei's takeover templates automate this across a large zone.
3. Delete the dangling record immediatelyFor any subdomain pointing at a resource you no longer own, remove the CNAME/A/NS record from DNS now. This is the only fix that fully closes the hole, repointing alone isn't enough if the target is already claimable.
4. Re-claim the resource if you still need the subdomainIf the subdomain must stay live, recreate the resource at the provider (same bucket/app name) under your account and re-attach it, then verify it serves your content before considering it safe.
5. Enforce decommission ordering going forwardMake it policy: delete the DNS record BEFORE tearing down the hosted resource. Reversing that order is exactly what creates the dangling window attackers scan for.