Subdomain Finder

How the subdomain finder works

The finder runs subfinder on Strix infrastructure with a fixed time budget. Subfinder queries passive sources only: certificate transparency logs, passive DNS datasets, search engines, and threat intelligence APIs. It never sends a packet to the target and it never guesses names. If a source does not answer within the budget, the result is marked partial and cached for a shorter time.

Results are normalized: lowercased, wildcard prefixes removed, names outside the domain dropped, and duplicates removed. The list is sorted by parent label so hosts under the same subtree sit together. Grouped view shows the second-level labels with the most hosts first.

What to do with the list

• Look for environments that should not be public: staging, dev, test, uat, and old version numbers.
• Look for third-party services: names that point at Heroku, S3, GitHub Pages, or Azure often become subdomain takeover candidates when the service is deleted.
• Check each live host with the headers checker and the SSL checker.
• Compare the list over time. A new host that nobody announced is a common source of breaches.

Limits

• Passive sources see only names that appear in public data. Internal names that never got a public certificate stay hidden.
• The list can include hosts that no longer resolve. Resolve and probe them before you rely on them.
• The list is capped at 1000 names. Very large organizations need a dedicated recon run.
• Lookups run against the registrable domain and are cached for 15 minutes.