How code-saksham-hash/recon_cli works
1. Repository shape
- This is a very small, single-purpose Python CLI project.
- The entire application appears to live in recon.py, with requirements.txt defining runtime dependencies and Dockerfile providing a containerized execution path.
2. Primary execution model
- The tool runs as a command-line program invoked with a target domain argument, e.g. python recon.py -d example.com.
- There is no evidence of a server, background worker, or multi-service deployment; the architecture is centered on one process that performs a set of reconnaissance tasks sequentially.
3. Core responsibility
- The main job is DNS and domain intelligence gathering for a single target domain.
- It combines passive data collection, active DNS probing, and IP/ASN enrichment into one reporting pipeline.
4. Input boundary
- The only explicit user input is the target domain.
- From that input, the tool derives subdomains and DNS queries; there are no signs of local database state, authentication, or user management.
5. DNS resolution subsystem
- One subsystem queries standard DNS record types: A, MX, TXT, NS, and CNAME.
- This is likely the deterministic, low-latency part of the tool and depends on local DNS resolution through dnspython.
6. Passive enumeration subsystem
- Subdomain discovery is augmented via crt.sh certificate transparency logs.
- This is an external HTTP dependency and an important architectural boundary: the tool is only as complete as the public CT data returned by crt.sh, and the README notes automatic retry behavior for that lookup.
7. Active enumeration subsystem
- The tool also performs brute-force subdomain discovery using a 60+ entry wordlist of common prefixes.
- Architecturally, this is the active probing path: it generates candidate names locally, then validates them by DNS lookup against the target domain.
8. Network intelligence enrichment
- The ASN lookup path resolves IP address metadata such as ASN, organization, country, city, and reverse DNS.
- This enrichment depends on an external IP intelligence service (ipapi.co per the README), making it another network-facing integration distinct from DNS queries.
9. Output/reporting layer
- Results are rendered in the terminal using Rich, with structured and color-coded output.
- The reporting layer is console-first rather than file-first; no persistent report storage or API output format is indicated.
10. Runtime and dependencies
- The project targets Python 3.8+.
- Key dependencies are dnspython for DNS, requests for HTTP to external services, and rich for terminal presentation.
- The Dockerfile packages these dependencies into a container image, giving the project a second runtime boundary: native Python execution or containerized execution.
11. End-to-end data flow
- Flow is: user supplies domain → tool enumerates subdomains passively and actively → tool resolves DNS records for discovered names → tool enriches with IP/ASN metadata where applicable → results are formatted in the terminal.
- The only external systems in the architecture are public internet services and DNS infrastructure; there are no internal microservices or local data stores.
12. Architecture summary for diagramming
- This repo should be drawn as a single CLI application with three outbound integrations: DNS resolver traffic, crt.sh HTTP requests, and ipapi.co HTTP requests.
- Around that core, show two discovery modes (passive and brute-force) feeding into a shared resolution/reporting stage, with Rich as the final presentation boundary.
Main entry points: recon.py recon.py · Dockerfile Dockerfile · requirements.txt requirements.txt
Components 12
Runtime
Single-process CLI execution and packaging boundary
- Target domain · User-supplied domain to investigate
- recon.py · Main CLI entrypoint that coordinates reconnaissance steps
recon.py - Passive enum · Discovers subdomains from certificate transparency data
recon.py - Brute-force · Generates common subdomain candidates and validates them via DNS
recon.py - DNS resolve · Queries A, MX, TXT, NS, and CNAME records for discovered hosts
recon.py - ASN enrich · Enriches resolved IPs with ASN and location details
recon.py - Rich output · Formats and prints structured results in the console
recon.py - Dockerfile · Container image path for running the CLI in Docker
Dockerfile - requirements.txt · Python runtime dependencies for DNS, HTTP, and terminal output
requirements.txt
External Services
Public DNS and HTTP dependencies used during reconnaissance
- crt.sh · Certificate transparency data source for passive enumeration
- DNS network · Public DNS infrastructure used for resolution and validation
- ipapi.co · External IP intelligence service for ASN and geo metadata
Connections 16
- Target domain → recon.py: invoke · CLI receives the target domain
- recon.py → Passive enum: start · Orchestrator launches passive discovery
- recon.py → Brute-force: start · Orchestrator launches active subdomain probing
- Passive enum → crt.sh: query · Fetch certificate transparency subdomains
- Brute-force → DNS network: probe · Validate candidate subdomains through DNS lookup
- recon.py → DNS resolve: resolve · Shared DNS record resolution for discovered names
- DNS resolve → DNS network: lookup · Resolve A, MX, TXT, NS, and CNAME records
- DNS resolve → ASN enrich: extract IPs · Pass resolved addresses into enrichment
- ASN enrich → ipapi.co: enrich · Request ASN and geo metadata
- Passive enum → recon.py: subdomains · Return discovered hostnames
- Brute-force → recon.py: hits · Return valid brute-force discoveries
- DNS resolve → recon.py: records · Return DNS record data for reporting
- ASN enrich → recon.py: metadata · Return ASN and reverse DNS details
- recon.py → Rich output: render · Send combined results to console reporting
- recon.py → requirements.txt: depends on · Python dependencies required for execution
- recon.py → Dockerfile: package · Optional containerized execution path