A domain scanner aggregates publicly available intelligence — DNS records, WHOIS data, SSL certificates, HTTP headers, and technology fingerprints — into a comprehensive profile of any domain. Used defensively, it reveals your own attack surface before adversaries find it. This guide covers what domain reconnaissance uncovers, how each technique works, and the ethical framework for responsible scanning.
- What Is Domain Reconnaissance?
- What OSINT Reveals
- DNS Enumeration
- WHOIS Intelligence
- SSL Certificate Analysis
- Certificate Transparency
- Technology Detection
- Security Posture Assessment
- Subdomain Enumeration
- Attack Surface Mapping
- Ethical & Legal Considerations
- Best Practices
- Common Mistakes
- Tools
- References
What Is Domain Reconnaissance?
📖 Definition — Domain reconnaissance (or domain intelligence) is the systematic collection and analysis of publicly available information about a domain to understand its infrastructure, technology stack, and security posture — without sending exploitation payloads or intrusive probes.
This is passive reconnaissance — gathering intelligence that the domain itself makes publicly available through DNS, WHOIS, SSL, HTTP headers, and public databases. It's the first step in any security assessment and a critical practice for defenders who want to understand what adversaries can learn about their organization.
What OSINT Reveals
A comprehensive domain scan aggregates multiple data sources into a unified intelligence profile:
| Data Source | What It Reveals | Risk Level |
|---|---|---|
| DNS Records (A, MX, NS, TXT) | IP addresses, mail providers, nameservers, SPF/DKIM/DMARC config | Medium |
| WHOIS | Registrar, registration dates, registrant info (if not redacted), nameservers | Low |
| SSL/TLS Certificates | Certificate authority, validity period, SANs (alt domains), organization name | Medium |
| Certificate Transparency Logs | All certificates ever issued for the domain — reveals subdomains | High |
| HTTP Headers | Server software, framework versions, security headers, caching behavior | Medium |
| Technology Fingerprinting | CMS, JavaScript frameworks, analytics, CDN, hosting provider | Medium |
| Subdomain Enumeration | Internal services, dev/staging environments, forgotten infrastructure | High |
DNS Enumeration
DNS is the foundation of domain intelligence. A complete DNS enumeration queries all relevant record types to map the domain's infrastructure:
# Full DNS enumeration
dig example.com A +short # Web server IPs
dig example.com AAAA +short # IPv6 addresses
dig example.com MX +short # Mail servers
dig example.com NS +short # Authoritative nameservers
dig example.com TXT +short # SPF, DKIM selectors, verification records
dig example.com SOA +short # Zone authority and serial
dig example.com CNAME +short # Aliases (CDN indicators)
dig _dmarc.example.com TXT +short # DMARC policyWhat DNS Records Reveal
- MX records → Email provider (Google Workspace, Microsoft 365, Proton Mail, self-hosted)
- NS records → DNS hosting (Cloudflare, AWS Route 53, registrar defaults)
- TXT records → Third-party service verifications (Google, Facebook, Atlassian), SPF authorized senders
- CNAME records → CDN usage, SaaS integrations, subdomain delegation
- A records → Hosting provider (via IP-to-ASN mapping), whether behind a CDN/proxy
WHOIS Intelligence
WHOIS provides domain registration metadata. While GDPR WHOIS redaction (post-2018) has reduced the personal information available, significant intelligence remains:
- Registration and expiration dates — Recently registered domains are suspicious; nearing-expiration domains may be neglected
- Registrar — Certain registrars are favored by specific threat actor groups
- Nameserver history — Changes correlate with hosting migrations or domain takeover
- Registrant organization — When not redacted, reveals the owning entity
ℹ️ Even with GDPR redaction, the registrar's abuse contact remains visible. Historical WHOIS records (via services like DomainTools or SecurityTrails) often contain pre-redaction registrant details.
SSL Certificate Analysis
An SSL/TLS certificate contains rich metadata about a domain's identity and infrastructure:
# Inspect a site's certificate
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -text
# Quick: subject, issuer, dates, SANs
echo | openssl s_client -connect example.com:443 -servername example.com 2>/dev/null | openssl x509 -noout -subject -issuer -dates -ext subjectAltNameKey Intelligence from Certificates
- Subject Alternative Names (SANs) — Lists all domains the certificate covers, revealing related domains and subdomains
- Certificate Authority — Let's Encrypt suggests automated issuance; extended validation (EV) certs reveal the legal entity
- Validity period — Short-lived certs (90 days) indicate automated renewal; long-lived certs may indicate enterprise infrastructure
- Key size and algorithm — Weak keys (RSA <2048-bit) or outdated algorithms indicate poor security practices
Certificate Transparency
📖 Definition — Certificate Transparency (CT) is a public logging framework (RFC 6962) that requires Certificate Authorities to log each issued certificate to publicly auditable append-only logs. This creates a searchable record of every certificate issued for any domain.
CT logs are a powerful subdomain enumeration source because they capture certificates for internal and staging subdomains that the organization may not intend to be publicly visible.
# Search CT logs via crt.sh
curl -s "https://crt.sh/?q=%.example.com&output=json" | jq -r '.[].name_value' | sort -u⚠️ CT logs are permanent and public. If you issue a certificate for internal-admin.example.com, that hostname is now visible to anyone searching CT logs — even if it's not publicly resolvable.
Technology Detection
Technology fingerprinting identifies the software stack behind a domain by analyzing HTTP headers, HTML content, JavaScript libraries, and other observable signals:
| Signal | Technology Revealed | Example |
|---|---|---|
Server header | Web server | nginx/1.24.0, Apache/2.4.57 |
X-Powered-By header | Application framework | Express, PHP/8.2, Next.js |
| HTML meta tags / generators | CMS | WordPress 6.4, Drupal |
| JavaScript file paths | Frontend frameworks | _next/static, wp-includes |
| Cookie names | Platform | PHPSESSID, ARRAffinity (Azure) |
X-Cache / CF-Ray | CDN | Cloudflare, Varnish, Fastly |
💡 Defensive tip: Remove or generalize version-revealing headers in production. In nginx: server_tokens off;. In Express: app.disable('x-powered-by');. Obscurity isn't security, but it eliminates low-hanging enumeration fruit.
Security Posture Assessment
Scanning a domain's security configuration reveals how well it's hardened against common attacks:
HTTP Security Headers
| Header | Purpose | Missing = Risk |
|---|---|---|
Strict-Transport-Security | Enforce HTTPS | Downgrade / MITM attacks |
Content-Security-Policy | Prevent XSS / injection | Cross-site scripting |
X-Content-Type-Options | Prevent MIME sniffing | Content type confusion |
X-Frame-Options | Prevent clickjacking | UI redress attacks |
Permissions-Policy | Control browser features | Camera/mic/geolocation abuse |
Email Security Records
- SPF — Defines authorized mail senders (TXT record)
- DKIM — Cryptographic signature on outbound mail
- DMARC — Policy for SPF/DKIM failures with reporting
- MTA-STS — Enforces TLS for inbound mail delivery
Subdomain Enumeration
Subdomains often expose forgotten, unpatched, or internal services. Enumeration techniques range from passive to semi-active:
- Certificate Transparency — Search crt.sh for all issued certificates (passive)
- DNS zone transfer — Request AXFR from nameservers (usually blocked, but worth testing:
dig axfr example.com @ns1.example.com) - Search engine dorking —
site:example.com -wwwreveals indexed subdomains - Public datasets — SecurityTrails, VirusTotal, Shodan maintain historical subdomain data
- DNS brute-forcing — Dictionary-based resolution of common subdomain names (active; request permission)
🚨 Active subdomain brute-forcing generates thousands of DNS queries and may trigger rate limiting or security alerts. Always obtain written authorization before scanning domains you don't own.
Attack Surface Mapping
Combining all reconnaissance data produces an attack surface map — a comprehensive inventory of an organization's externally visible assets and their security posture:
1. Asset Discovery — Enumerate all domains, subdomains, IPs, and services associated with the organization.
2. Service Identification — Map open ports, running services, and application versions on each asset.
3. Configuration Analysis — Check security headers, TLS configuration, DNS security, and authentication mechanisms.
4. Vulnerability Correlation — Match identified software versions against CVE databases for known vulnerabilities.
5. Risk Prioritization — Rank findings by severity and exploitability. Focus on internet-facing, unpatched, or misconfigured assets first.
Defensive teams should perform this exercise quarterly and after any significant infrastructure change (new services, migrations, acquisitions).
Ethical & Legal Considerations
⚠️ Reconnaissance legality varies by jurisdiction. Passive information gathering (DNS, WHOIS, CT logs) is generally legal. Active scanning (port scanning, brute-forcing) may violate computer fraud laws if performed without authorization.
- Own assets only — Scan your own domains freely. For third parties, get explicit written permission.
- Passive first — CT logs, WHOIS, DNS, and HTTP header analysis are non-intrusive and publicly available.
- Bug bounty scope — If a domain has a bug bounty program, stay within the defined scope and rules of engagement.
- No exploitation — Reconnaissance is about discovery, not exploitation. Never attempt to access or modify systems you discover.
- Responsible disclosure — If you find a vulnerability on someone else's domain, report it through their security contact or bug bounty program.
Best Practices
💡 Run a domain scan against your own organization monthly. Treat it as a self-assessment — if you find something surprising (an unknown subdomain, a missing security header, an exposed staging server), your adversaries have already found it too.
- Scan your own domains regularly and before launches to catch misconfigurations early
- Remove or restrict version-revealing headers and unnecessary DNS TXT records
- Use wildcard certificates or private CAs for internal subdomains to limit CT log exposure
- Enable WHOIS privacy to reduce personal information leakage
- Implement all HTTP security headers (HSTS, CSP, X-Content-Type-Options, X-Frame-Options)
- Configure SPF, DKIM, and DMARC on all domains — including domains that don't send email (use
v=spf1 -all) - Decommission unused subdomains to prevent subdomain takeover vulnerabilities
- Monitor Certificate Transparency logs for unauthorized certificate issuance (services like CertSpotter)
Common Mistakes
| Mistake | Consequence | Fix |
|---|---|---|
| Leaving staging/dev subdomains publicly resolvable | Exposes unprotected services | Use private DNS or VPN-only access for internal services |
| Exposing server versions in HTTP headers | Attackers target known CVEs for that version | Disable version disclosure in server config |
| Issuing public certs for internal hostnames | Subdomains visible in CT logs forever | Use private CA or wildcard certs for internal names |
| No DMARC on parked/non-mail domains | Domain can be spoofed for phishing | Add v=DMARC1; p=reject; and v=spf1 -all |
| Forgetting to remove DNS records after decommissioning | Dangling CNAME → subdomain takeover | Audit DNS records quarterly; remove stale entries |
| Assuming WHOIS privacy hides everything | Historical records, NS, and registrar still visible | Understand what privacy does and doesn't protect |
Tools
🔍 Domain Scanner — Comprehensive domain intelligence: DNS, WHOIS, SSL, headers, and technology detection in one scan.
🌐 DNS Lookup — Query all DNS record types from multiple global resolvers.
🔒 SSL Checker — Analyze certificate details, chain validity, expiration, and TLS configuration.
🛡️ Security Scanner — Audit HTTP security headers and common web security misconfigurations.
📍 Website to IP — Resolve domains to IP addresses with geolocation and hosting provider details.
References
- 📄 OWASP Testing Guide — Information Gathering
- 📄 NIST SP 800-115 — Technical Guide to Information Security Testing and Assessment
- 📄 RFC 6962 — Certificate Transparency
- 📄 Certificate Transparency — Official Project Site
- 📄 ICANN — WHOIS Resources & RDAP Transition
- 📄 OWASP — HTTP Security Headers Cheat Sheet
🚀 Free ToolZilla tools used in this article
All client-side, no signup, no upload — open them in a new tab while you read:
- 🔧 Domain Scanner — try it free in your browser.
- 🔧 DNS Lookup — try it free in your browser.
- 🔧 SSL / TLS Checker — try it free in your browser.
- 🔧 Security Scanner — try it free in your browser.
- 🔧 Website to IP — try it free in your browser.
- 🧰 Browse all 60+ free tools →
🎯 Key Takeaway — Domain scanning reveals everything an organization makes publicly visible: infrastructure, technology, security configuration, and forgotten assets. Run it against your own domains to discover your attack surface before adversaries do. Pair regular self-assessment with proactive hardening — remove version headers, decommission stale subdomains, enforce security headers, and monitor CT logs for unauthorized certificate issuance.