A single domain can have many services running behind it.
When you visit:
example.com
you might only see the main website. But the same domain could also have:
blog.example.com
api.example.com
mail.example.com
cpanel.example.com
status.example.com
These are called subdomains.
Developers, website owners, system administrators, and security researchers often need to discover these subdomains to understand which services are publicly associated with a domain.
The interesting part is that you don't always need to actively scan a server to find them.
A large amount of this information can already be discovered through public sources such as Certificate Transparency logs and DNS records.
Let's look at how this works.
What Is a Subdomain?
A subdomain is an additional hostname created under a primary domain.
If the main domain is:
example.com
possible subdomains could include:
www.example.com
shop.example.com
api.example.com
support.example.com
Organizations use subdomains to separate websites, applications, APIs, email systems, control panels, documentation, and other services.
For example:
api.example.com
might handle API requests, while:
docs.example.com
could host developer documentation.
Both belong to the same root domain but may point to different servers or services.
Why Would You Want to Find Subdomains?
There are many practical reasons.
If you manage a website, subdomain discovery can help you understand which hostnames are publicly visible.
If you're a developer, it can help you identify APIs, documentation sites, dashboards, or development environments associated with a project.
Security teams also use subdomain discovery during asset inventory and passive reconnaissance.
You might discover hostnames such as:
api.example.com
dev.example.com
staging.example.com
mail.example.com
cpanel.example.com
Some may represent current services.
Others may be older hostnames that still appear in public records.
This makes subdomain discovery useful not only for finding services but also for understanding the public footprint of a domain.
How Can Subdomains Be Discovered Without Scanning?
One method is passive subdomain discovery.
Instead of aggressively probing a target server, passive discovery relies on information already available from public sources.
One particularly useful source is Certificate Transparency.
Certificate Transparency logs contain information about publicly issued SSL/TLS certificates.
Certificates frequently contain domain names.
For example, if certificates were issued for:
example.com
api.example.com
shop.example.com
those hostnames may appear in Certificate Transparency records.
This gives us a way to discover potential subdomains without guessing every possible hostname.
What Are Certificate Transparency Logs?
Certificate Transparency, often shortened to CT, is a public system designed to record SSL/TLS certificates.
When Certificate Authorities issue certificates, certificate information can be submitted to publicly accessible CT logs.
These records help make certificate issuance more transparent.
They also happen to provide a useful source of domain information.
Suppose an organization previously obtained certificates containing:
www.example.com
api.example.com
dashboard.example.com
Searching Certificate Transparency data may reveal those hostnames.
This is why CT logs have become a useful source for subdomain discovery.
A Simple Subdomain Discovery Process
A basic passive discovery workflow can be represented like this:
Domain
↓
Search public records
↓
Discover possible subdomains
↓
Remove duplicate entries
↓
Resolve DNS records
↓
Display hostname and IP address
For example, you might start with:
example.com
and discover:
www.example.com
mail.example.com
api.example.com
cpanel.example.com
The next step is checking whether these hostnames currently resolve through DNS.
The result might look like:
www.example.com 203.0.113.10
mail.example.com 203.0.113.20
api.example.com 203.0.113.10
cpanel.example.com 203.0.113.10
Now you have more than a list of names.
You can also see which IP addresses are associated with them.
Why Do Multiple Subdomains Have the Same IP Address?
This is common.
You might find results such as:
api.example.com 203.0.113.10
cpanel.example.com 203.0.113.10
mail.example.com 203.0.113.10
This does not necessarily indicate a problem.
Multiple hostnames can point to the same server.
This frequently happens with shared hosting, control panel services, reverse proxies, and other hosting configurations.
A single server can respond differently depending on which hostname was requested.
For example:
blog.example.com
and:
shop.example.com
could both resolve to the same IP while serving completely different websites.
So when analyzing subdomains, the hostname itself is just as important as the IP address.
Trying Subdomain Discovery in Your Browser
You can query public sources manually, process the results, remove duplicate hostnames, and perform DNS lookups yourself.
For a faster way to experiment with the process, you can use this browser-based Subdomain Finder.
Enter a root domain such as:
github.com
The tool searches publicly available sources for known subdomains and attempts to resolve their IP addresses.
The results show information such as:
Subdomain IP Address
subdomain.example.com 203.0.113.10
another.example.com 203.0.113.20
This makes it easy to see the relationship between discovered hostnames and their DNS resolution without manually processing the records.
How to Read the Results
There are two main pieces of information to pay attention to.
Subdomain
This is the hostname discovered from public records.
For example:
api.example.com
The name itself may provide clues about the purpose of the service.
Common examples include:
api.
mail.
blog.
docs.
status.
support.
dev.
staging.
However, names should not be treated as proof of what a service actually does.
A hostname called dev.example.com, for example, does not guarantee that it currently hosts a development environment.
IP Address
If DNS resolution succeeds, you may also see an IP address.
For example:
api.example.com → 203.0.113.15
This means the hostname currently resolves to that address through the DNS information available at the time of the lookup.
It does not necessarily mean that a website is running directly on that server.
The address could belong to a CDN, reverse proxy, load balancer, hosting provider, or another layer of infrastructure.
Why Do Some Discovered Subdomains No Longer Work?
Public records can contain historical information.
Imagine that an organization used:
old.example.com
two years ago.
An SSL certificate was issued for it, causing the hostname to appear in Certificate Transparency records.
Later, the organization removed the DNS record.
The historical certificate record can still exist.
Therefore:
Discovered subdomain ≠ active service
This distinction matters when interpreting the results.
Subdomain discovery tells you what public data reveals about a domain. It does not guarantee that every discovered hostname is currently operational.
What About Wildcard Certificates?
You may occasionally encounter records such as:
*.example.com
This is a wildcard certificate.
It can cover multiple subdomains under the same domain.
It does not mean that every possible subdomain exists.
For example, seeing:
*.example.com
does not prove that:
random.example.com
is a real service.
Wildcard records therefore need to be interpreted differently from explicitly listed hostnames.
Exporting Subdomain Results to CSV
When a domain has many discovered subdomains, reviewing everything directly in a browser becomes less convenient.
Exporting the results as CSV solves this problem.
A CSV file can contain data such as:
Subdomain,IP Address
api.example.com,203.0.113.10
mail.example.com,203.0.113.20
blog.example.com,203.0.113.30
You can then open the file in spreadsheet software or process it using your preferred development tools.
This is useful when you need to:
- Keep an inventory of discovered hostnames
- Compare results from different dates
- Sort subdomains by IP address
- Search large result sets
- Include findings in technical documentation
- Review infrastructure associated with your own domains
Are Public Records Enough to Find Every Subdomain?
No.
This is one of the most important limitations to understand.
Passive discovery only finds information available through the public data sources being searched.
Consider:
internal.example.com
If this hostname is only used inside a private network and has never appeared in public certificate records, it may not be discovered.
Some subdomains may also use configurations that prevent them from appearing in the available datasets.
This means the result should not be treated as a complete list of every subdomain belonging to an organization.
It is better to think of it as:
Publicly discoverable subdomains
rather than:
All existing subdomains
When Is Subdomain Discovery Useful?
For website owners, it can reveal public hostnames associated with their domains.
For developers, it can help map services associated with an application or organization.
For system administrators, it provides another way to review internet-facing assets.
For security professionals, it can serve as an early passive reconnaissance step during authorized assessments.
It can also help identify forgotten infrastructure.
For example, if your current documentation contains:
www.example.com
api.example.com
but public records also reveal:
staging.example.com
old-api.example.com
you now have two additional assets worth investigating internally.
The Most Important Part Is Interpreting the Data
Finding a long list of subdomains is easy.
Understanding what the results actually mean is more important.
Keep these distinctions in mind:
Found in public records
≠
Currently active
Resolves to an IP
≠
Web application is running
Same IP address
≠
Same application
No result
≠
No subdomain exists
Each result gives you one piece of information about the public footprint of a domain.
Final Thoughts
Subdomain discovery is a useful technique for understanding how websites and online services are organized.
Certificate Transparency logs make this particularly interesting because they provide a public source of hostnames that have appeared in SSL/TLS certificates.
By combining those records with DNS resolution, you can turn a simple domain name into a more useful view of its publicly discoverable services.
The basic process is straightforward:
Enter domain
↓
Discover subdomains
↓
Resolve IP addresses
↓
Review results
↓
Export if needed
Just remember that passive discovery provides visibility into public data, not a guaranteed inventory of every system behind a domain.
That distinction is what makes the results useful rather than misleading.
Top comments (0)