Why certificates give subdomains away
Publicly trusted certificate authorities submit every certificate they issue to Certificate Transparency logs, append-only public records specified in RFC 6962 and revised in RFC 9162. Major browsers reject certificates that are not logged, so in practice every HTTPS hostname with a public certificate is on record. The hostnames sit in each certificate's Subject Alternative Name field, readable by anyone.
That makes the logs a history of a domain's HTTPS hosts. If a certificate was ever issued for vpn.example.com or jira-test.example.com, the name stays in the logs after the host is gone. The scanner queries a public CT search index for certificates covering names under your domain, strips the *. prefix from wildcard entries and keeps up to 2,000 distinct names.
How the scan runs
Candidates come from two places: the certificate logs and a built-in list of 56 common hostnames (www, mail, api, dev, staging, vpn, ns1 and similar). Names from certificates are resolved first, shortest first, then the wordlist. Up to 120 names are checked for A, AAAA and CNAME records through the public resolvers Cloudflare 1.1.1.1, Google 8.8.8.8 and Quad9 9.9.9.9. Any beyond that are listed as Not checked.
Before resolving, the scanner asks for a random hostname that cannot exist. If an address comes back, the zone has a wildcard record, and wordlist guesses that resolve only to that wildcard address are thrown out. Wordlist names that do not resolve are dropped as noise. Certificate names are always kept, because a name that once had a certificate is worth knowing about even when it is dead.
Reading the table
Rows are sorted with resolving names first, then alphabetically. Status is Resolves when the name has an A or AAAA record, No DNS when it has neither and Not checked when it fell outside the 120 name budget. The Addresses / CNAME column shows the alias target, if any, and up to three addresses. Source says whether the name came from a CT log, the wordlist or both.
A row that says Resolves with an empty address column points at a private address such as 10.0.0.5. The scanner does not print internal addresses that leak into public DNS. The CT logs tile shows how many certificates the index returned and which index answered. If it reads Unavailable, a warning explains that the search timed out or the indexes were down, and the table holds wordlist results only.
What to do with the findings
For your own domain the list is a cleanup queue. Confirm each live name with DNS Lookup, follow alias chains with CNAME Lookup, and use IP Lookup to see whose network an unfamiliar address belongs to. Then deal with each kind of leftover.
- Dead names from old certificates: remove any leftover DNS records and note the name as retired.
- Aliases to services you no longer use: delete them before someone else claims the target.
- Test and staging hosts open to the internet: put them behind authentication or an allowlist.
- Internal names on public certificates: switch to a wildcard certificate or a private CA so future names stay out of the logs.
What a passive scan cannot find
Coverage has gaps in both directions. A subdomain that never had a publicly trusted certificate and is not one of the 56 common names will not appear. Hosts covered by a wildcard certificate show up only as the wildcard, not by name. Log entries are never deleted, so a dead host stays in the list. And because the tool never connects to the hosts, Resolves says only that a DNS record exists, not that a service answers.
Very large domains can exceed the time limit on the certificate search, in which case you get the warning and a partial result. A DNS lookup that times out is shown as No DNS, so re-run before treating a name as dead. The scan has a per-minute limit and a daily cap per IP address, and results are not stored.