If you learn one DNS enumeration tool, make it dnsrecon. It is the Swiss Army knife of the category: a single, actively maintained Python script that pulls standard records, attempts zone transfers against every nameserver, enumerates SRV records, brute forces subdomains, does reverse lookups, and exports clean XML, CSV, or JSON. This article is part of the PingLabz DNS enumeration guide, and every command below was run from Kali against a real BIND9 server in a lab we control.
What dnsrecon does
dnsrecon (the "DNS Recon" tool) rolls the entire enumeration workflow into one command with a -t type switch. It can check all NS records for zone transfers, enumerate general records (MX, SOA, NS, A, AAAA, SPF, TXT), perform SRV record enumeration, expand top-level domains, check for wildcard resolution, brute force subdomains from a wordlist, and do PTR lookups across a CIDR range. That breadth is why most testers reach for it first.
It comes preinstalled on Kali. Elsewhere: sudo apt install dnsrecon, or pip install dnsrecon on any system with Python 3.6+.
The lab target
The target for this cluster is a BIND9 server at 192.168.99.100, authoritative for the internal domain pinglabz.lab. The zone lists two nameservers (ns1 is live, ns2 is a dead address), a pair of mail servers, SPF and verification TXT records, SRV records for LDAP and Kerberos, an IPv6 host, and a spread of internal A records. It deliberately allows zone transfers to the attacker so you can see the worst case. Full topology is in the pillar guide.
Standard enumeration and the zone transfer
The highest-value single command is a standard enumeration with a zone-transfer attempt (-a), pointed at a specific nameserver with -n:
root@kali:~# dnsrecon -n 192.168.99.100 -d pinglabz.lab -a
[*] Checking for Zone Transfer for pinglabz.lab name servers
[*] Resolving SOA Record
[*] SOA ns1.pinglabz.lab 192.168.99.100
[*] Resolving NS Records
[*] NS Servers found:
[*] NS ns2.pinglabz.lab 10.0.53.11
[*] NS ns1.pinglabz.lab 192.168.99.100
[*] Trying NS server 10.0.53.11
[-] Zone Transfer Failed for 10.0.53.11!
[-] Port 53 TCP is being filtered
[*] Trying NS server 192.168.99.100
[+] 192.168.99.100 Has port 53 TCP Open
[+] Zone Transfer was successful!!
[*] NS ns1.pinglabz.lab 192.168.99.100
[*] TXT v=spf1 mx a:mail.pinglabz.lab -all
[*] TXT plz-verification=dns-recon-lab-2026
[*] AAAA ipv6host.pinglabz.lab 2001:db8:53::10
[*] A admin.pinglabz.lab 10.0.53.99
[*] A backup.pinglabz.lab 10.0.53.60
[*] A dc01.pinglabz.lab 10.0.53.5
[*] A jenkins.pinglabz.lab 10.0.53.91
[*] A mail.pinglabz.lab 10.0.53.20
[*] A vpn.pinglabz.lab 10.0.53.30Notice how dnsrecon walks every nameserver in the NS set. The dead ns2 refuses (port 53 TCP filtered), then ns1 answers and the whole zone spills out - mail servers, the domain controller, a Jenkins box, the VPN gateway, an IPv6 host, and every internal 10.0.53.x address. That is the entire value of the tool in ten seconds.
Brute forcing when the transfer is blocked
On a properly configured target, that AXFR fails on every nameserver. Then you switch to brute force with -t brt and a wordlist:
root@kali:~# dnsrecon -n 192.168.99.100 -d pinglabz.lab -D /home/j/dns-recon/subs.txt -t brt
[*] Performing host and subdomain brute force against pinglabz.lab...
[*] A mail2.pinglabz.lab 10.0.53.21
[*] A www.pinglabz.lab 10.0.53.10
[*] A vpn.pinglabz.lab 10.0.53.30
[*] A intranet.pinglabz.lab 10.0.53.50
[*] A db.pinglabz.lab 10.0.53.70
[*] CNAME smtp.pinglabz.lab mail.pinglabz.lab
[*] A jenkins.pinglabz.lab 10.0.53.91
[*] A dc01.pinglabz.lab 10.0.53.5
[*] CNAME web.pinglabz.lab www.pinglabz.lab
[*] CNAME router.pinglabz.lab gw.pinglabz.lab
[*] 25 Records FoundBrute force resolves CNAME aliases too, so you see the relationships (smtp is really mail, web is really www). It only finds names in your wordlist, so quality matters - the wordlists in /usr/share/wordlists/ and SecLists are the usual starting points.
The options that matter
A common one-liner for a real engagement combines standard enumeration, a wordlist, and XML output: dnsrecon -d target.com -D /usr/share/wordlists/dnsmap.txt -t std --xml dnsrecon.xml. dnsrecon also checks the target's BIND version and tests for NXDOMAIN hijacking unless you disable those with --disable_check_bindversion and --disable_check_nxdomain.
The defender's view
The scariest line in the output above is "Zone Transfer was successful". Lock allow-transfer down to your known secondaries by IP and TSIG key, and that entire capture becomes a row of failures. Run dnsrecon against your own domain periodically - if -a ever succeeds from an unauthorised host, you have a finding to fix. See the hardening checklist in the DNS enumeration pillar.
Related tools
dnsrecon overlaps with dnsenum, which produces a similar all-in-one report in Perl. For heavy subdomain brute forcing, hand off to dnsmap or, at scale, massdns. To audit a zone you have transferred, use dnswalk. Once recon is done and you have live hosts, move on to port scanning with the Nmap cluster.
Key takeaways
dnsrecon is the first DNS enumeration tool to learn because it does the whole workflow in one script: standard records, zone transfers across every nameserver, SRV enumeration, and subdomain brute forcing, with clean export formats. Lead with -a to catch a leaky server, fall back to -t brt with a good wordlist when transfers are blocked, and export to XML or JSON for reporting. Then run it against your own domains, because the same command an attacker uses is the fastest way to find out what your DNS is giving away.
Only run dnsrecon against domains you own or are explicitly authorised to test. The output here is from a private lab.
