NetSight
IP …
Updated

Subdomain Finder

Discover subdomains for any domain by aggregating Certificate Transparency logs, passive DNS, threat-intel feeds and web archives. Passive discovery, no probing of the target.

About subdomain discovery

We enumerate subdomains by aggregating multiple passive intelligence sources: Certificate Transparency logs, passive-DNS feeds, threat-intel datasets and web archives. No packets are sent to the target itself, only public datasets are queried. This is pure passive reconnaissance. Each discovered host is then resolved over DNS-over-HTTPS so you can tell live hosts from stale records, and hosts confirmed by several independent lookups are marked.

Method

  • Several independent passive datasets are queried in parallel and merged.
  • Every host is resolved over DNS-over-HTTPS; live hosts are separated from stale records.
  • Resolved IPs are checked against Cloudflare's network so you can see which hosts are proxied.

Sources run isolated, so a single provider being down only removes its results, never the whole lookup. Wildcard entries (*.example.com) are filtered and duplicates are merged. Internal or expired subdomains may still appear.

When it's useful

  • Mapping an organization's external attack surface before a penetration test.
  • Finding forgotten staging or admin endpoints that still have certs.
  • Due diligence on a domain you're about to acquire.

How it works

The lookup collects hostnames from two kinds of public data. The first kind is Certificate Transparency data: every publicly trusted TLS certificate is recorded in append-only public logs, and a certificate lists the hostnames it covers. The second kind is passive DNS and archive data: historic observations of hostnames from resolvers, web crawls, URL scanners and web archives. Several independent services of both kinds are queried in parallel from the server, and the domain name you enter is sent to them as the search term.

The raw results are normalized before they are merged. Names are lowercased, a leading *. and a trailing dot are removed, and anything that is not a hostname below the searched domain is discarded. The remaining names are de-duplicated, and for each name the tool counts how many sources reported it.

Each name is then looked up over DNS-over-HTTPS for an A record, which gives the IPv4 address if one exists. At most 600 names are resolved per lookup. When there are more, names reported by several sources and common service labels such as www, mail or api are resolved first, while very long or random-looking names are resolved last. Names beyond the cap are listed as not checked. Resolved IPv4 addresses are compared with the published Cloudflare address ranges to flag proxied hosts. Finished results are cached, so repeating a lookup shortly afterwards can return the earlier result.

How to read the results

  • found: the number of distinct hostnames collected from all sources, whether or not they currently resolve.
  • resolve: how many of the checked names returned an A record at lookup time. These are shown first in the list.
  • IP address: the first IPv4 address returned. If it belongs to a reverse proxy or CDN, it is the address of that service, not of your origin server.
  • Cloudflare badge: the address lies in a published Cloudflare IPv4 range, so the host is very likely served through that proxy.
  • The multiplier badge (for example x2): the number of independent sources that reported the name. A higher number means the name is less likely to be an artifact of a single data set, but it says nothing about whether the host is still in use.
  • no DNS: no A record was returned. The name may be retired, may exist only as an IPv6 or CNAME-only record that did not yield an IPv4 answer, or may be reachable only from inside a private network.

What a result does not prove

A subdomain that appears in a certificate was valid at some point, but certificates are often issued months in advance of use and remain in the logs after the service is gone. A name seen in passive DNS or an archive may have been decommissioned years ago. Conversely, a host that is absent from the list may still exist: internal names, names covered only by a wildcard certificate, and names that were never published anywhere public cannot be found passively.

Wildcard certificates deserve special attention. A certificate for *.example.com shows that the organization uses wildcard coverage but does not reveal which names sit behind it, which is one reason complete enumeration is not possible from public data alone. The tool strips the wildcard prefix and does not list the bare apex domain as a subdomain.

Examples

Example 1: a typical organization

Input: example.com. Suppose the result lists www, mail, api and staging below the domain, with the first three resolving and staging showing no DNS. The first three are live. staging appeared in certificate logs or an archive but has no A record now, so it is likely a retired environment. Check whether its DNS entry was removed deliberately and whether any other record still points at the old system.

Example 2: mostly proxied hosts

Input: example.org. If most resolving hosts carry the Cloudflare badge, the addresses shown are proxy addresses. They cannot be used to locate the origin servers, and any port scan of those addresses would test the proxy, not the application behind it.

Example 3: a large domain

Input: a domain with several thousand certificates. The list may exceed the 600 resolution cap, so part of it is shown as not checked. Those names are still real findings from the sources, but their current DNS state is unknown. Copy them and resolve them with your own tooling if you need a complete picture.

Common problems and how to fix them

  • The result is empty. The domain may have no publicly logged certificates and no archive history, or the domain was entered with a typo. Enter only the registrable name (for example example.com), without a path or port.
  • The lookup reports that providers are unavailable. Every source failed or timed out. Wait a minute and try again. A single failing source only removes its own results.
  • A known subdomain is missing. It has probably never appeared in a public certificate, passive DNS record or archive. Names behind a wildcard certificate or on a private network stay invisible.
  • Many names show no DNS. This is expected for older domains. Use the list to find forgotten records and certificates, not as a list of live systems.

Questions

Is this legal?
Yes. Only public datasets are queried and no packets are sent to the target itself. This is pure passive reconnaissance.
Why don't I see a subdomain I know exists?
If it was never exposed in any public dataset (no TLS certificate, no passive-DNS record, no archive entry), it won't appear. Internal-only or self-signed subdomains are invisible to passive discovery.
How fresh are the results?
Most sources update within minutes to hours. Newly issued certificates tend to show up quickly; some archives can lag by days.
How do I find all subdomains of a domain?
No method finds every subdomain from the outside. Combining Certificate Transparency data, passive DNS and archives, as this tool does, finds most publicly exposed names. Names that are internal, covered only by a wildcard certificate or never published are only visible with access to the zone itself, such as a zone transfer or the DNS provider's records.
What is a subdomain takeover?
A takeover is possible when a DNS record such as a CNAME still points to an external service that has since been deleted, so someone else can claim that name on the service. Names that appear in the results but have no current DNS answer, or that point to a resource you no longer control, are worth reviewing for this.
Why does a subdomain show no DNS record?
The tool only looks for an A (IPv4) record at lookup time. A missing answer can mean the host was retired, the record exists only for IPv6, the name exists only in an internal DNS view, or the name was beyond the 600-name resolution cap and was not checked.
What does the Cloudflare badge mean?
It means the resolved IPv4 address is inside a published Cloudflare address range, so traffic to that host most likely passes through the proxy. The IP shown is then the proxy's address and not the origin server's.
What do the numbers next to a subdomain mean?
The number is how many of the independent data sources reported that name. It is a rough indicator of how well attested the name is, not a measure of whether the host is currently live.
Security Dashboard
Live vulnerability dashboard: new CVEs, early warnings and malware reports, filterable and subscribable.
Blocklist Check
Check an IPv4 address against fifteen threat feeds, grouped by category.
Reverse IP Lookup
List all domains hosted on an IPv4 address from passive DNS, with links to DNS and WHOIS.
IP Lookup
Instant geolocation, ISP, ASN, abuse history and reputation for any IPv4 or IPv6 address.