A passive result is a lead, not a live DNS answer
Passive subdomain discovery aggregates observations from sources that may have different collection times and coverage. A name in an export could be historical, no longer resolvable or unrelated to the current organization. It is still valuable as evidence that a source observed the name, provided you keep its provenance.
A DNS zone export answers a different question: what records were configured in a specific zone view when the file was captured. A live DNS lookup answers what a queried resolver returned at its observation time. None of these alone proves an application is reachable or controlled by the organization.
| Observation | Appropriate conclusion | Not established |
|---|---|---|
Passive result: portal.example.com | The named source reported this host | Its IP, reachability or present ownership |
Zone export: portal.example.com A 192.0.2.40 | This A record was configured in the exported view | That every public resolver returns it |
| Authorized DNS lookup | A resolver returned an answer at that moment | An application is healthy or its ownership is verified |
How Recon.ph keeps those facts separate
A supported flat JSONL input can contain:
{"host":"portal.example.com","source":"fictional-example"}
The workspace classifies this row as DISCOVERED. If a zone export also contains portal.example.com A 192.0.2.40, it retains separate record evidence for the same host. A single host can therefore have several evidence types. Recon.ph does not make a network request to resolve the name or verify its service.
The JSONL source property in this illustrative input does not become a source label in the normalized output; the workspace records the imported filename. Keep detailed provider names and collection times in your external review notes. See supported formats for the exact accepted fields.
Compare equivalent evidence across time
Imagine that a passive export lists old.example.com on Monday but a Tuesday export does not. That difference might reflect deletion, a collection setting, a source outage or historical-data retention. It is not proof of DNS removal.
For a more defensible comparison, use the same tools, options, scope and intended source coverage at both collection times. Treat a second source as independent corroboration, not as a replacement for comparability. Preserve the original files and record missing coverage.
Practical review checklist
- Identify which data source reported each hostname and when.
- Record whether it is a passive sighting, configured record or authorized live observation.
- Check the exact base-domain boundary and exclude lookalike suffixes.
- Import comparable exports into the workspace, then review its warnings.
- Mark apparent removals needs verification until an authorized source confirms the intended state.
The asset inventory guide explains the broader evidence model. The worked snapshot example demonstrates concrete DNS changes rather than passive-list fluctuations.
Primary references
For a bounded, repeatable example of collecting selected public DNS answers from known hostnames, see the Linux, macOS and Windows command-line guide. Such lookups are evidence for specific names and types, not a full zone backup.