Subdomain Finder & Takeover Checker

How this subdomain finder works

Enter a domain and this tool queries public Certificate Transparency logs for every certificate ever issued to a name under it, builds a deduplicated list of subdomains, then resolves each one to see whether it still points anywhere. Nothing is sent to your servers during discovery — the entire list comes from public records.

Why every subdomain you own is already public

This surprises people, so it is worth being clear about. Since 2018, browsers have required that publicly trusted certificates be logged to Certificate Transparency — a set of append-only, publicly readable logs designed so that a certificate authority cannot quietly issue a certificate for your domain without anyone noticing. It works well for that purpose.

The side effect is that certificates are an inventory. Every time you issue one for staging.example.com or internal-admin.example.com, that hostname is published to a permanent public log. Attackers have known this for years and it is usually the first place they look. Naming a host something obscure protects nothing.

Dangling records and subdomain takeover

The finding worth acting on is a subdomain whose DNS record survives the thing it pointed at. The usual sequence: a team spins up a marketing page, a docs site or a status page on a hosted platform, points a CNAME at it, then later deletes the resource on that platform. The CNAME stays in DNS. The hostname on that platform is now unclaimed.

Anyone can then register that same hostname on the platform and start serving whatever they like at your subdomain — on your domain, over HTTPS, with a valid certificate they can obtain themselves. The consequences run from convincing phishing to real session theft, because any cookie your main site scopes to the parent domain will be sent to the attacker's page too.

This tool flags two related states: records that point at a third-party host which no longer resolves, and records that do not resolve at all. Both are cleanup candidates. The first is the more urgent.

Attack surface you forgot you had

Even without a takeover, the list itself is worth reading. Most teams find something they had forgotten: an old staging environment still reachable from the internet, a legacy admin panel, a marketing microsite from a campaign that ended three years ago running software that has not been patched since. Every one of those is a live host with your name on it.

What to do with the results

• Delete DNS records for anything that no longer resolves. A dangling record has no upside and is the precondition for takeover.
• For each subdomain that does resolve, confirm you know what it is, who owns it, and that it is being patched. If nobody can answer those, it should not be exposed.
• Avoid scoping cookies to the parent domain unless you genuinely need them shared. It is what turns a subdomain takeover into a session compromise.
• Re-check periodically. This list grows every time someone issues a certificate, which on modern platforms happens automatically.

Deprovisioning order matters

Most takeovers are created by doing teardown in the wrong sequence. The safe order is always the same:

1. Remove the DNS record first
2. Then delete the resource on the hosting platform

# Doing it the other way round leaves a window — potentially
# permanent — where the name is claimable by anyone.