Introduction
Domain Name System (DNS) intelligence gathering is a critical first step in the reconnaissance phase of cybersecurity. DNS acts as the phonebook of the internet, translating human-readable domain names into IP addresses. By querying DNS records, security professionals can uncover a wealth of information about a target's infrastructure, including mail servers, subdomains, and security configurations.
DNS is especially valuable in reconnaissance because it reveals infrastructure relationships rather than just one endpoint. A single domain can point you toward web servers, mail providers, validation tokens, aliases, and sometimes entire forgotten environments. That is why DNS intelligence often expands the scope of an assessment dramatically.
In this lab, you will learn how to use two powerful command-line tools, host and dig, to perform DNS reconnaissance. We will use a deliberately vulnerable domain, zonetransfer.me, which is specifically designed by security researchers for practicing DNS queries and zone transfers safely. You will learn how to extract basic IP records, mail server details, text records, and even attempt a full zone transfer to map out the target's entire DNS footprint.
Query Basic IP Records (A/AAAA)
In this step, you will learn how to retrieve the most fundamental DNS records: A and AAAA records. An A record maps a domain name to an IPv4 address, while an AAAA record maps it to an IPv6 address. Finding these IP addresses is essential because it tells you exactly where the target's main web server is hosted.
This is a reminder that domains and hosts are not the same concept. A domain name is a label in DNS. An IP address is where traffic is ultimately routed. Reconnaissance often starts by translating between those two views.
We will start by using the host command, which is a simple utility for performing DNS lookups. Ensure you are in your default working directory ~/project.
Run the following command to perform a basic lookup on our target domain:
host zonetransfer.me
You should see an output similar to this, showing the IPv4 address and the mail servers associated with the domain:
zonetransfer.me has address 5.196.105.14
zonetransfer.me mail is handled by 10 alt2.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx2.googlemail.com.
zonetransfer.me mail is handled by 10 alt1.aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx3.googlemail.com.
zonetransfer.me mail is handled by 0 aspmx.l.google.com.
zonetransfer.me mail is handled by 20 aspmx4.googlemail.com.
zonetransfer.me mail is handled by 20 aspmx5.googlemail.com.
While host is great for quick checks, the dig (Domain Information Groper) command provides much more detailed output and flexibility. Let's use dig to specifically ask for the A record. We will use the +short flag to keep the output clean, showing only the IP address.
To save our reconnaissance data for later analysis, we will redirect the output of our dig command into a text file named a_records.txt. Run the following command:
dig A zonetransfer.me +short > ~/project/a_records.txt
You can view the contents of the file you just created using the cat command:
cat ~/project/a_records.txt
The output will display the IPv4 address of the target domain. Saving your findings is a crucial habit in intelligence gathering, as it allows you to build a comprehensive profile of your target over time.
5.196.105.14
Query Mail and Text Records (MX, TXT)
In this step, we will dig deeper into the target's infrastructure by querying Mail Exchange (MX) and Text (TXT) records.
MX records specify the mail servers responsible for accepting email messages on behalf of a domain. Identifying these servers can reveal which third-party email providers the target uses (like Google Workspace or Microsoft 365) or if they host their own mail infrastructure.
TXT records are similarly valuable because they often describe trust relationships, such as which systems are allowed to send mail or which external services have been verified for the domain.
Let's query the MX records for our target domain using dig:
dig MX zonetransfer.me +short
You will see a list of mail servers along with their priority numbers (lower numbers mean higher priority):
20 aspmx5.googlemail.com.
10 alt1.aspmx.l.google.com.
10 alt2.aspmx.l.google.com.
20 aspmx2.googlemail.com.
20 aspmx3.googlemail.com.
0 aspmx.l.google.com.
20 aspmx4.googlemail.com.
Next, we will look at TXT records. Administrators use TXT records to add arbitrary text to a domain's DNS. In cybersecurity, TXT records are highly valuable because they often contain Sender Policy Framework (SPF) rules, DomainKeys Identified Mail (DKIM) configurations, and various site verification tokens. These can reveal internal IP ranges authorized to send emails or third-party services integrated with the domain.
Let's query the TXT records and save the output to a file named txt_records.txt in your working directory:
dig TXT zonetransfer.me +short > ~/project/txt_records.txt
View the contents of the file to see what information the administrators have left in the TXT records:
cat ~/project/txt_records.txt
You might notice entries starting with v=spf1, which define the email sending policies, or various verification strings. This information helps map out the trust relationships the target domain has with other services.
"google-site-verification=tyP28J7JAUHA9fw2sHXMgcCC0I6XBmmoVi04VlMewxA"
Discover Subdomains (CNAME)
In this step, you will learn about Canonical Name (CNAME) records. A CNAME record is used to map an alias name to a true or canonical domain name. For example, www.example.com might be a CNAME pointing to example.com.
Discovering subdomains is a critical part of expanding your attack surface. Often, organizations secure their main website but forget to update or secure older, forgotten subdomains (like dev.target.com or testing.target.com).
Let's query a specific subdomain that is known to exist on our practice target to see how CNAME records behave. We will query testing.zonetransfer.me and save the results.
Run the following command to query the CNAME record and save it to cname_records.txt:
dig CNAME testing.zonetransfer.me +short > ~/project/cname_records.txt
Now, inspect the file you just created:
cat ~/project/cname_records.txt
You should see an output like www.zonetransfer.me.. This tells us that testing.zonetransfer.me is actually just an alias pointing to another domain entirely. Finding these relationships can lead a security researcher to discover third-party hosting providers or hidden infrastructure that belongs to the target.
Attempt DNS Zone Transfer
In this final step, you will attempt a DNS Zone Transfer. A zone transfer (specifically using the AXFR query type) is a mechanism used by DNS servers to replicate DNS databases across multiple servers.
Zone transfers are a classic example of a legitimate administrative feature becoming a security issue when access control is weak. The mechanism itself is normal. The misconfiguration is allowing arbitrary outsiders to request the full data.
If a DNS server is misconfigured, it might allow any anonymous user to request a full copy of the zone file. This is a massive security vulnerability because it instantly provides the attacker with a complete map of every single subdomain, IP address, and record associated with the domain, bypassing the need for guessing or brute-forcing subdomains.
To attempt a zone transfer, we first need to know the authoritative Name Servers (NS) for the domain. Let's query the NS records:
dig NS zonetransfer.me +short
You should see output listing the name servers, such as:
nsztm1.digi.ninja.
nsztm2.digi.ninja.
Now that we have the name server (nsztm1.digi.ninja), we can directly ask it for a full zone transfer using the axfr record type. The syntax for dig requires us to specify the target domain and the specific name server we are querying (using the @ symbol).
Run the following command to attempt the zone transfer and save the massive amount of output to zone_transfer.txt:
dig axfr zonetransfer.me @nsztm1.digi.ninja > ~/project/zone_transfer.txt
Once the command completes, view the first few lines of the file using the head command:
head -n 20 ~/project/zone_transfer.txt
You will see a complete dump of the domain's DNS records, including hidden subdomains, internal IP addresses, and various text notes left by administrators. In a real-world scenario, finding an open zone transfer is a critical finding that significantly accelerates the reconnaissance phase.
Summary
Congratulations! You have successfully completed the DNS Intelligence Gathering lab.
In this lab, you learned how to leverage the host and dig commands to perform passive reconnaissance on a target domain. You explored how to extract basic IPv4 addresses (A records), identify mail infrastructure (MX records), and uncover security policies and third-party integrations (TXT records). You also learned how to trace domain aliases (CNAME records) to discover hidden subdomains. Finally, you successfully executed a DNS zone transfer (AXFR) against a misconfigured name server, demonstrating how a single vulnerability can expose an organization's entire external network topology.
These skills form the foundation of external network mapping and are essential for any cybersecurity professional conducting penetration testing or vulnerability assessments.
