Ethical Hacking
DNS Enumeration
The internet runs on DNS. Every domain name, every subdomain, every mail server — all of it is mapped through a distributed database that anyone can query. For a pen tester, that database is one of the richest sources of intelligence available, and most of it is sitting in plain sight.
DNS is the phone book — and it is public
Before the web existed, large organisations maintained physical phone books — a central directory mapping names to contact numbers. DNS is the digital equivalent. It maps human-readable domain names like company.com to the numerical IP addresses that computers actually use to communicate. Without it, you would need to memorise IP addresses to visit any website.
The critical thing for a pen tester to understand is that DNS records are, by design, publicly accessible. They have to be — if they were private, nobody outside the organisation could reach their website, send them email, or connect to their services. That openness is a feature of how the internet works. It also means that querying DNS records is entirely passive reconnaissance. You are reading a public directory, not probing a private system.
What makes DNS enumeration genuinely valuable in a pen test is how much infrastructure it can reveal. A carefully read set of DNS records can tell you which cloud providers the company uses, how their email is routed, whether they have any unprotected subdomains, and sometimes even internal server names that were never meant to be visible externally.
The record types that actually matter
DNS has over a dozen record types but in practice, a handful come up in almost every engagement. Each one answers a different question about the target's infrastructure. Here is what each record type reveals and why a pen tester cares about it.
The CNAME record deserves extra attention. Subdomain takeover — where an attacker registers a service that an abandoned CNAME points to and takes control of that subdomain — has affected large companies including Microsoft, Shopify, and Snapchat. It is a finding that requires no exploitation skill at all, just careful reading of DNS records during passive recon.
Zone transfers — when a misconfiguration gives away everything
A DNS zone transfer is a mechanism that exists for a legitimate reason. When an organisation runs multiple DNS servers, the primary server needs a way to replicate its complete record database to the secondary servers so they stay in sync. A zone transfer does exactly that — it sends a full copy of all DNS records for a domain to whoever asks.
The problem is that some DNS servers are misconfigured to allow zone transfers from any IP address — not just the other DNS servers in the same organisation. When that happens, an attacker can request a complete dump of every DNS record for the entire domain. Every subdomain. Every internal server name. Every IP address. All in one request, all in a few seconds.
It is one of those findings that causes genuine alarm in a debrief. Handing a client a complete map of their internal DNS infrastructure — gathered passively in under a minute — consistently gets a strong reaction. It should. A real attacker gets exactly the same map.
Real-world context: Zone transfers were a significant attack surface in the early internet era and remain a finding in modern pen tests more often than you might expect. Older DNS servers and legacy configurations frequently have this misconfiguration. If you find one in an engagement, it goes straight to the top of the report as a critical information disclosure finding — even though no exploitation was involved.
Running DNS enumeration against your lab target
Metasploitable runs its own DNS service — which means you can practise every DNS enumeration technique covered in this lesson directly against your lab target, completely legally, inside your private network.
The scenario: Your client is a mid-sized manufacturing company. You are on day one of the engagement, passive recon is complete, and you have just moved into the active reconnaissance phase. Your whitelisted IP is authorised to query their DNS servers directly. You begin DNS enumeration to map their record structure before any port scanning begins.
# dig is the primary DNS query tool on Linux
# We are querying DNS records directly — this is active recon
# Only run this after your IP has been authorised for the active phase
# Query the A record — what IP address does this domain resolve to?
# Replace 192.168.56.101 with your Metasploitable IP from Lesson 9
dig A target.local @192.168.56.101
# Query the MX record — which server handles email for this domain?
dig MX target.local @192.168.56.101
# Query the NS record — which name servers are authoritative for this domain?
dig NS target.local @192.168.56.101Breaking it down:
The @ symbol tells dig to send the query directly to that specific DNS server instead of using your system's default resolver. In a real engagement, you would point this at the target's own nameserver — so you are querying their infrastructure directly rather than through a public DNS service.
The TTL — Time To Live — measured in seconds. 604800 seconds is exactly one week. This tells caching DNS resolvers how long to keep this record before checking for an update. Long TTLs mean changes to DNS records propagate slowly, which matters during incident response.
The number 10 is the MX priority. Lower number means higher priority — email gets delivered here first. The subdomain mail.target.local is a new hostname that just surfaced from a single DNS query. Write it down and add it to your growing target list.
Now attempt a zone transfer. In a lab environment, Metasploitable is deliberately misconfigured to allow this — which means you will see exactly what a successful zone transfer looks like in practice.
# Attempt a DNS zone transfer using dig
# AXFR is the record type that requests a full zone transfer
# If the DNS server is misconfigured, it returns every single DNS record for the domain
# On a properly secured server, this request is refused with a "Transfer failed" message
# On Metasploitable, it is intentionally open — so you will see the full response
# The structure is: dig AXFR [domain] @[nameserver IP]
dig AXFR target.local @192.168.56.101Breaking it down:
AXFR stands for Authoritative Full Zone Transfer. It was designed for DNS server-to-server replication. When a nameserver responds to this request from an unauthorised IP, that is the misconfiguration — it should only respond to known secondary nameservers.
A development server that would never have appeared in passive recon. This is the value of a successful zone transfer — internal subdomains that were never meant to be discoverable from outside the organisation are now fully mapped. Development environments are almost always less hardened than production.
The SOA record contains the administrator email address in a dot-separated format. root.target.local means root@target.local. This tells you the DNS admin account uses root — a significant security concern that also belongs in the report.
In eight lines of output, you now have five internal IP addresses, five hostnames, and a complete map of the target's DNS infrastructure. A dev server, an FTP server, a VPN gateway — all discovered without any exploitation, all from a single misconfigured DNS setting. That is the power of DNS enumeration done properly.
dnsenum — automating the enumeration process
Running individual dig queries works well for targeted lookups but becomes tedious when you need to enumerate a domain thoroughly. dnsenum automates the process — it queries all the common record types, attempts a zone transfer, and then brute-forces subdomain names from a wordlist, all in a single run.
It produces a comprehensive DNS picture in a fraction of the time it would take to run each query manually. This is the tool most pen testers reach for when they want a thorough DNS profile rather than specific targeted queries.
# dnsenum automates DNS enumeration — it runs multiple queries in sequence
# It queries A, MX, NS, SOA records, attempts a zone transfer,
# and then brute-forces subdomain names using a wordlist
# Pre-installed on Kali — no setup needed
# --dnsserver tells dnsenum to query this specific DNS server directly
# rather than relying on your system's default resolver
# Replace 192.168.56.101 with your Metasploitable IP
dnsenum --dnsserver 192.168.56.101 target.localBreaking it down:
dnsenum attempts a zone transfer automatically as part of its standard run. You do not have to think about this — it just happens. If the server is misconfigured, you get the full dump. If it is properly secured, dnsenum moves on without breaking stride.
After the zone transfer, dnsenum tries common subdomain names from a built-in wordlist — admin, test, staging, dev, mail, vpn, api, and hundreds more. Any that resolve to a real IP address get added to the results. This found admin.target.local at .106 — a host that was not in the zone transfer output at all.
Found through brute-force subdomain guessing rather than zone transfer. This means even a properly secured DNS server that blocks zone transfers can still leak subdomain information if an attacker tries common names. The two techniques complement each other — always run both.
Pulling findings together — a DNS intelligence summary
At the end of a DNS enumeration phase, you consolidate everything into a clean summary that feeds directly into the next phase of the engagement. Here is what that summary looks like after running the queries above.
Six hosts mapped, two critical targets identified, and the DNS server itself confirmed as misconfigured for zone transfers — all before a single port scanner has run. This is the target list that feeds the scanning phase in Lesson 12. Everything from here is faster and more focused because the DNS enumeration was done properly.
Teacher's Note: A successful zone transfer is one of those findings that always lands hard in a client debrief. It requires no technical exploitation — just a single misconfigured setting — yet it hands an attacker a complete internal network map. Always attempt it, always document it, and always explain the business impact clearly in the report.
Practice questions
Scenario:
Scenario:
Scenario:
Quiz
Scenario:
Scenario:
Scenario:
Up Next · Lesson 12
Whois & Network Enumeration
From DNS records to network ranges — mapping the full scope of an organisation's internet-facing infrastructure before scanning begins.