TontonTools

Subdomain Finder

Discover a domain's subdomains — map the full web footprint.

100% Free No signup Privacy-friendly Domain & IP Tools
Updated Sep 2026

Powered by crt.sh Certificate Transparency logs — free, no key required.

Share X / Twitter Facebook LinkedIn WhatsApp

How to use Subdomain Finder

  1. Enter the domain — one you own or are authorized to assess.
  2. Review discovered subdomains — from CT logs and DNS sources.
  3. Audit each: forgotten/outdated services and dangling CNAMEs are the priority findings.
  4. Investigate within scope — DNS, SSL and header checks per subdomain; nothing unauthorized.

What is Subdomain Finder?

A subdomain finder enumerates the subdomains under a domain — blog.example.com, api.example.com, mail.example.com, dev.example.com and the rest — mapping the full surface of an organization's web presence beyond the main site. Subdomains host distinct services, and finding them reveals how an operation is structured.

The security framing matters up front: subdomain enumeration is a core step in authorized security assessment (attack-surface mapping) — and it's the same reconnaissance attackers run. Use it on your own domains, or with explicit permission on others; never for unauthorized probing.

About the Subdomain Finder

Enter a domain and discover its known subdomains, drawn from public sources (Certificate Transparency logs, DNS data, passive datasets).

Legitimate uses: your own attack-surface audit — the essential one, since organizations routinely forget subdomains they created (that staging. box from 2021 running outdated software is exactly what enumeration surfaces, and what attackers find first); subdomain-takeover checks — dangling CNAMEs pointing at deprovisioned services are a classic, findable vulnerability; infrastructure understanding — mapping how a service organizes (API endpoints, regional sites, admin panels); and bug-bounty scoping within authorized programs.

Method and limits: much discovery now comes from Certificate Transparency (every HTTPS cert publicly logs its hostnames — a rich, passive source), supplemented by DNS and wordlist data; results are strong but never exhaustive (internal-only and never-certified subdomains stay hidden). Findings feed onward — DNS/SSL/HTTP-header checks per subdomain, and ping/port scans within authorized scope.

Frequently Asked Questions

Discovering subdomains from public data (CT logs, DNS) is passive and legal. Actively probing or attacking what you find requires authorization — your own assets or explicit written permission. Reconnaissance isn't attack, but stay on the right side of scope.
Primarily Certificate Transparency logs — every HTTPS certificate publicly records its hostnames, so certified subdomains are findable passively. DNS records, passive-DNS datasets and wordlist guessing supplement it.
Because you've forgotten some — and attackers enumerate them on day one. Old staging/dev boxes, deprecated services and dangling CNAMEs are the classic weak points, all invisible until you map them.
When a subdomain's CNAME points at a third-party service (S3 bucket, Heroku app) that's been deleted — an attacker re-registers that service name and controls your subdomain. Enumeration + dangling-target checks catch it.
No — CT-based discovery is strong for HTTPS-certified subdomains but misses internal-only, wildcard-hidden and never-certified ones. It maps the public footprint thoroughly, not exhaustively.

We use cookies for analytics and to keep the tools free via ads. See our Privacy Policy.