Skip to main content

Subdomain Discovery & Certificate Transparency

How we find subdomains, why they’re publicly visible, and how to reduce future exposure.

Passive OSINT Only — DNS Tool performs passive OSINT collection. We read publicly available DNS records, check publicly accessible URLs, and produce intelligence from publicly observable data. We do not attempt to exploit any vulnerability, bypass any access control, or interact with any system in a way that requires authorization.

Because subdomain names are often published indirectly, even if you never intended them to be. The biggest source is Certificate Transparency (CT): if a hostname ever appeared on a publicly trusted TLS certificate, it is recorded in public CT logs. CT logs are designed to be public and append-only, specifically so the world can audit certificate issuance.

Separately, subdomains can also be discovered through normal DNS behavior (common names like www, mail, api, etc.), plus CNAME chains that point to third-party infrastructure.

DNS Tool uses multiple layers of discovery, all based on public data and open standards:

Certificate Transparency Scanning

We parse Certificate Transparency entries to extract subdomain names that have appeared on publicly logged certificates.

Wildcard Certificate Detection

Wildcards like *.example.com don’t list every subdomain, but they signal that subdomains exist and help avoid false “0 subdomains” results.

DNS Probing + CNAME Traversal

We probe common service names (e.g., www, mail, api, admin, vpn, sso) using standard DNS lookups and follow CNAME chains to show where each hostname actually points.

In your report output, we explicitly disclose this: subdomains are discovered via CT logs (RFC 6962), DNS probing, and CNAME traversal.

  • CT-only and wildcard-blind: they query CT but treat wildcard cert entries poorly, incorrectly reporting “0 subdomains” when only *.domain entries exist.
  • No DNS probing layer: they won’t try common names, so they miss real-world service hostnames that never appear in CT.
  • Paid OSINT dependency: some tools rely on paid passive DNS or subdomain datasets. DNS Tool sticks to public, open-source layers unless a user opts into their own API key.

Certificate Transparency (RFC 6962) describes publicly auditable, append-only logs of certificates so domain owners and auditors can detect misissuance.

In practice, modern ecosystems enforce CT: for example, Apple requires publicly trusted TLS server certificates to comply with their CT policy (including SCT requirements).

Translation: if you put a hostname on a public certificate, you should assume that hostname will be visible in CT logs.

No. CT logs are designed to be append-only. Once a certificate containing a name is logged, that historical fact remains publicly auditable.

What you can do is reduce future exposure — see the checklist below.

Reality: You can’t erase history. You can stop creating new public breadcrumbs.
  1. Stop issuing publicly trusted certs that contain sensitive hostnames.
    If it needs to remain private, don’t put internal-x.example.com on a public CA certificate.
  2. Use a private CA / internal PKI for internal-only hostnames.
    Internal sites can still be HTTPS without public trust anchors. Deploy trust via MDM, GPO, Jamf, etc.
  3. Use split-horizon DNS for internal hostnames.
    Internal names should only resolve inside your VPN/private network. Public resolvers should return NXDOMAIN.
  4. If it must be public, assume it will be discoverable.
    If a hostname is Internet-reachable and uses a public cert, treat it as public metadata.
  5. If you must use a wildcard, know what it does and does not hide.
    A wildcard (*.example.com) can reduce the number of explicit hostnames on certs, but the wildcard itself is still visible in CT logs.

Public hostname + public cert

= public metadata. Treat it as discoverable.

Internal-only hostname
  • Internal DNS only
  • Internal PKI only
  • Not referenced by public certs, docs, or DNS records

No. This is OSINT + DNS, not intrusion:

  • We use public CT history and standard DNS queries.
  • Our probing is limited to common service names (not exhaustive brute force).
  • We disclose the source attribution in the report output (“Certificate Transparency + DNS Intelligence”).

Yes. That’s part of the product philosophy: conclusions should be independently verifiable.

Verify it yourself:
# Check if a common subdomain resolves:
dig +short A www.example.com
dig +short CNAME www.example.com

# Spot-check CT presence:
# Visit https://crt.sh/?q=example.com
# to search for certificates containing your domain.
Straight talk about your data.

We use two cookies, both essential:

  • _csrf — Prevents cross-site request forgery. Required for form submissions. Security-only.
  • _dns_session — Only exists if you choose to sign in. No account required to use DNS Tool.

We log your IP address for two reasons: rate limiting (so nobody abuses the service) and security (identifying malicious actors and complying with legal obligations). We check source geography for analysis accuracy — DNS responses vary by region, and knowing which resolver answered from where makes the science better.

No tracking cookies. No analytics cookies. No ad networks. No data brokers. Our code is open-core — the application framework is publicly available under BUSL-1.1 with timed Apache-2.0 conversion. Verify it yourself.

If you create an account and want out, account deletion removes your login and scan history. Public domain analyses remain available because they contain only public DNS records, already hashed. Full details: Privacy Pledge.