DEV Community

Cover image for Domain Scanner: Understanding Domain Intelligence & Reconnaissance
toolbox-poster
toolbox-poster

Posted on • Originally published at toolbox.starnomina.tn

Domain Scanner: Understanding Domain Intelligence & Reconnaissance

#webdev #tutorial #security #cybersecurity

TL;DR
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.

📑 Table of Contents

  • 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 policy
Enter fullscreen mode Exit fullscreen mode

What 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 subjectAltName
Enter fullscreen mode Exit fullscreen mode

Key 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
Enter fullscreen mode Exit fullscreen mode

⚠️ 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

⚡ Pro Tip: 💡 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 -www reveals 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

⚡ Pro Tip: 💡 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

🎯 Key Takeaway: 🎯 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.

Originally published on StarNomina ToolBox. Try our free online tools — no signup required.

Top comments (0)