Subdomain takeover: the DNS record that outlived the service

Somewhere in your DNS there is probably a record pointing at a service you no longer use. A staging environment on a platform you migrated off. A status page from a vendor you replaced. A marketing microsite for a campaign that ended.

The service is gone. The record is not. And on a lot of hosting platforms, an unclaimed hostname is available to whoever asks for it first.

How the attack works

It is a three-step sequence, and none of the steps require access to anything you own.

1. Enumerate. Pull every hostname ever issued a certificate under your domain from Certificate Transparency logs. This is public data by design.
2. Find the gaps. Resolve each one. Look for records that still exist in DNS but point at a third-party platform where the resource is unclaimed - typically identifiable by the platform's own "no such site" error page.
3. Claim it. Sign up for that platform, add the hostname as a custom domain. The platform checks DNS, finds your CNAME pointing at it, and accepts the claim. It will usually issue a TLS certificate automatically.

The result is a page on something.yourdomain.com, served over HTTPS with a valid certificate, under someone else's control.

Why it matters more than it sounds

The instinct is that a forgotten subdomain is low-stakes. It is not, because a browser's trust decisions are largely scoped to the domain.

• Cookies. A cookie set with Domain=.yourdomain.com is sent to every subdomain, including the hijacked one.
• OAuth and SSO redirects. Allowlists are frequently written as wildcards over the domain. A controlled subdomain can become a valid redirect target for an authentication flow.
• CORS. Policies that trust any origin under your domain will trust the attacker's page.
• Plain credibility. A phishing page on your actual domain, with a real certificate and no browser warning, is far more convincing than any look-alike.

That last point is the one that reaches your customers. Everything a security awareness programme teaches people to check - the URL, the padlock - reads as legitimate.

Certificate Transparency: why your subdomains are already public

Certificate Transparency is a public, append-only log of every certificate issued by a publicly trusted CA. It exists for a good reason: it makes mis-issuance detectable, so a CA cannot quietly issue a certificate for your domain without leaving a record.

The side effect is that your hostname list is public. Every time you request a certificate for internal-tools.yourdomain.com or staging-v2.yourdomain.com, that name enters a permanent public record.

This is not a flaw to be worked around, and you cannot opt out without giving up publicly trusted certificates. The correct response is to assume the list is known and make sure nothing on it is embarrassing or dangling. Treat a subdomain as public the moment it gets a certificate.

Auditing your own

Start by listing what exists. A Certificate Transparency search for your domain returns the hostnames. Then resolve each one and look at what answers:

for host in $(cat hostnames.txt); do
  printf '%-40s ' "$host"
  dig +short "$host" | head -1 || echo "(no answer)"
done

Three outcomes, and they mean different things:

• Resolves to something you run. Fine. Confirm it should still be public.
• Does not resolve at all. The DNS record is gone. Harmless, and worth nothing more than a note.
• Resolves, but the service returns a platform error page. This is the dangerous one. The record is live and pointing at an unclaimed resource.

That third case is what a scanner is looking for when it flags "dangling DNS". It is also why a finding of "did not resolve" deserves a look rather than a shrug - the distinction between a record that is gone and a record that points somewhere claimable is the whole risk.

If one has already been taken

A live takeover is a different problem from a dangling record, and the order of operations matters.

1. Remove the DNS record first. This severs the attacker's claim immediately and is entirely within your control. Do it before anything else.
2. Work out what trusted it. Check for cookies scoped to the parent domain, wildcard OAuth redirect allowlists, CORS policies trusting any subdomain, and any internal service that allowlists by domain suffix.
3. Rotate what was exposed. If session cookies were reachable, invalidate sessions. If an OAuth flow could have been redirected, rotate the client secret.
4. Check what was served. Search engine caches and the Wayback Machine may show what was hosted there, which determines whether customers were shown anything and whether you need to tell them.
5. Report it to the platform. Most hosting providers will act on a takeover report, and some can tell you when the claim was made.

The wildcard question

A wildcard certificate for *.yourdomain.com is convenient - one certificate, every subdomain covered - and it changes the shape of this problem in both directions.

It helps in one way: individual hostnames no longer appear in Certificate Transparency, because the wildcard covers them without naming them. Your subdomain list is less enumerable.

It hurts in two. First, you lose your own visibility - the CT log was also how you found out what exists, and a wildcard removes that inventory. Second, a wildcard certificate and its private key are valid for every subdomain, so the blast radius of a compromised key is the entire domain rather than one hostname.

Neither answer is universally right. But if you use wildcards, you need a different source of truth for what subdomains exist - your DNS zone file, exported and reviewed - because certificate transparency will no longer tell you.

Fixing and preventing

The fix for an individual case is a one-line deletion: remove the DNS record. If you still need the hostname, point it somewhere you control.

Prevention is a process problem rather than a technical one:

1. Delete DNS at decommission time. When you stop paying for a service, remove the record in the same change. This is the entire fix, and it is skipped constantly because the record causes no visible problem.
2. Put it on the offboarding checklist. Cancelling a vendor should include "remove DNS records pointing at them" alongside revoking access and closing the account.
3. Prefer specific records over wildcards. A wildcard *.yourdomain.com means you cannot enumerate what exists, because everything resolves.
4. Re-enumerate periodically. Quarterly is enough for most companies. The list only grows.

The wider point

Subdomain takeover is a good example of a category that shows up repeatedly in external security posture: the problem is not something anyone did wrong, exactly. Someone spun up a service, someone else cancelled it, and the DNS record simply was not anybody's job.

That is also why it is worth checking from the outside periodically. Nothing internal will alert you - the record works perfectly, it just points at someone else now.