I've recently been organizing my Information Gathering notes for a cybersecurity project I'm maintaining on GitHub.
While reviewing the material, I kept coming back to the same idea: knowing which command to run is useful, but understanding what the result actually tells you is just as important.
Here are three distinctions I think are worth understanding when learning reconnaissance.
1. Finding a subdomain doesn't mean it's still active
Certificate Transparency logs are useful for discovering hostnames associated with TLS certificates.
But finding a hostname in a certificate doesn't necessarily mean the hostname still resolves, or that a web service is currently running there.
A certificate might be historical, and the infrastructure may have changed since it was issued.
This is why I think it's important to separate three questions:
- Was this hostname found in a source?
- Does it currently resolve in DNS?
- Is there a service responding at the destination?
They require different checks, and the results shouldn't be treated as interchangeable.
2. DNS records don't tell you everything about the infrastructure
Commands such as dig example.com A or dig example.com MX can help identify published DNS information.
But the results need context.
An A record gives you an IPv4 address associated with a name. It doesn't prove that an HTTP server is reachable there.
And if a website uses a reverse proxy or CDN, the address returned by DNS may belong to the intermediary rather than the origin server.
DNS provides useful evidence, but not a complete picture of the application.
3. Nmap -Pn doesn't prove a host is online
Another distinction worth remembering is the difference between discovering a host and scanning its ports.
For example:
sudo nmap -sn 192.0.2.0/24
This performs host discovery without the normal port scan.
Now consider:
nmap -Pn -sT -p 80,443 192.0.2.10
The -Pn option tells Nmap to skip ordinary host discovery and proceed with the requested scan.
It doesn't mean Nmap has confirmed that the host is online.
An unanswered discovery probe could mean the host is offline, but it could also mean the selected probes were blocked or went unanswered.
The addresses above are documentation examples, not results from an actual assessment. Network testing should only be performed against authorized targets.
Why I'm documenting these details
I'm still studying cybersecurity, and writing notes helps me revisit concepts that are easy to misunderstand.
I've been collecting these explanations in a free, open-source project called Cybersecurity Survival Notes.
The new Information Gathering section also covers RDAP and WHOIS, DNS enumeration, OSINT, web technologies, and service detection.
You can read the notes here:
https://radz-04.github.io/Cybersecurity-survival-notes/
Or explore the Markdown files on GitHub:
https://github.com/Radz-04/Cybersecurity-survival-notes
If you notice anything inaccurate or unclear, corrections and technical feedback are welcome.

