Domain Reconnaissance: What Your DNS Records Reveal

Your Domain Tells a Story — Here Is What DNS Records Reveal

Before an attacker touches your systems, they read your domain. Everything published in DNS, in certificate logs, and in registration records tells a coherent story: public, permanent, and trivially fast to reconstruct. The tools cost nothing. The data never expires.

DNS records, SSL certificates, and WHOIS data sketch your complete attack surface in under 15 minutes using only free public tools. This is the perspective that attackers operate from by default and that most security teams have never applied to their own infrastructure. This post is the audit you should run today.

WHOIS Still Tells a Story Even With Privacy Proxies

Privacy proxies redact the registrant name but leave registrar, creation date, nameserver records, and update history exposed. That residual data is enough to fingerprint hosting migrations, infer infrastructure changes, and establish attack timing context.

ICANN formally transitioned gTLD domains from WHOIS to RDAP in January 2025, but most tools still query legacy WHOIS, and the data available differs by registrar. RDAP supports tiered access that redacts sensitive fields in public queries, yet nameserver records are never redacted under either protocol: ns1.digitalocean.com routes to DigitalOcean, ns-123.awsdns.com to Route53, dns1.p01.nsone.net to NS1/IBMDNS. The nameserver chain maps the hosting provider before any active probe begins.

The gap between creation date and last-updated date matters more than either value alone. A domain dormant for three years that was recently updated is a phishing signal: the temporal fingerprint of an infrastructure reactivation. Registrar identity fingerprints the organizational tier: NameCheap is budget consumer, CSC Global and MarkMonitor are enterprise-grade with legal lock features and escrow protections. An acquisition target using NameCheap for its primary domain while running enterprise cloud infrastructure is a governance gap, not just a reconnaissance signal.

DNS Records Are an Unintentional Org Chart

A, MX, and TXT records collectively reveal your email provider, CDN vendor, third-party SaaS integrations, and cloud footprint without any active scanning or authentication.

MX records fingerprint the email stack immediately: aspmx.l.google.com is Google Workspace, mail.protection.outlook.com is Microsoft 365, and a self-hosted MX record exposes the IP of the mail server directly. TXT records extend this further. Domain ownership verification tokens from Stripe, GitHub, Atlassian, and Google Search Console each map to an active vendor relationship. An attacker reading your TXT records has a working inventory of your SaaS subscriptions before sending a single packet to your network.

SPF records expose the full email routing graph. The include: chain cascades through every external provider authorized to send on your behalf:

"v=spf1 include:_spf.google.com include:sendgrid.net include:_spf.salesforce.com ~all"

That single TXT record identifies three external email pipelines in one query. The ip4: directives in SPF are worse still: they expose internal mail relay IP addresses directly in the public record, no network scanning required.

DKIM selector records complete the picture. Querying default._domainkey.example.com or google._domainkey.example.com returns the public key and reveals whether DKIM signing is configured at all. DMARC policy then determines the operational exposure: p=none is monitoring mode only and the domain is open to spoofing for phishing. A missing DMARC record eliminates even the audit trail. The rua= tag frequently leaks an internal reporting email address that does not appear anywhere else in the organization's public footprint.

Certificate Transparency Is a Permanent Subdomain Ledger You Cannot Opt Out Of

Every TLS certificate ever issued for your domain is in public append-only logs forever — including staging servers, internal APIs, and decommissioned services you assumed were private because they had no DNS record.

RFC 9162 (Certificate Transparency v2.0, December 2021) mandates CT logging for all publicly-trusted CAs. Certificates cannot be removed once submitted to a CT log. This is by design: the append-only Merkle Tree structure is what makes the system auditable. The side effect is that every certificate you have ever issued is permanently discoverable by anyone with an internet connection.

The subdomain exposure is significant. CT log history typically contains 10 to 100 times more subdomains than currently active DNS records. A single crt.sh query returns the complete historical certificate record including Subject Alternative Names, issuance dates, and CA identity:

curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value' | sort -u

Certificates for internal services given HTTPS for compliance purposes (staging.internal.example.com, api-dev.example.com) appear in CT logs even with no public DNS entry and no external routing. They reveal the naming conventions your organization uses for internal infrastructure, which feeds subdomain brute force wordlists for active enumeration.

The orphaned subdomain pattern is the highest-value finding from CT log analysis. A CNAME like cdn.example.com CNAME old-bucket.s3.amazonaws.com becomes a takeover vector once the S3 bucket is deprovisioned. The CT logs prove the hostname existed, the CNAME still resolves, and an attacker who registers the matching bucket name controls traffic destined for your subdomain. Bug bounty programs consistently rank dangling CNAME findings among the highest-volume critical reports precisely because the evidence trail runs through public CT logs.

Misconfigurations Signal That Infrastructure Is Not Actively Audited

Missing DMARC policies, permissive SPF, zone transfer on secondary nameservers, and dangling CNAME records are not isolated bugs. They co-occur in organizations where DNS is treated as set-and-forget configuration.

Zone transfer is the highest-value misconfiguration when present. A permissive AXFR response from a secondary nameserver dumps every record in the zone:

dig @ns2.example.com example.com AXFR

This should fail on any hardened server. When it succeeds, it returns A, CNAME, MX, TXT, and PTR records that would otherwise require days of brute-force enumeration to reconstruct. Wildcard SPF with the +all qualifier authorizes the entire internet to send email as your domain. An SPF record ending in +all rather than ~all or -all is a live phishing enabler.

An MX record pointing to a hostname that resolves to 0.0.0.0 or a no-reply address signals orphaned mail routing from an acquisition or migration. Delegated NS records on subdomains (NS records at dev.example.com pointing to a different provider) reveal shadow IT setups where engineering teams created independent DNS zones outside central control. Multiple A records for the same hostname across different IP ranges reveal canary deployments or multi-region setups without load balancer abstraction.

None of these individually constitute a critical vulnerability. Together, they tell a consistent story: the DNS configuration has not been audited since it was provisioned.

Run the Attacker Recon Sequence Against Your Own Domain

The passive recon sequence that takes an attacker 15 minutes is the same audit you should run quarterly. None of it requires specialist tooling — dig, curl, and crt.sh cover the full sequence.

# Step 1: Registrar, nameservers, creation and update dates
whois example.com

# Step 2: Core record types
# (some resolvers restrict ANY queries; use targeted queries as fallback)
dig example.com ANY +short
dig example.com MX +short
dig example.com TXT +short

# Step 3: Complete subdomain history from CT logs
curl "https://crt.sh/?q=%.example.com&output=json" | jq '.[].name_value' | sort -u

# Step 4: Zone transfer test (should fail on hardened nameservers)
dig @ns1.example.com example.com AXFR
dig @ns2.example.com example.com AXFR

# Step 5: Email security posture
dig _dmarc.example.com TXT
# p=none: monitoring only, domain is spoofable
# no record: worse than p=none

Review each result against what you expect. Unexpected subdomains in CT logs require immediate follow-up: check whether the CNAME target still exists, and if the cloud resource has been deprovisioned, delete the DNS record or reclaim the resource before someone else does. Every include: in your SPF record is a third party with email sending authority you may not have reviewed recently. Every TXT verification token is an active vendor relationship that should appear in your asset inventory.

The recon view of your domain is public regardless of whether you look at it. The question is whether you understand what it says before someone else acts on it. Running this sequence quarterly, especially after infrastructure changes, vendor additions, or domain acquisitions, is the lowest-cost audit in security.