Is a Forgotten DNS Record Putting Your Domain at Risk? Subdomain Takeover Explained

What is a dangling DNS record?

A DNS record is an instruction: 'when someone asks for this name, send them there.' The risky kind is a CNAME, which says 'this name is an alias for that other name', for example shop.yourbrand.com pointing at a store hosted by a third-party platform. A record becomes dangling when the thing it points to stops existing but the record stays. The alias still answers, it just leads to an unclaimed slot.

The trap is that DNS and the platform are two separate systems with two separate owners. Deleting your project on the platform does not touch your DNS zone, because the platform has no access to it. And your DNS provider does not know the project is gone. Nothing links the two, so nothing cleans up. Dangling records are almost always created by well-meaning shutdowns, not by mistakes at launch.

How does a subdomain takeover actually work?

The attack is boring, which is why it works. An attacker finds a subdomain of yours whose CNAME points at a platform address that returns a 'not found' or 'no such site' page. They create an account on that platform, claim the exact address your record points to, and add your subdomain as a custom domain. Many platforms historically accepted this without proof that the attacker owns the domain, because the DNS record already 'proved' the pointer. From that moment the platform serves the attacker's page at your subdomain.

Notice what the attacker did not do. They never logged into your registrar, never touched your DNS settings, never phished anyone on your team. The only mistake was yours, months earlier, and it was an omission. Platforms differ in how hard they make this today, and several now require a verification record before they serve a custom domain, but you cannot assume every service you ever used does. The safe assumption is that an unclaimed target behind a live CNAME is claimable.

Why does it matter if it's only an old subdomain?

Because the browser and everyone else judge the subdomain by your domain name, not by how forgotten it is. A page at promo.yourbrand.com inherits trust you built on yourbrand.com, and several concrete things follow from that:

• Phishing that looks real. A login page under your own domain, with a valid HTTPS certificate, beats any lookalike domain you could warn customers about.
• Cookie exposure. If your app sets cookies scoped to the whole domain (.yourbrand.com) rather than to a single host, a page on any subdomain you do not control can potentially read or overwrite them. That is a path toward session hijacking.
• Broken allowlists. Security settings such as CORS rules, content security policies, and OAuth redirect lists often trust '*.yourbrand.com'. A hijacked subdomain slips straight through them.
• Brand and SEO damage. Spam, malware, or adult content hosted under your domain can get the whole domain flagged by browsers and search engines, which hurts the subdomains you do care about.
• Email risk. Some records, such as SPF includes or MX entries pointing at services you abandoned, create the same 'claim the dead target' opening for mail.

Which records are most likely to be dangling?

Look for records that were created for something temporary. The usual suspects are the ones where a third party hosted the thing behind your name:

• CNAMEs to hosting and deployment platforms: landing pages, documentation sites, status pages, help centers, and preview or staging environments.
• CNAMEs to cloud storage and CDN endpoints that were deleted after a migration.
• A records pointing at cloud IP addresses you released. Another customer of the same cloud can later be handed that address.
• NS records delegating a subdomain to another provider's nameservers you no longer pay for. This is the worst case, because whoever controls those nameservers controls everything under that subdomain.
• Records pointing at a domain that has since expired. Anyone can register an expired domain, and then every record aimed at it follows them.

How do you audit your own domain in 20 minutes?

You do not need special software for a first pass. Export or copy your complete DNS zone from your DNS provider (every provider has a zone-file export or a plain list view), then work through it line by line. Pay attention to subdomains you do not recognize, and to anything created by a former employee, contractor, or agency.

For each CNAME, ask three questions: What service does this point to? Do we still use that service? Does the target still resolve to something we own? Look up the target. If it returns no answer at all (NXDOMAIN), or it loads a generic 'site not found' or 'nothing here' page from the platform, treat the record as dangling. You can run those lookups, plus A, MX, TXT, and NS records for the whole domain, with the free DNS lookup tool at ZeroTaken, which is faster than doing it from a terminal if you are not used to dig.

Then act on the result. If you no longer use the service, delete the record. If you still use it, confirm in that service's dashboard that your custom domain is attached and verified. Write the surviving records into a short inventory (name, target, owner, purpose). A one-page list is what stops this from happening again, because the next shutdown will have somewhere to check.

What stops it from happening again?

The fix is about ordering and habit rather than tools. First, when you decommission anything that has a custom domain, remove the DNS record before you delete the project, never after. If the record is gone first, there is no window in which a live pointer leads to an unclaimed target. Second, prefer services that make you prove ownership of a domain with a TXT verification record before they will serve it. That check is exactly what blocks a stranger from claiming your subdomain, so choose it when you have the option.

Third, scope your cookies to the specific host that needs them instead of the whole parent domain, so a compromised sibling subdomain cannot read your session cookie. Fourth, avoid wildcard records pointing at third parties unless you truly need them, because a wildcard turns every possible name into a potential takeover. Finally, put a recurring calendar reminder on the DNS inventory, quarterly is plenty, and make adding a record and removing a record both a two-line entry in that list. Teams with this habit rarely end up with strangers' pages on their own domain.

What should you do if a subdomain has already been taken over?

Act in this order. Delete or repoint the dangling DNS record immediately, since that is what ends the abuse; everything else is cleanup. Then look at what was served and for how long, using your DNS provider's change history if it keeps one, and check whether any cookies, OAuth redirects, or allowlists trusted that subdomain during the window.

If the subdomain ever shared cookies with your main app, rotate session secrets and force a re-login. Request a review through your search engine's webmaster tools and browser safe-browsing reports if the content was flagged. Then add the missing entry to your inventory and finish the audit above, because a takeover on one subdomain usually means others were left behind in the same cleanup that created it.