A 142.250.80.46 AAAA 2606:4700::6810 MX 10 mail.acmecorp.com NS ns1.cloudflare.com TXT v=spf1 include:_spf CNAME www → cdn.cloudflare.net SOA ns1.dns.provider.net PTR 46.80.250.142.in-addr.arpa SRV _sip._tcp 10 60 5060 CAA 0 issue "letsencrypt.org"

MITRE ATT&CK · T1596.001

DNS / Passive DNS
Reconnaissance

How adversaries search DNS data and passive DNS repositories to silently map an organization's infrastructure, subdomains, and services before launching targeted attacks.

Tactic: Reconnaissance (TA0043) Sub-technique of T1596 Platform: PRE Severity: High

CSS-Only Simulation

DNS Query & Passive DNS Resolution Flow

When an adversary queries a domain name, DNS resolution traverses a global hierarchy of nameservers. This animation shows how a single DNS query travels from a client through recursive resolvers to authoritative nameservers, revealing infrastructure details at each hop. Passive DNS databases store historical snapshots of these queries, enabling attackers to reconstruct an organization's entire DNS footprint without ever touching their servers directly.

DNS Query Initiated

$ d i g A N Y a c m e c o r p . c o m

💻 Attacker DNS Client

➞

🔄 Recursive Resolver (ISP)

➞

🌎 Root Server a.root-servers.net

➞

📍 TLD Server .com NS

➞

🖥 Authoritative NS1.acmecorp.com

QUERY RESPONSE

DNS Record Types Discovered

Each DNS record type exposes different layers of an organization's infrastructure. Attackers systematically query all record types to build a comprehensive attack surface map , from web servers and mail gateways to cloud providers and authentication services.

A142.250.80.46

AAAA2606:4700::6810

MX10 mail.acmecorp.com

NSns1.cloudflare.com

TXTv=spf1 include:_spf.google.com

CNAMEcdn.cloudflare.net

A MX NS TXT AAAA CNAME SOA PTR

Subdomain Discovery Cascade

Using wordlists, permutation engines, and certificate transparency logs, adversaries discover subdomains that organizations may have forgotten exist. Each resolved subdomain represents a potential attack vector , from forgotten staging environments to internal tools accidentally exposed to the internet.

[FOUND] www.acmecorp.com → 142.250.80.46

[FOUND] mail.acmecorp.com → 203.0.113.10

[FOUND] vpn.acmecorp.com → 203.0.113.20

[NEW] api-staging.acmecorp.com → 203.0.113.55

[HIDDEN] internal-admin.acmecorp.com → 10.0.1.50

[NEW] dev-db.acmecorp.com → 203.0.113.70

[HIDDEN] jira.acmecorp.com → 203.0.113.80

[NEW] gitlab-ci.acmecorp.com → 203.0.113.90

Passive DNS Historical Timeline

Passive DNS repositories like Farsight DNSDB, VirusTotal, and SecurityTrails capture and store DNS query/response data over time. This enables adversaries (and defenders) to see historical DNS records, including subdomains that have since been removed, IP address changes, and infrastructure shifts , all without generating any direct queries to the target's DNS servers.

Jan 2022, First Observation

A record: acmecorp.com → 198.51.100.5

Original web server on shared hosting

Source: Farsight DNSDB

Jun 2022, Infrastructure Migration

A record: acmecorp.com → 142.250.80.46

Migrated to cloud provider (Google Cloud)

Source: VirusTotal Passive DNS

Mar 2023, Subdomain Expansion

New: api.acmecorp.com, staging.acmecorp.com, dev.acmecorp.com

3 new subdomains discovered , potential development environments

Source: SecurityTrails

Nov 2023, Mail Server Change

MX record: 10 mail.acmecorp.com (was: ASPMX.L.GOOGLE.COM)

Switched from Google Workspace to self-hosted mail

Source: PassiveTotal

Apr 2024, CDN Adoption

CNAME: www.acmecorp.com → acmecorp.cdn.cloudflare.net

Now behind Cloudflare CDN , WAF potentially active

Source: DNSDB

Sep 2024, Suspicious Addition

New: test-admin.acmecorp.com → 203.0.113.150

Unknown test subdomain pointing to non-standard IP range

Source: VirusTotal

IP Address Mapping

DNS resolution maps domain names to IP addresses, revealing the physical hosting infrastructure. When multiple domains resolve to the same IP, it indicates shared hosting or related services , a technique called "reverse IP lookup" that expands the attacker's view of the target's footprint.

acmecorp.com

142.250.80.46

api.acmecorp.com

142.250.80.47

mail.acmecorp.com

203.0.113.10

vpn.acmecorp.com

203.0.113.20

Reverse DNS Lookup

Reverse DNS (PTR records) maps IP addresses back to domain names. Adversaries use this to discover all domains hosted on the same server, identify shared infrastructure, and uncover previously unknown assets that share an IP with the target organization.

↻ Reverse DNS Lookup Results

142.250.80.46→acmecorp.com

142.250.80.47→api.acmecorp.com

203.0.113.10→mail.acmecorp.com, smtp.acmecorp.com, imap.acmecorp.com

203.0.113.20→vpn.acmecorp.com

203.0.113.55→staging.acmecorp.com, test.acmecorp.com, backup.acmecorp.com

203.0.113.90→gitlab-ci.acmecorp.com

Network Path Tracing

Traceroute and DNS path analysis reveal the network infrastructure between the attacker and the target. Each hop exposes intermediate routers, network segments, and potentially the hosting provider's infrastructure topology.

💻

Attacker

192.168.1.50

🔄

ISP Gateway

10.0.0.1

🌐

IXP Peering

198.32.0.0

☁️

Cloud Edge

142.250.1.1

🖥

Target Server

142.250.80.46

Impact Analysis

Why DNS/Passive DNS Reconnaissance Matters

DNS is one of the oldest and most fundamental protocols on the internet , and one of the most frequently abused for reconnaissance. Because DNS records are inherently public and designed for universal accessibility, they provide adversaries with a treasure trove of information about an organization's infrastructure, often without generating any suspicious log entries on the target's systems.

30%+

of 2024 cyber incidents involved DNS abuse as an initial reconnaissance vector

Source: OpenProvider Cybersecurity Report 2025

87%

of organizations have at least one publicly resolvable subdomain they are unaware of

Source: SecurityTrails DNS Research Study

5,900+

BIND9 DNS servers affected by CVE-2025-40778 critical vulnerability in 2025

Source: NIST NVD / CISA KEV

31.4 Tbps

record-breaking DDoS attack powered by DNS amplification technique in 2024

Source: Cloudflare DDoS Threat Report

72%

of attacks occur outside working hours when DNS monitoring is reduced

Source: Semperis Active Directory Report

$4.44M

average cost of a data breach where DNS reconnaissance preceded the initial access

Source: IBM Cost of a Data Breach Report

DNS reconnaissance is uniquely dangerous because it is passive, non-intrusive, and virtually untraceable. Unlike port scanning or vulnerability probing, DNS queries are normal internet traffic that blends seamlessly with legitimate requests. An attacker querying your organization's DNS records from a coffee shop WiFi looks identical to any other user resolving your website. Passive DNS databases compound this problem by maintaining years of historical records , meaning even subdomains you deleted years ago may still be visible to anyone who knows where to look.

The consequences are severe: exposed staging servers with default credentials, forgotten development APIs still accepting traffic, mail servers revealing internal hostnames through SPF and DKIM records, and VPN endpoints that provide direct network access. Organizations routinely discover dozens of "zombie" subdomains that nobody internally remembers creating, each representing a potential entry point for an attacker.

Authoritative Resources

Glossary

Key Terms & Concepts

Understanding DNS and passive DNS requires familiarity with several core concepts. Each term below is paired with a simple analogy to make the technical details accessible, regardless of your background.

DNS (Domain Name System)

The hierarchical, distributed naming system that translates human-readable domain names (like acmecorp.com) into machine-routable IP addresses (like 142.250.80.46). DNS operates as a global database of name-to-address mappings, organized into zones managed by authoritative nameservers.

💡 DNS is like the internet's phone book, instead of remembering your friend's phone number (IP address), you look up their name (domain name) and the phone book tells you how to reach them.

Passive DNS

Centralized repositories that store historical DNS query/response data collected from recursive resolvers worldwide. Unlike active DNS queries (which go directly to the target's nameserver), passive DNS provides historical records without generating any traffic to the target organization.

💡 Passive DNS is like having a library of old phone books going back years, even if someone changed their number or moved, you can still find their old listing and trace their history.

DNS Record Types

Different types of DNS entries that serve different purposes: A/AAAA records map to IP addresses, MX records point to mail servers, NS records identify nameservers, TXT records store text data (SPF, DKIM, DMARC), CNAME records create aliases, and PTR records enable reverse lookups.

💡 DNS record types are like different sections in a business directory, the street address (A record), the mail room (MX record), the reception desk (NS record), and special notes (TXT record).

DNS Pivoting

The technique of using discovered DNS records as starting points to find additional infrastructure. By following CNAME chains, reverse IP lookups, and shared nameservers, attackers systematically expand their map of the target's infrastructure beyond what is immediately visible.

💡 DNS pivoting is like following a trail of breadcrumbs, you find one clue (a domain name), which leads to another (an IP address), which leads to more domains on the same server, revealing a whole network you didn't know existed.

Reverse DNS Lookup (PTR)

The process of querying an IP address to find the associated domain name. This is the opposite of standard DNS resolution and is used to discover all domain names hosted on a single IP address, revealing shared hosting relationships and related assets.

💡 Reverse DNS is like looking up a phone number to find out whose name it's listed under, you might discover that the same phone number is used by multiple businesses at the same address.

DNS Zone Transfer (AXFR)

A mechanism for replicating DNS zone data between nameservers. If misconfigured, zone transfers allow anyone to download the complete DNS configuration of a domain, every subdomain, record, and timestamp, in a single request.

💡 A zone transfer is like accidentally leaving the master copy of your entire address book in a public place, instead of looking up one name at a time, someone walks away with the whole book.

Subdomain Enumeration

The systematic discovery of subdomains belonging to a target domain using wordlists, brute-force techniques, certificate transparency logs, search engines, and passive DNS databases. Each discovered subdomain represents a potential attack surface.

💡 Subdomain enumeration is like searching every extension at a company's address, you check "Suite 100," "Mail Room," "Server Closet," "Testing Lab", finding doors you never knew existed.

DNS Amplification

An attack technique that exploits open DNS resolvers to flood a target with amplified traffic. Attackers send small queries with the victim's spoofed IP address to open resolvers, which return large responses to the victim, creating a devastating DDoS attack.

💡 DNS amplification is like asking 1,000 people to send you a catalog, but putting someone else's return address on the request, they get buried under an avalanche of mail they never asked for.

Case Study

Real-World Scenario: The Forgotten Subdomains

Lisa Park

Senior DNS Administrator

Meridian Financial Group, 12,000 employees, $8.7B assets under management

Lisa Park had been Meridian Financial Group's DNS administrator for six years. She managed a clean, well-organized DNS zone with about 15 subdomains, the corporate website, email gateway, VPN portal, customer portal, and a handful of internal tools. Her DNS records were properly configured, her SPF and DKIM records were correct, and she felt confident about her organization's DNS security posture. Then, during a routine third-party security assessment, everything changed.

⚠️ Before: The Hidden Reality

Lisa believed Meridian had 15 subdomains. The security assessment revealed they actually had 147 publicly resolvable subdomains, ten times what she knew about. Many were legacy systems from mergers and acquisitions over the past decade.

staging-old.meridianfg.com, A decommissioned staging server from a 2019 acquisition, still running Apache 2.4.29 with known CVEs
test-ldap.meridianfg.com, A forgotten LDAP testing endpoint exposing directory service queries to the internet
backup-db.meridianfg.com, An old backup database server with default credentials, containing 3 years of customer records
hr-internal.meridianfg.com, An HR self-service portal from a 2020 merger, still accessible without MFA
api-v1-legacy.meridianfg.com, A deprecated API endpoint processing live transactions without rate limiting

✓ After: Full DNS Visibility

After the wake-up call, Lisa implemented a comprehensive DNS monitoring and management program that gave Meridian complete visibility into their DNS footprint.

Deployed automated subdomain discovery using passive DNS monitoring, alerting on any new subdomain within 24 hours
Conducted a full audit of all 147 discovered subdomains, decommissioning 89 that were no longer needed
Implemented DNS zone transfer restrictions to prevent AXFR enumeration on all nameservers
Added cloud-native DNS security tools to monitor for unauthorized DNS record changes in real-time
Established quarterly DNS hygiene reviews as part of the organization's security operations routine

The assessment also revealed that passive DNS databases like SecurityTrails and VirusTotal still contained records for subdomains Lisa had removed years earlier. An attacker using passive DNS could have discovered infrastructure details that no longer existed in Meridian's active DNS zone, including internal IP ranges and server hostnames that provided valuable intelligence for social engineering attacks. This highlighted a critical truth: removing a DNS record does not erase it from history.

The total cost of the remediation project was $340,000, but the potential cost of a breach through one of those forgotten subdomains was estimated at $4.8 million based on Meridian's industry and data profile. Lisa now considers DNS visibility one of the most important aspects of her organization's security posture, and she regularly uses passive DNS tools herself to monitor what the world can see about Meridian's infrastructure.

Actionable Guide

How to Defend Against DNS/Passive DNS Reconnaissance

Follow these seven steps to reduce your organization's exposure to DNS-based reconnaissance. Each step includes specific action items, protection keywords, and links to related techniques for deeper understanding.

Step 1 of 7

Audit Your Complete DNS Footprint

Before you can protect your DNS infrastructure, you need to know exactly what exists. Most organizations discover significantly more subdomains and records than they expect when they conduct a thorough audit.

Use passive DNS databases (SecurityTrails, VirusTotal, DNSDB) to see what historical records exist for your domains
Run subdomain enumeration tools against your own domains to discover what an attacker would find
Compare your internal DNS zone files against what is publicly resolvable, any differences indicate either intentional external services or accidental exposure

DISCOVER AUDIT

Step 2 of 7

Decommission Unused Subdomains and Records

Zombie subdomains, forgotten DNS entries pointing to decommissioned or abandoned servers, are one of the most common findings in security assessments. Each one is a potential entry point.

Create an inventory of all discovered subdomains and categorize them as active, deprecated, or unknown
Contact former employees, acquired companies, and department heads to verify the purpose of unknown subdomains
Remove DNS records for any subdomain that no longer serves a legitimate business purpose

CLEANUP HYGIENE

Related: T1590.005 IP Addresses

Step 3 of 7

Restrict DNS Zone Transfers

DNS zone transfers (AXFR) allow secondary nameservers to replicate zone data. If unrestricted, anyone can download your entire DNS configuration, every subdomain, record, and timestamp, in a single request.

Configure ACLs on all authoritative nameservers to allow zone transfers only to designated secondary nameservers
Verify zone transfer restrictions by attempting an AXFR query from an external IP address
Use TSIG (Transaction SIGnature) authentication to cryptographically sign zone transfer requests

PREVENT HARDEN

Related: T1590.002 DNS

Step 4 of 7

Implement DNS Monitoring and Alerting

Real-time monitoring of DNS changes enables rapid detection of unauthorized modifications. Attackers who compromise your DNS provider or registrar account can redirect traffic without breaching your network.

Deploy DNS change monitoring that alerts on any new, modified, or deleted DNS records within minutes
Monitor passive DNS databases for new subdomains appearing under your domain, which may indicate compromise or misconfiguration
Integrate DNS alerts into your SIEM and incident response workflows for automated escalation

DETECT MONITOR

Step 5 of 7

Secure DNS Configuration with DNSSEC

DNSSEC (DNS Security Extensions) adds cryptographic signatures to DNS records, ensuring that responses are authentic and have not been tampered with. This prevents cache poisoning and man-in-the-middle attacks on DNS.

Enable DNSSEC on all authoritative zones and ensure DS records are properly published in the parent zone
Implement NSEC or NSEC3 to prevent zone enumeration through walking techniques
Regularly validate DNSSEC chains using tools like dnsviz.net to detect misconfigurations

PREVENT AUTHENTICATE

Step 6 of 7

Minimize Information Disclosure in DNS Records

DNS records often contain more information than necessary. TXT records, SOA records, and NS records can leak internal hostnames, email addresses, server versions, and organizational structure.

Review all TXT records for unnecessary information, remove internal verification tokens and debugging entries from production zones
Use generic contact addresses in SOA records (e.g., [email protected]) rather than personal email addresses
Ensure SPF, DKIM, and DMARC records are properly configured but do not leak internal mail server hostnames unnecessarily

MINIMIZE HARDEN

Step 7 of 7

Establish Ongoing DNS Hygiene Practices

DNS security is not a one-time project, it requires continuous attention. As organizations grow, acquire companies, and deploy new services, DNS complexity increases and forgotten entries accumulate.

Schedule quarterly DNS hygiene reviews to audit all records, decommission unused entries, and verify access controls
Implement a DNS change management process requiring approval and documentation for any new DNS record creation
Conduct annual third-party DNS assessments to catch issues that internal teams may overlook

MAINTAIN GOVERN

Pitfalls

Common Mistakes & Best Practices

DNS security failures often stem from simple oversights rather than sophisticated attacks. Here are the most common mistakes organizations make and the best practices that effectively prevent them.

❌ Common Mistakes

🚫

Allowing Unrestricted Zone Transfers

Leaving AXFR queries open to any IP address lets attackers download your entire DNS configuration in one request, revealing every subdomain, record type, timestamp, and administrative contact. This single misconfiguration can expose your entire infrastructure map.

Fix: Configure ACLs to restrict zone transfers to specific IP addresses only. Use TSIG authentication for cryptographic verification of transfer requests.

🚫

Ignoring Zombie Subdomains from Mergers

After mergers and acquisitions, DNS zones from acquired companies are often merged without thorough review. Legacy subdomains from years-old acquisitions continue resolving, exposing forgotten services, default credentials, and outdated software to the internet.

Fix: Conduct comprehensive subdomain audits after every acquisition. Use passive DNS to discover historical records from the acquired company's domains.

🚫

Leaking Internal Hostnames in Public Records

SOA records, NS records, MX records, and TXT records frequently contain internal server hostnames that reveal network topology, server naming conventions, and organizational structure to anyone performing basic DNS queries.

Fix: Review all DNS records for unnecessary information. Use external-facing hostnames that differ from internal names. Remove debugging TXT records from production zones.

🚫

No DNS Change Monitoring

Most organizations cannot detect unauthorized DNS changes in real-time. An attacker who compromises a DNS registrar or hosting account can silently redirect traffic, intercept emails, or create phishing subdomains without triggering any alerts.

Fix: Deploy DNS change monitoring with immediate alerting. Integrate passive DNS monitoring to detect new subdomains appearing under your domain.

🚫

Not Monitoring Passive DNS Databases

Organizations focus on their active DNS zones but ignore what passive DNS databases reveal about their history. Old records, removed subdomains, and historical IP addresses remain visible to anyone with access to these databases for years.

Fix: Regularly query passive DNS databases (SecurityTrails, VirusTotal, DNSDB) for your own domains to understand what information remains visible about your infrastructure history.

✅ Best Practices

🔒

Implement DNSSEC on All Authoritative Zones

DNSSEC adds cryptographic integrity to DNS responses, preventing cache poisoning and ensuring that responses are authentic. Enable DNSSEC with NSEC3 to prevent zone walking while still providing authenticated denial of existence.

🔎

Conduct Regular DNS Attack Surface Assessments

Quarterly assessments using the same tools attackers use (subdomain enumeration, reverse DNS, certificate transparency, passive DNS) give you the attacker's perspective of your organization and reveal issues before adversaries find them.

📊

Maintain a Comprehensive DNS Inventory

Keep a documented inventory of all DNS records, subdomains, and their business owners. This inventory should be reconciled against actual DNS resolution regularly to catch drift between documentation and reality.

🛠️

Use DNS Monitoring Services with Passive DNS Tracking

Deploy commercial DNS monitoring services that combine active monitoring with passive DNS intelligence. These services alert you to new subdomains, DNS record changes, and infrastructure modifications within minutes.

🎯

Apply Least Privilege to DNS Management Access

Restrict DNS registrar and nameserver access to authorized personnel only. Enable multi-factor authentication, maintain audit logs of all DNS changes, and implement change approval workflows to prevent unauthorized modifications.

Tactical Analysis

Red Team vs. Blue Team Perspectives

Understanding how both attackers and defenders approach DNS reconnaissance reveals the true nature of this technique. Red teams leverage DNS as a silent intelligence-gathering tool, while blue teams must detect and limit information disclosure without breaking legitimate DNS functionality.

🔴 Red Team: Attack Perspective

Objective: Silently map the target's complete DNS infrastructure to identify attack surfaces, pivot points, and potential entry vectors without generating detectable activity.

Initial Reconnaissance: Query public DNS records (A, AAAA, MX, NS, TXT, CNAME, SOA) using dig, nslookup, and host to build a baseline of the target's infrastructure
Subdomain Discovery: Use wordlists, permutations, and certificate transparency logs via subfinder, amass, assetfinder to discover hidden subdomains
Passive DNS Mining: Query Farsight DNSDB, VirusTotal, SecurityTrails, and PassiveTotal for historical records, finding deleted subdomains, old IP addresses, and infrastructure changes
DNS Pivoting: Follow CNAME chains, reverse IP lookups, and shared nameserver relationships to discover additional domains and services beyond the primary target
Zone Transfer Attempt: Try AXFR queries against all discovered nameservers to potentially download the complete zone file in a single request
Intelligence Compilation: Correlate all DNS data with WHOIS records, certificate data, and search engine results to build a comprehensive target profile

🔵 Blue Team: Defense Perspective

Objective: Minimize information disclosure through DNS while maintaining legitimate functionality, detect reconnaissance activity, and ensure rapid response to unauthorized DNS changes.

Zone Transfer Lockdown: Configure ACLs to restrict AXFR/IXFR to authorized secondary nameservers only; use TSIG keys for authentication; verify restrictions with external testing
DNS Change Monitoring: Deploy real-time monitoring via DNSMonitor, Datadog, or AWS Route 53 alerts; integrate with SIEM for correlation and automated escalation
Passive DNS Awareness: Regularly query SecurityTrails, VirusTotal, and DNSDB for your own domains; track what historical information remains visible and plan remediation
DNSSEC Deployment: Enable DNSSEC with NSEC3 on all authoritative zones; validate chains regularly; prevent zone walking while ensuring authenticated responses
Information Minimization: Audit all DNS records for unnecessary disclosure; use generic hostnames in public records; remove debug entries from production zones
DNS Query Logging: Enable query logging on authoritative nameservers to detect unusual query patterns (e.g., systematic TXT record enumeration, ANY queries, or repeated zone transfer attempts)

Threat Intelligence

Threat Hunter's Eye: How Attackers Exploit DNS Weaknesses

DNS reconnaissance exploits the fundamental design of the internet's naming system. Understanding these patterns helps threat hunters and defenders identify when their organization is being targeted.

🔍 DNS Reconnaissance Patterns to Watch For

Attackers follow predictable patterns when conducting DNS reconnaissance. While individual DNS queries look identical to normal traffic, the aggregate pattern reveals malicious intent. Here are the key indicators:

Systematic TXT record enumeration: An unusual number of TXT queries in a short time window, often looking for SPF, DKIM, DMARC, verification tokens, and internal debugging information
ANY query floods: Repeated DNS ANY queries (requesting all record types) against a target domain, which some nameservers still answer and which reveal all records in one response
Zone transfer attempts: AXFR/IXFR queries from IP addresses that are not your designated secondary nameservers, the most direct indicator of DNS reconnaissance intent
Subdomain brute-force patterns: Hundreds or thousands of DNS queries for predictable subdomain patterns (admin, test, dev, staging, backup, internal, vpn, mail, api) within minutes
Reverse DNS sweeps: Sequential PTR queries across IP ranges belonging to the target organization, indicating an effort to map all domains on shared infrastructure
Passive DNS API abuse: High-volume queries to public passive DNS APIs for a specific domain, suggesting an automated tool is gathering historical intelligence

📡 Hunting Queries for DNS Analysts

These queries can be used in your SIEM, DNS logging platform, or security monitoring tools to detect potential DNS reconnaissance activity targeting your organization:

# Detect zone transfer attempts from unauthorized IPs
# Look for AXFR queries NOT from your secondary NS IPs
source_ip NOT IN (ns1.yourdomain.com, ns2.yourdomain.com)
AND dns.query_type = "AXFR"

# Detect subdomain brute-force patterns
# Flag when >50 unique subdomain queries in 5 minutes
COUNT(DISTINCT dns.query_name) > 50
WHERE dns.query_name ENDSWITH "yourdomain.com"
GROUP BY source_ip, time_window(5m)

# Detect systematic TXT record enumeration
dns.query_type = "TXT"
AND dns.query_name LIKE "%yourdomain.com"
AND COUNT(dns.query_name) > 10 per source_ip per hour

# Detect reverse DNS sweeps across your IP ranges
dns.query_type = "PTR"
AND dns.query_name LIKE "reverse-of-your-IP-range%.*"
AND COUNT(dns.query_name) > 20 per source_ip per hour

# Detect ANY queries (requesting all record types)
dns.query_type = "ANY"
AND dns.query_name LIKE "%yourdomain.com"

💡 The Silent Nature of DNS Reconnaissance

What makes DNS reconnaissance particularly dangerous is its inherent stealth. DNS queries are normal, expected internet traffic, every website visit, every email sent, every API call generates DNS queries. An attacker running systematic DNS reconnaissance generates traffic that is virtually indistinguishable from legitimate DNS resolution.

Unlike port scanning or vulnerability probing, which trigger IDS/IPS alerts and are blocked by firewalls, DNS reconnaissance is passive, non-intrusive, and almost never blocked. The queries go to public nameservers, not to the target's infrastructure directly. Passive DNS databases add another dimension: an attacker can gather comprehensive intelligence about your organization's DNS history without querying your nameservers at all.

This is why DNS hygiene, minimizing what information is publicly available, is far more effective than trying to detect reconnaissance activity. You cannot reliably detect who is querying your DNS records, but you can control what those records reveal. The most effective defense is ensuring that your DNS records expose only what is absolutely necessary for legitimate business operations.

Secure Your DNS Footprint Today

DNS reconnaissance is one of the first steps in nearly every cyber attack. The information your DNS records reveal, subdomains, IP addresses, mail servers, cloud providers, gives adversaries the blueprint they need to plan targeted attacks. Take control of your DNS visibility before someone else does.

🔎 Check Your DNS Footprint 🛡 CISA DNS Security Guide 📚 MITRE ATT&CK T1596.001

Have questions about DNS reconnaissance or want to share your experience? Join the discussion below.

🔗 Sibling Techniques, T1596 Search Open Technical Databases

📄 T1596, Parent Technique 👤 T1596.002, WHOIS 🔒 T1596.003, Digital Certificates ☁️ T1596.004, CDNs 🔎 T1596.005, Scan Databases

🔬 Related MITRE Techniques, Cross-Family References

T1590 · Network Info: T1590.002, DNS T1590 · Network Info: T1590.001, Domain Properties T1590 · Network Info: T1590.005, IP Addresses