Subdomain Finder

A subdomain finder lists the hostnames that exist under a domain, such as shop.example.com, mail.example.com or staging.example.com. This tool reads public Certificate Transparency logs, where every publicly trusted HTTPS certificate and the names it covers are recorded, adds a short list of common names, and resolves each one in DNS so you can see which are live, which point elsewhere through a CNAME, and which no longer resolve. It highlights the two problems worth acting on: dangling CNAMEs that point at cloud services which no longer exist, a common route to subdomain takeover, and staging, test or admin sites that are reachable from the public internet.

How to use the Subdomain finder

1. 1 Enter the domainType the main domain, such as example.com. A www prefix is removed automatically.
2. 2 Run the searchWe query the Certificate Transparency logs for every certificate issued to the domain and its subdomains, then resolve each name in one batch over DNS-over-HTTPS.
3. 3 Read the tableEach subdomain shows its status (live, CNAME only, dangling or no DNS), what it points to, and whether it came from the logs or the common-name list.
4. 4 Act on dangling records firstRemove or fix any CNAME marked dangling, because those are the ones someone else might be able to claim.
5. 5 Lock down private hostsPut public staging, test and admin hosts behind a login, an IP allowlist or a VPN.

What Certificate Transparency logs are

Certificate Transparency (CT) is a system of public, append-only logs that record every TLS certificate issued by publicly trusted certificate authorities. Browsers such as Chrome and Safari require certificates to be logged before they will trust them, so in practice almost every HTTPS certificate on the public web appears in these logs within minutes of being issued.

Each logged certificate lists the hostnames it is valid for. That makes CT logs a free and passive record of the subdomains an organisation has used over the years: every time someone requested a certificate for portal.example.com or test-api.example.com, that name was written into a public log. Services such as crt.sh and Cert Spotter index the logs and make them searchable, and this tool queries them for you.

Because the method is passive, it does not touch the target servers at all until the final DNS check. It is the same data security teams, auditors and attackers all use, which is exactly why it is worth looking at your own domain first.

Why you should know your own subdomains

Subdomains accumulate. A marketing campaign gets its own microsite, a developer sets up a staging copy, a help desk or status page is moved to a third-party service, a project is abandoned. Years later nobody remembers that old.example.com still points somewhere. Each forgotten host is something that is not being patched, monitored or renewed.

From an SEO point of view, public staging and test sites can be indexed by search engines and compete with your real pages as duplicate content. From a security point of view, old hosts often run outdated software, may expose admin panels or test data, and can damage trust if someone else ends up serving content on them. An inventory is the first step to cleaning up.

• Find forgotten staging, test and campaign sites.
• Spot DNS records that point to services you no longer use.
• Check that every live host has HTTPS and is monitored.
• Keep duplicate copies of your site out of search results.

Dangling CNAMEs and subdomain takeover

A CNAME record makes one hostname an alias for another, for example help.example.com pointing to example.zendesk.com, or shop.example.com pointing to a store on a hosted platform. If you later close that account or delete that cloud resource but leave the CNAME in place, the alias now points at a name that does not exist. That is a dangling CNAME.

On some services, anyone can then create a new resource with that same name, such as an app called example on a platform-as-a-service, or a storage bucket with a matching name, and the old CNAME will send your visitors straight to it. That is subdomain takeover. An attacker can host phishing pages, malware or misleading content under your domain, with your domain's reputation and, sometimes, its cookies.

This tool flags a subdomain as dangling only when its CNAME target does not resolve at all and the target is on a service known to allow names to be reclaimed. That keeps the warning focused. It does not try to claim anything or prove exploitability; treat a flag as a reason to check the record and remove it if the resource is gone.

How to read each status

Live means the name resolved to one or more IP addresses, directly or through a CNAME chain, so something answers there. CNAME only means the name is an alias but no address came back, which can be normal for some services but deserves a look. Dangling means the CNAME points to a hostname that does not exist on a takeover-prone service. No DNS means the name appeared in the certificate logs in the past but no longer resolves, which is usually harmless history.

If the domain uses wildcard DNS, every made-up name resolves, so guesses from the common-name list are hidden and only names seen in the logs are shown. If the domain uses a wildcard certificate, hosts covered only by that certificate never appear in the logs by name, so the list may be incomplete. Both cases are noted in the results.

Limits of a certificate-based search

The logs only know about names that were put on a public certificate. Internal hostnames, hosts that only serve plain HTTP, and names covered only by a wildcard certificate are not listed. Very large domains can have thousands of logged names; this tool resolves the first 150 alphabetically in each run so the check stays fast, and says when it has done so.

The log services are free community resources and occasionally slow or unavailable. When the main source does not answer, the tool falls back to a second one, and if neither responds it checks only the common names and tells you, so you can run it again later.

Nothing here involves brute-forcing names, scanning ports or sending traffic to the subdomains themselves. The only active step is a DNS lookup for each name, the same thing any browser does before visiting a site.

Cleaning up after you find something

For each dangling CNAME, decide whether the service is still needed. If not, delete the DNS record at your DNS host. If it is, recreate the resource on the provider so the name is yours again. For live staging or admin hosts, add authentication, restrict access by IP address or VPN, and add a noindex header so search engines do not list them. For live hosts you do not recognise, find the owner before changing anything.

Then make it routine: review subdomains whenever a project ends or a provider changes, and remove DNS records in the same change that shuts down the service behind them. Use our DNS Lookup for the full record set on any name, the SSL Checker to confirm live hosts have valid certificates, and the Website Technology Checker to see what each one runs.

Examples you can copy

help.example.com.  CNAME  example-old.herokuapp.com.
; example-old.herokuapp.com no longer exists (NXDOMAIN)
; fix: delete the record, or recreate the app with that name

shop.example.com.  CNAME  shops.myshopify.com.
shops.myshopify.com.  A  23.227.38.65

Header set X-Robots-Tag "noindex, nofollow"
AuthType Basic
AuthName "Staging"
AuthUserFile /path/to/.htpasswd
Require valid-user

Common mistakes to avoid

Frequently asked questions