Skip to content
Lesson 4 of 8

Domain and Infrastructure OSINT

6 min read

WHOIS and Domain Records

Infrastructure OSINT almost always begins with the domain. A WHOIS query reveals registration information: the registrar, creation and expiration dates, name servers, and in some cases the registrant's contact details. Although many records are now protected by privacy services (WHOIS privacy), the residual information remains valuable: the registration date can place the origin of an infrastructure, and the name servers can link several domains to the same owner.

# Basic WHOIS query: registrar, dates, name servers
whois example.com

# Quickly filter the most useful fields
whois example.com | grep -Ei "registrar|creation|expir|name server"

A useful technique is historical WHOIS, offered by services like WhoisXML or SecurityTrails, which preserves old versions of the records. Often a domain that hides its contact details today had them exposed in the past, before enabling privacy protection. Comparing historical records lets you correlate seemingly independent domains that share the same email or the same original registrant.

All of this information is public by design of the domain name system. Querying it is perfectly legal and constitutes the basis of any infrastructure reconnaissance, whether in an authorized pentest or in an audit of one's own exposure.

DNS Enumeration

The DNS system holds a map of a domain's infrastructure that can be queried legally. A and AAAA records point to IP addresses; MX records reveal mail servers; TXT records often contain SPF, DKIM, and DMARC configurations, and sometimes third-party service verifications that betray which platforms the organization uses; NS records indicate the name servers.

# Key records for a domain
dig +short example.com A       # IPv4 addresses
dig +short example.com MX      # mail servers
dig +short example.com TXT     # SPF, DKIM, third-party verifications
dig +short example.com NS      # name servers

# Zone transfer attempt (only with authorization): a misconfigured server would
# return the ENTIRE zone, a serious leak that must be reported
dig AXFR example.com @ns1.example.com

Tools like dig, nslookup, dnsx, or dnsrecon let you query these records systematically. The zone transfer (AXFR) is a classic target: if a DNS server is misconfigured and allows it, it returns the complete list of the zone's records, exposing the entire internal structure. Finding this in an audit is an important result, because it represents an information leak that must be fixed.

TXT and MX records deserve special attention for their revealing value. An SPF record authorizing include:_spf.google.com indicates Google Workspace usage; one mentioning an email marketing provider reveals that business relationship. Each piece helps reconstruct the target's technology stack.

Subdomains and Certificates

Subdomain discovery is one of the most productive techniques in infrastructure OSINT, because it expands the known surface. There are two approaches. The passive one queries sources that have already collected subdomains — passive DNS databases, engines like Amass or subfinder — without directly touching the target's infrastructure. The active one tests names via dictionary brute force, which generates traffic toward the target and should only be done with authorization.

Certificate Transparency logs are an excellent and entirely passive source. Every time a TLS certificate is issued, it is recorded in public logs. Querying crt.sh returns all certificates issued for a domain, which often reveals subdomains that appear nowhere else:

# Subdomains from certificate transparency (passive, quiet)
curl -s "https://crt.sh/?q=%25.example.com&output=json" \
  | jq -r '.[].name_value' | sort -u

# Passive enumeration with subfinder (third-party sources, no contact with target)
subfinder -d example.com -silent

This often reveals development environments (dev., staging.), internal panels (grafana., jenkins.), and forgotten services. It is one of the first queries every investigator should run. In a defensive audit, this enumeration often reveals forgotten assets (shadow IT) that the organization itself did not know were exposed, which makes it an exercise of enormous preventive value.

Shodan and Infrastructure Search

Shodan is a search engine that indexes devices and services connected to the internet rather than web pages. It lets you query which ports and services an IP or range has exposed, what software and versions they run, and what banners they return. For infrastructure OSINT it is invaluable: from a domain you can find all associated IPs and, with Shodan, learn their service surface without sending a single packet directly to the target, since Shodan already performed that scan.

# See what an IP exposes publicly (ports, services, versions)
shodan host 203.0.113.10

# Find all of an organization's assets by name in the certificate/record
shodan search 'org:"Example Inc." http.title:"login"'

# Useful filters: port, country, technology
shodan search 'ssl.cert.subject.cn:example.com port:443'

Censys and FOFA offer similar capabilities with different approaches. These engines allow searches by organization, certificate, technology, or country, and are especially useful for identifying all of an entity's assets scattered across different cloud providers.

It is important to stress that these engines only show information that services expose publicly; querying them is legal. However, attempting to connect to, authenticate against, or exploit the services found is no longer OSINT, but an action that requires explicit authorization. The ethical investigator uses Shodan to map and understand exposure, not to access systems without permission.

Mini-case: From a Domain to the Full Map

Chaining the above over our own domain, without a single active scan:

  1. whois places the age and registrar.
  2. dig TXT reveals include:_spf.google.com → email on Google Workspace.
  3. crt.sh lists vpn.example.com and jenkins.example.com → two services to review.
  4. dig +short jenkins.example.com A gives the IP; shodan host shows it responds on port 8080 with an exposed Jenkins.

Defensive conclusion: a continuous-integration server reachable from the internet is an obvious risk that should be shut down or placed behind a VPN. The entire finding was achieved with third-party sources, without touching the infrastructure and without leaving the legal framework.

Investigator OPSEC

  • WHOIS, crt.sh, subfinder in passive mode, and Shodan do not touch the target: they are quiet.
  • Direct dig against the target's DNS servers, subdomain brute force, and HTTP visits do leave a trace; reserve them for authorized engagements.
  • Use a Shodan API key dedicated to research and never upload it to a repository.
  • Control network attribution when making active queries: an identifiable IP can alert the target.

Infrastructure Checklist

  • [ ] Current and historical WHOIS queried; registrant and dates documented.
  • [ ] Key DNS records (A, MX, TXT, NS) enumerated and normalized.
  • [ ] Subdomains discovered via passive means (crt.sh, subfinder) before active ones.
  • [ ] IPs mapped and their service surface reviewed on Shodan/Censys.
  • [ ] Zone transfer tested only with authorization; leaks reported.
  • [ ] Zero connection to or exploitation of services without explicit permission.