Recon.ph
Methodology and supported formats
Learn how Recon.ph imports local asset evidence, normalizes hostnames, detects changes and handles ambiguous or unsupported records.
What the workspace does
The workspace merges input files into two snapshots, baseline and current, then compares normalized hosts and DNS record evidence. A snapshot can include several sources. Changes are computed locally in your browser; no external DNS resolution, TLS connection, third-party API or server-side scanning occurs.
If you provide only the current snapshot, the workspace produces an inventory; it does not invent historical changes.
Accepted inputs
| Input | Supported form | Notes |
|---|---|---|
| BIND-style DNS zone | .zone, .db, .bind, .txt | Single-line records for A, AAAA, CNAME, MX, TXT, NS, CAA and common DNS types. $ORIGIN, @, TTL and optional IN are supported. Not a complete RFC zone parser: multiline parentheses, $INCLUDE and unusual directives produce warnings or may require normalization. |
| CSV | .csv | Headers such as hostname/host/name, type, value/content/target/ip. Missing type becomes DISCOVERED, meaning host evidence rather than a DNS answer. Comma, semicolon and tab delimiters supported. |
| JSON / JSONL | .json, .jsonl, .ndjson | Flat arrays or newline-separated objects with a host, hostname, fqdn, name or domain field, plus optional type and value. Nested vendor-specific output is not supported. |
| Hostname list | .txt | One fully qualified domain name per line; # comments allowed. No IP probing. |
The published example files establish the accepted shapes. For a large vendor-specific export, first convert it to the normalized CSV header hostname,type,value.
Scope and normalization
- Names are trimmed, converted to lowercase and stripped of a final DNS root dot. Relative BIND names are resolved against
$ORIGINwhen supplied. - DNS record values are trimmed. Hostname-valued records such as CNAME, MX and NS are normalized, while TXT strings remain distinct evidence.
- Duplicate host/type/value rows are merged, retaining filenames as source provenance.
- Optional base-domain scope admits the exact domain and its subdomains, not lookalike suffixes.
- A standalone discovered host is not treated as an A or AAAA answer.
- Wildcards remain wildcard records; they do not prove that all possible subdomains were observed.
What counts as a change
A new host is present in the current snapshot but not the baseline; a removed host is the reverse. A record addition/removal is a difference in the normalized (hostname, type, value) evidence set. If a CNAME target changes, expect a removed record and an added record, not an automatic 'compromised' label.
Only supplied evidence is compared. Differing tools, incomplete exports, wildcard handling, TTLs, response timing, split-horizon DNS and propagation can produce apparent changes that require validation. TTL differences alone are not tracked.
Safe use and size limits
The workspace accepts up to 5 MB per file and 30,000 parsed records per file. It holds data in memory, creates files locally when you download and does not persist snapshots across page reloads. Exclude secrets and unrelated personal data from exports. Use only assets within your authority.
CSV output neutralizes spreadsheet formula-leading values for safer opening in common spreadsheet apps. Keep original source files independently.
Evidence quality
For follow-up investigation, note export date, export method, DNS view/account, and scope. A difference is a lead for verification, not a finding of vulnerability or malicious ownership. The worked snapshot example shows the distinction.