DNS Reconnaissance: Real-Life Use Cases and Tools

Every successful penetration test or red team exercise begins with a scope. From there, DNS reconnaissance is one of the most useful ways to start building an asset map.
But DNS reconnaissance use cases aren’t limited to pentesting — one can do a lot of interesting things using DNS data as a starting point. In this post, we will look at the other applications of DNS reconnaissance and the tools that turn simple DNS queries into actionable data points for a security assessment. If you need a refresher on DNS basics before diving into DNS reconnaissance, check out this DNS primer.

What Is DNS Reconnaissance?

DNS reconnaissance is the process of collecting information about a target’s Domain Name System (DNS) infrastructure, including subdomains, DNS servers, and DNS records. 

It’s widely used in a variety of cybersecurity processes, such as  attack surface management, penetration testing, threat intelligence, and other, to understand how a domain is structured and which systems are exposed.

How DNS Reconnaissance Works

DNS reconnaissance converts a single domain into a list of connected assets, including IP addresses, mail servers, subdomains, and other network clues. It relies on DNS records to identify these additional assets and, in the process, may also uncover network misconfigurations. 

DNS reconnaissance involves DNS enumeration as the first step to collect all records, followed by additional techniques that rely on the initial data gathered to expand on the findings.

DNS Enumeration

DNS enumeration is the process of discovering as many DNS records for a domain as possible to map the DNS infrastructure and find misconfigurations. The table below shows the DNS records commonly targeted during this stage and the DNS data points and insights they reveal.

Record TypeWhat It Reveals
A and AAAA recordsMaps a domain to its physical or cloud-hosted IPv4 or IPv6 address.
CNAME recordReveals aliases for a domain or subdomain, which may point to third-party services such as AWS, Zendesk, or Shopify, and can indicate external platforms used by an organization. 
PTR recordProvides the domain associated with an IP address (if the starting point for enumeration was an IP address rather than a domain name)
SRV recordSpecifies the hostname and port of servers providing specific services, including Active Directory, VoIP, or messaging protocols.
MX recordIdentifies the mail servers and shows if a company uses on-premise mail servers or cloud providers like Google Workspace or Microsoft 365.
NS recordLists the authoritative name servers for the domain, which can be targeted for deeper queries or potential exploits.
TXT recordSince these DNS records are often used for security and verification, they can leak authorized IP ranges, third-party email services (via configuration records such as SPF, DKIM, and DMARC), SaaS providers, and internal or legacy configuration clues.
SOA recordContains the DNS administrator’s contact email and the zone serial number, which can reveal update frequency, operational practices, and potential misconfigurations. 

From the DNS records retrieved during the DNS enumeration phase, you can collect a lot of data: domains, subdomains, IP addresses, mail servers, name servers, hosting providers, and even misconfigurations. You can use these as inputs for your next reconnaissance steps. 

DNS Enumeration as a part of DNS reconnaissance

DNS Zone Transfer

Once you’ve identified the authoritative DNS servers for the domain name, you can attempt an AXFR request (aka zone transfer request). If that server is misconfigured to allow AXFR requests from any IP address, you can download a full copy of the DNS zone file, which may include many hostnames, subdomains, and associated records.

A successful AXFR request provides a map of the internal and external networks without requiring you to guess a single hostname, allowing you (and unauthorized users) to obtain more internal network information that can be used in other attacks. 

DNS Brute Forcing

Another DNS reconnaissance technique is the use of brute forcing to find subdomains. This involves running a script that queries the target DNS server using a massive list of common prefixes (dev, staging, vpn, or api). 

If the server returns an IP address for a query, that means the subdomain exists. This technique is often used by subdomain enumeration tools. Discovering subdomains this way can point attackers towards vulnerable production environments that can be targeted in further attack simulations.

Reverse DNS Lookup

When you have a range of IP addresses belonging to the target, you can perform a reverse DNS lookup to identify the domain names associated with those IP addresses. This helps you map out the external assets associated with the organization and identify services associated with the IP addresses, so you’ll have a better picture of its external attack surface.

Passive DNS Enumeration vs. Active DNS Enumeration

When you're performing DNS reconnaissance, the choice between passive and active methods usually depends on your rules of engagement and how stealthy you need to be.

Passive enumeration techniques gather DNS data without sending a packet to the target's infrastructure. You query third-party DNS databases that have already crawled the web or collected logs from recursive resolvers. The target won’t be able to detect these techniques, but the data might be slightly outdated and not complete.

Active enumeration involves sending DNS queries that may reach the target’s infrastructure (directly to authoritative servers or via resolvers), such as targeted lookups, brute-forcing, and zone transfer testing. While the data you gather is up-to-date, active enumeration is noisy and increases the risk of triggering alerts.

Passive vs active DNS reconnaissance

Use Cases for DNS Reconnaissance 

External Asset Discovery

The goal of DNS reconnaissance, when used for external asset discovery, is to expand the asset catalog beyond what the client already knows, since organizations may accumulate (and forget) legacy servers, marketing sites, shadow IT assets, and other internet-facing assets over time, and all of which can become potential parts of an attack path. As part of the broader attack surface management and pentesting, external asset discovery leads to:

  • Subdomain enumeration via A / AAAA / CNAME
  • Discovery of forgotten, legacy, development, or test systems
  • Identification of internet-facing services
  • Discovery of lateral paths

How to do it: Use automated discovery tools that perform DNS lookups to retrieve DNS records for multiple domains and then do reverse lookups of the uncovered DNS data points. Below is a very basic example of how these tools work under the hood.

Example: The DNS lookup result of yahoo[.]com included A records pointing to 74[.]6[.]143[.]25 and 74[.]6[.]143[.]26.

Forward DNS lookup for yahoo.com

A reverse IP lookup gave a list of subdomains associated with these IP addresses, including:

  • atsv2-fp.wg1.b.yahoo[.]com
  • Media-router-fp73.prod.media.vip.bf1.yahoo[.]com
  • new-fp-shed.wg1.b.yahoo[.]com
  • media-router-fp74.prod.media.vip.bf1.yahoo[.]com

This way, we’ve successfully discovered some of yahoo’s subdomains. 

Further enrichment: To get better results, combine DNS queries with WHOIS lookups and IP range scanning to find other blocks of infrastructure owned by the same organization. Subdomain enumeration tools have this combination under the hood already, but in many cases DNS external asset discovery helps you find other assets such as IP addresses, email addresses, and more.

Technology Fingerprinting 

Knowing the target’s tech stack allows you to tailor your pentest approach. If you know a site uses an outdated version of a specific CDN or a specific cloud provider, you can look for known vulnerabilities or misconfigurations unique to that vendor. 

Although DNS alone won't tell you the exact software version a server is running, it provides hints and helps you choose the right tool, exploit, and attack paths.

How to do it: Analyze CNAME records to see if they point to SaaS platforms like Zendesk or cloud providers like AWS. Check TXT records for third-party verification strings from services like Google, Microsoft, or Atlassian. 

Example: The TXT record for example1[.]com contains the string v=spf1 a mx include:websitewelcome.com ~all. This strongly suggests that the domain’s hosting provider is HostGator, which uses websitewelcome[.]com for its resellers’ mail servers. With that information, if we were still in 2019, an attacker could’ve tried exploiting one of the information disclosure vulnerabilities that plagued HostGator to gain access to private information. These particular issues were fixed long ago and are not relevant now, but you get the gist.

DNS details for example1.com

Further enrichment: While DNS helped identify some providers, you would need to combine it with port scanning, web scraping, and other methods to get a more complete picture of the organization’s tech stack. 

Mail Infrastructure Reconnaissance 

This process reveals how well-protected an organization is against email-based attacks and enables phishing simulations and mail spoofing tests. It identifies where their mail is hosted and whether they have implemented security protocols to prevent others from sending mail as their domain.

How to do it: Pull the MX records to see who handles their email. Then, dig into TXT records to find SPF, DKIM, and DMARC policies.

Example: The MX record for meta[.]com tells us that the company is using Proofpoint Email Protection, a specialized gateway that sits in front of the actual mail servers to filter out spam, malware, and phishing. As a pentester, you now know your test emails would be analyzed by Proofpoint’s sandbox, and common lures would likely be flagged. 

DNS lookup details for meta.com

Based on its TXT record, Meta’s SPF record uses a redirect. This means the actual, more detailed SPF policy is stored in the TXT record for the domain: _spf.fb[.]com.

SPF DNS lookup details for meta.com

Further enrichment: You can deconstruct the real SPF record (_spf.fb[.]com in our example), which will likely specify authorized sending IP addresses and IP ranges for the target organization, and inspect the SSL certificates associated with those IP addresses to gain more information about the organization’s email-sending eco-system.

DNS Misconfiguration Reconnaissance

DNS misconfiguration reconnaissance looks for weaknesses in DNS setups that attackers could use to redirect traffic, take over subdomains, or abuse email systems. It involves analyzing DNS records and how DNS servers respond to queries, often focusing on the authoritative name servers discovered during earlier enumeration. 

How to do it: Here are some ways you can perform DNS misconfiguration recon:

  • DNS zone transfer testing: If the DNS server is misconfigured to allow AXFR requests from any IP address, an attacker can download the entire DNS zone file.
  • Dangling CNAME discovery: A dangling CNAME occurs when your DNS points to an external service (e.g.,  a GitHub Pages, an AWS S3 bucket, or a Zendesk portal) that has been deleted or expired, but the DNS record remains. This can lead to subdomain takeover.
  • Overly permissive DNS delegation: Delegation happens when a parent zone (company[.]com) passes authority for a child zone (lab[.]company[.]com) to a different set of name servers, and those name servers have weak security. If an attacker gains control over the delegated name servers, they can redirect traffic for that subdomain and any of its children.
  • Leaked internal naming via TXT/SRV: TXT and SRV records contain metadata that provides clues about a target’s internal environment. Querying them can reveal the software and providers a company uses, helping you narrow down what’s needed for penetration testing. 

Further enrichment: You can complement the insights from the DNS misconfiguration reconnaissance to do advanced recon, such as targeted brute-forcing, infrastructure fingerprinting, and virtual host fuzzing.

DNS Recon Tools

Nslookup and Dig Commands

nslookup and dig are the standard command-line tools for querying DNS servers. While they do similar things, they differ in the DNS data points they provide and how they are normally used in workflows.

The nslookup command maps a hostname to an IP address in a clean and summarized format, and can also be used for reverse IP lookup, MX lookup, and TXT lookup. It’s built into Windows, macOS, and Linux. Below are sample queries:

nslookup example[.]com

nslookup example[.]com 1.1.1.1 (if you know the specific DNS server for the domain)

nslookup 8.8.8.8 (reverse lookup)

nslookup -query=mx example[.]com (MX lookup)

nslookup -query=txt example[.]com (TXT lookup)

The dig command returns detailed metadata, including query flags, Time to Live (TTL) values, and technical status codes like NXDOMAIN. You can use it to look up A, AAAA, SOA, TXT, NS, and MX records, as well as do a reverse IP lookup. It’s native to macOS and Linux, but Windows users must install it manually. Here’s how standard DNS queries look like:

dig example[.]com

dig AAAA example[.]com

dig example[.]com MX

dig example[.]com NS

dig example[.]com SOA

dig example[.]com TXT

If you only want the record without other details, you can add +short to the command, like this:

dig example[.]com +short

dig example[.]com MX +short

dig example[.]com NS +short

dig example[.]com SOA +short

dig example[.]com TXT +short

Use the -x flag to do a reverse lookup:

dig -x 8.8.8.8 +short

DNS Lookup APIs

Manual DNS discovery using the nslookup and dig commands are not always possible, especially when you’re working with organizations with complex DNS infrastructure and large attack surfaces. For scaling, you can use DNS Lookup API, which can check thousands of domains in seconds and covers 26 record types, or DNS Chronicle API to retrieve the historical A and AAAA records of multiple domains. 

Subdomain Enumeration Tools 

Tools like Amass and Subfinder are industry standards. They help penetration testers find every possible subdomain using different active and passive techniques and data sources, such as Certificate Transparency logs, public DNS servers, brute-forcing, and many more. You can find a deeper dive into these in this guide.

Passive DNS Databases

If you need to avoid API constraints, such as rate limits and timeouts, or run complex DNS enumeration processes, a passive DNS database can help. You can download large DNS datasets and run bulk queries that might take hours when using APIs. 

Databases also allow you to use regular expressions (regex) or fuzzy searches to find subdomains that might be relevant to your target. And because you have the raw data available in a database, you can perform statistical analysis that an API wouldn't allow. For example, you might notice that three years ago, 10 subdomains began pointing to the IP addresses of the organization’s old hosting provider, but only a few of those subdomains are in your asset inventory.

Conclusion

DNS reconnaissance is the data-collection phase of many important cybersecurity processes, such as penetration testing, red teaming, attack surface management, and threat actor infrastructure mapping. You can start with one domain and end with a detailed map of the target’s DNS infrastructure, along with some misconfigurations, using a combination of active and passive reconnaissance techniques. 

DNS data is extremely diverse and rich. Every record links to another, there are many ways to pivot off each, so a single piece of information can act as a starting point for a lot of discoveries, enabling you to get a more complete picture of the target.

Check out the threat reports we build using DNS reconnaissance or try out DNS recon yourself with our APIs.

Try our WhoisXML API for free
Get started