Practical documentation · Authorized use only

Subfinder

Subfinder discovers subdomains from passive sources. It is a strong first step for an authorized external attack-surface inventory because it avoids probing discovered hosts, but every name still needs ownership and DNS validation.

OSINTReconSubdomainsGolang

Start safely and get useful results

Best for

• Passive subdomain inventory
• Continuous authorized exposure review

Not for

• Host scanning without scope confirmation
• Assuming every historical DNS name is live

Before you run anything

• Document the authorized target, time window, success criteria, data-handling rules, and a named stop contact before you begin.
• Confirm the installed version with the tool’s version or help command, then compare its documented behavior with the linked upstream project before relying on any option.

Practical workflows

Beginner

Run passive discovery for an owned domain

Scenario: Build an initial asset candidate list for example.com.

subfinder -d example.com -silent -o subdomains.txt

Use the explicitly authorized root domain and save only candidate names.

Expected use: Expect duplicates, historical names, and third-party service names; do not scan them automatically.

Intermediate

Keep source attribution for review

Scenario: An analyst needs to understand why a name appeared.

subfinder -d example.com -all -v -o subfinder-evidence.txt

Retain verbose source context only where permitted by the engagement’s data policy.

Expected use: Source overlap increases confidence but does not establish current control or scope.

Interpret results like an analyst

• Validate DNS and ownership before treating a candidate as an asset.
• Review cloud-provider or vendor-hosted names with the owner; they may be legitimate delegated services.

Common mistakes and operating tips

Avoid

• Turning passive discovery output into a scan list without asset authorization.
• Publishing source data that contains personal or third-party information.

Operational discipline

• Treat command output as evidence, not a conclusion: retain the command, version, scope, timestamp, and a redacted result in the engagement record.
• Start with the smallest safe scope, validate expected behavior in a lab or pilot, then expand only when the authorization and monitoring plan support it.

Verify against the current upstream

Tool behavior and release syntax can change. Treat this guide as practical operating context, then verify version-specific details against the upstream project before an assessment.

Open authoritative upstream documentation