Finds the hosts under a domain and flags the ones that look private.
Every host you publish is a way in. The ones that get attacked are rarely the main website: they are the staging copy with last year's code, the admin panel somebody opened for a week, the old VPN endpoint nobody switched off. Nothing lists them for you, so most teams have no inventory of their own names.
DNS cannot be asked for the names under a domain, so they have to be found. This tool reads the public certificate logs, which record a name every time a certificate is issued for it, and tries the host names that nearly every domain uses. Each candidate is resolved, and what answered is listed with its address. Names that look internal are marked, because those are the ones worth a decision.
There is no question in DNS that means list everything under this domain. The one mechanism that does it, a zone transfer, is refused by every properly run nameserver, and should be. So a name is only found if something public points at it, or if somebody guesses it. Both sources are used here, and each has a blind spot worth knowing.
| Source | Finds | Misses |
|---|---|---|
| Certificate Transparency logs | Any host that has had a publicly trusted certificate issued for it, including ones deleted years ago. | Hosts covered by a wildcard certificate, hosts with no certificate, and anything on a private certificate authority. |
| Common host names | The hosts most domains run: www, mail, vpn, api, staging and the rest. | Anything named in a way nobody would guess. |
| Your own DNS zone | Everything, because it is the authoritative list. | Nothing, but only the domain's owner can export it. |
| Search engines and archives | Hosts that were linked from somewhere public. | Anything never linked, which is most internal systems. |
Finding a host is not the same as finding a problem. Work through them in this order, because the first two can be settled in minutes and the rest need an owner.
The worst finding is not a forgotten server. It is a name that points at a cloud service that no longer exists: a CNAME to a storage bucket, a site host or a help desk that was deleted while the DNS record stayed. On many services anyone can create a resource with that name and start serving content, on your domain, with a valid certificate. Cookies scoped to the parent domain can go with it.
The fix is the same every time: delete the DNS record when you delete the thing it points at, and make that part of how a service is decommissioned rather than something somebody remembers.
The same two sources, asked directly. The first queries a certificate log, the second resolves a list of candidate names, and the third asks whether a zone transfer is allowed, which it should not be.
curl -s 'https://crt.sh/?q=%25.example.com&output=json' |
python3 -c 'import json,sys;print(*sorted({n for r in json.load(sys.stdin) for n in r["name_value"].split()}),sep="\n")'
for h in www mail vpn api staging admin; do host $h.example.com; done
dig AXFR example.com @ns1.example.comEverything here is a public certificate log and ordinary DNS lookups, which is the same information a browser uses. Nothing is sent to the hosts themselves. Still, act on what you find only for domains you own or are permitted to test.
A wildcard certificate covers every host under a domain without naming any of them, so those names never reach the logs. If the host name is not one of the common ones either, nothing public points to it. The result says when a wildcard is in use.
It is listed because it still resolves. A name that resolves to a service you have deleted is worse than one that does not resolve at all: somebody else can often claim the service and serve content on your name.
From your own DNS zone, which your provider can export. Use this tool to find what is published that your zone file does not explain.