Dangling DNS Records (Subdomain Takeover)

You deployed a staging app to Vercel at staging.yourapp.com. You set up a CNAME record pointing staging.yourapp.com to cname.vercel-dns.com. A few months later, you delete the Vercel project — but forget to remove the DNS record.

Now that CNAME is dangling. It points to Vercel, but no project is behind it. An attacker creates a new Vercel project, adds staging.yourapp.com as a custom domain, and Vercel happily verifies it — because the CNAME already points there. The attacker now controls content on your subdomain.

This isn't theoretical. Subdomain takeovers are used for phishing campaigns, cookie theft (if cookies are scoped to .yourapp.com), and bypassing email security policies. The attacker's page looks completely legitimate because it's literally on your domain.

The attack targets the gap between your DNS configuration and your cloud infrastructure. When a CNAME points to a service that no longer exists, the subdomain is up for grabs on that platform.

Here's how the dangling record typically gets created:

AI tools don't directly create subdomain takeover vulnerabilities — but they accelerate the workflow that leads to them. When spinning up and tearing down projects is fast, DNS hygiene gets left behind.

• Rapid prototyping creates infrastructure sprawl. You deploy three versions of a project to Vercel in a week. The DNS records pile up. When you delete the old projects, the records stay.
• AI-generated deploy scripts skip cleanup. "Deploy this to Netlify" gets you a working deploy. Nobody asks the AI to also write the teardown script that removes DNS records.
• Platform guides focus on setup, not decommission. Every tutorial shows how to add a custom domain. Almost none explain what to do when you remove the project behind it.

The vulnerability isn't in the code — it's in the infrastructure. Every project you ship and later abandon is a potential takeover target. The faster you build, the more dangling records you leave behind.

Flowpatrol checks for dangling DNS records by resolving your subdomains and verifying the services behind them:

1. 1Enumerates subdomains using DNS records, certificate transparency logs, and common subdomain patterns.
2. 2Resolves each CNAME chain and identifies which cloud platform the record points to.
3. 3Checks for takeover signals — looks for error pages, 404s, and platform-specific "site not found" responses that indicate the service doesn't exist.
4. 4Reports vulnerable subdomains with the dangling record, the target platform, and the exact DNS change needed to fix it.

Dangling DNS records are invisible until someone exploits them. Flowpatrol finds them before that happens.