Certificate Transparency for DNS Discovery

The short answer

Certificate Transparency (CT) is a system of public, append-only logs that record TLS certificates as certificate authorities (CAs) issue them. Every certificate lists the DNS names it is valid for, so the logs double as a large, searchable history of hostnames. For a domain owner, that is a useful inventory source: query the logs for your domain, resolve every name you find, and look for hosts you did not know about, names that point at services you no longer use, and certificates you did not request.

Use it on your own domains first

CT data is public, and attackers read it too. The best defense is to look before they do: find the forgotten staging site, the old marketing host, and the CNAME that still points at a deleted cloud resource, and clean them up.

How Certificate Transparency works

CT was specified in RFC 6962, Certificate Transparency, and revised as RFC 9162, Certificate Transparency Version 2.0. Its goal is accountability for CAs. If any CA issues a certificate for your domain, whether by mistake or because it was tricked, the certificate becomes visible in public logs where you can find it.

The flow is short. Before issuing a certificate, the CA submits a precertificate to several independent logs. Each log returns a signed certificate timestamp (SCT), a promise to include the entry. The CA embeds those SCTs in the final certificate, and major browsers expect them before they trust a publicly issued certificate. The logs themselves are Merkle trees, a hash structure that lets anyone check that entries were never removed or rewritten.

Domain owner
requests certificate

Certificate authority
logs precertificate

CT logs
return SCTs

Monitors and search sites
index every name

Monitors download the logs and index them. Search services such as crt.sh, a public Certificate Transparency search engine, make that index queryable by domain name.

What CT reveals about your DNS names

Each certificate carries its hostnames in the Subject Alternative Name (SAN) extension as dNSName entries. A single certificate can list one name or dozens. From a DNS point of view, CT can show you:

Hostnames that exist, or once existed, under your domain, including ones that are not linked from anywhere.
Naming patterns that hint at environments, such as staging, dev, vpn, or per-customer names.
Which CAs issue for your domain, and when, which you can compare with your CAA policy.
Wildcard certificates such as *.example.com, which cover names without listing them.

It also has clear limits. CT only covers publicly trusted certificates, so names served with certificates from a private internal CA are absent. Hostnames that never had their own certificate, or that are covered only by a wildcard, do not appear. And CT is historical: a name in a certificate from three years ago may no longer exist in DNS at all. Treat CT as one inventory source next to your zone files, not as the complete list.

Searching crt.sh for your domain

The crt.sh web interface accepts a domain, and the % character works as a wildcard, so %.example.com matches every name under the domain. Adding output=json returns machine-readable results that you can process with jq. In a URL, % must be encoded as %25. The service is shared and free, so keep queries modest and cache the results.

$ curl -s 'https://crt.sh/?q=%25.example.com&output=json' \
    | jq -r '.[].name_value' | tr 'A-Z' 'a-z' | sort -u
*.example.com
api.example.com
legacy-shop.example.com
mail.example.com
staging.example.com
status.example.com
www.example.com

The name_value field can hold several names separated by newlines, which is why the output is flattened and de-duplicated. Each JSON entry also includes the issuer name and the not_before and not_after dates, which help you tell current names from historical ones.

Turning CT results into a DNS inventory

A list of names is only the start. Resolve each one and sort the results. A quick loop with dig is enough for a small domain:

$ for h in api legacy-shop mail staging status www; do
    for type in A AAAA; do
      dig +noall +comments +answer +authority "$h.example.com" "$type"
    done
  done

Inspect both A and AAAA results and their status: an empty A answer can be an IPv6-only host, NOERROR/NODATA is different from NXDOMAIN, and SERVFAIL or a timeout is a query failure. Follow any CNAME to its final target and check both address families before describing it as addressless. A rough triage table:

What you see	What it usually means	What to do
Resolves to your own infrastructure	Live, expected host	Confirm it has an owner and is patched
Resolves to an address nobody recognizes	Forgotten host, or a cloud IP since reassigned	Find the owner or remove the record
CNAME to a third-party service whose target is absent or has neither A nor AAAA data	Possible dangling record	Verify the provider-specific resource state and ownership; then remove unused DNS or restore the resource
NXDOMAIN, or no A or AAAA data	The name is absent or lacks address records; this does not prove retirement	Check status, CNAME targets, other record types and ownership before removing anything
Certificate from a CA you do not use	Another team, a vendor, or mis-issuance	Investigate and review CAA records

The dangling CNAME case is the dangerous one. If a record points at a cloud bucket, app platform, or SaaS hostname that was deleted, someone else may be able to claim that resource and serve content on your name. Subdomain Takeover Attacks: What They Are and How to Stop Them covers how to confirm and fix it.

Defensive habits built on CT

Beyond a one-off inventory, CT supports a few ongoing practices:

Monitor new issuance. Several CAs and security vendors offer alerting when a new certificate for your domain appears in the logs. An unexpected certificate is an early warning of a compromised DNS account, a misconfigured automation, or a lookalike phishing setup.
Restrict issuers with CAA. CAA records tell CAs which of them may issue for your domain. CT then lets you check that the policy is respected. See CAA Records – Deep Dive.
Think before naming hosts. Any name in a public certificate becomes public. Avoid putting customer names, project code names, or internal details into hostnames that get publicly trusted certificates.
Weigh wildcards carefully. A wildcard certificate keeps individual names out of the logs, but the same private key then works for every name under it, so a compromise of one server affects all of them. Wildcard DNS Risks covers the DNS side of that trade-off.
Close the loop with DNS clean-up. When a service is retired, remove its DNS records at the same time as the cloud resource, in that order: DNS first, then the resource.

Stay in scope

CT data about other organizations is public, but probing their hosts is a different matter. Run the resolve-and-check workflow on domains you own or are authorized to assess.

How DNS Panopticon helps

The Advanced scan modes, available on the paid plan, use CT data directly. Website Recon Advanced adds a Certificate History card listing certificates logged for the domain and its subdomains with issuers and dates. Domain Visualizer Advanced takes the names found in those certificates and looks each one up in DNS, so you can see which still resolve and where they point. It caps the number of outbound lookups per scan, and when a domain has more names than the cap allows, the report lists the names it did not look up.

For a zone you control, export it and load it into Zone Analyzer to compare what CT says exists with what your zone actually publishes. Names present in CT but missing from the zone are usually retired. Names in the zone that point at third-party services are the ones to verify.

FAQ

Does Certificate Transparency show every subdomain I have?

No. It only shows names that appear in publicly trusted certificates. Names that never had a certificate, names covered only by a wildcard certificate, and names using a private internal CA will not appear, so combine CT data with your zone files and other inventories.

Can I keep a hostname out of CT logs?

Not if it appears in a publicly trusted certificate, because browsers expect those certificates to be logged. If a name must stay private, use a wildcard certificate or a private CA for it, and remember that DNS itself is not secret either.

What should I do if CT shows a certificate I did not request?

First check whether another team or a service provider issued it for a legitimate reason. If nobody did, treat it as a possible mis-issuance or compromise, contact the issuing certificate authority, and review your CAA records and DNS account security.