📰 Originally published on SecurityElites — the canonical, fully-updated version of this article.
KALI DAY 23
·
DNS Reconnaissance
·
Most subdomain enumeration tutorials teach you to run Subfinder, check crt.sh, and call it done. Those tools are essential — but they miss an entire category of DNS information that only active querying reveals. I’ve found internal VPN hostnames, staging environments, and mail server configurations in DNS zones that no certificate transparency log ever recorded. The tool that finds them is Fierce, and on Kali Linux Day 23 — Fierce DNS Reconnaissance Tutorial we’re going to run it properly.
Fierce does one thing that most enumeration tools skip: it attempts a DNS zone transfer before brute forcing. A successful zone transfer hands you every DNS record in the domain — internal hostnames, mail servers, dev environments, the complete map — in a single query. It fails more often than it succeeds these days, but when it works, it’s the single most efficient recon operation you can run.
🎯 What You’ll Master in Day 23
How DNS zone transfers work and why misconfigured servers hand attackers the complete network map
Running Fierce with default and custom wordlists against lab targets
The –traverse flag and why adjacent IP reverse lookups reveal hidden hosts
Building a complete active recon workflow combining Fierce with Subfinder and httpx
Recognising and documenting zone transfer misconfiguration as a finding
⏱️ 20 min read · Kali Linux required for Exercises 2 & 3 ### 📋 Kali Linux Day 23 — Fierce DNS Reconnaissance Tutorial – Contents 1. DNS Reconnaissance Fundamentals 2. Zone Transfers — The Misconfiguration That Reveals Everything 3. Running Fierce — Installation and Core Usage 4. Advanced Fierce Techniques 5. Full DNS Recon Workflow ## DNS Reconnaissance Fundamentals DNS reconnaissance maps the network infrastructure attached to a domain. Every subdomain that resolves to an IP is a potential attack surface — a web application, an admin panel, a mail server, a VPN gateway. The DNS system is designed to be publicly queryable, which means a significant amount of infrastructure information is available without triggering any authentication or intrusion detection.
The DNS record types most valuable in recon are A records (domain to IPv4), AAAA records (domain to IPv6), MX records (mail servers — often direct access to mailservers bypassing front-end security), NS records (authoritative nameservers — the targets for zone transfer attempts), CNAME records (aliases — reveal internal naming conventions), and TXT records (SPF, DMARC, verification tokens that leak technology stack information).
Active DNS reconnaissance differs from passive in one critical way: your IP address hits the target’s nameservers. Every query is logged. This means you must be within scope before running active DNS recon tools like Fierce, and you should understand what “scope” means in the context of DNS — most bug bounty programs explicitly permit subdomain enumeration but not active port scanning, so clarify before you run.
DNS RECORD TYPES — RECON REFERENCECopy
Query specific DNS record types
dig target.com A # IPv4 addresses
dig target.com MX # Mail servers → bypass spam filters
dig target.com NS # Nameservers → zone transfer targets
dig target.com TXT # SPF, DMARC, tech stack leakage
dig target.com CNAME # Aliases → naming convention patterns
Manual zone transfer attempt with dig
dig axfr target.com @ns1.target.com
; If successful: all DNS records returned
; If misconfigured: “Transfer failed” message
Quick subdomain check
host dev.target.com # Does dev subdomain exist?
nslookup vpn.target.com # VPN gateway check
Zone Transfers — The Misconfiguration That Reveals Everything
A DNS zone transfer (AXFR request) is a legitimate DNS operation where secondary nameservers synchronise their records from the primary. The security issue arises when the primary nameserver is configured to allow transfers from any IP address — not just authorised secondaries. When that misconfiguration exists, any attacker can request the complete zone and receive every DNS record: internal hostnames, internal IP addresses, mail servers, dev and staging environments, VPN gateways.
Zone transfers were a common misconfiguration in the early 2000s and remain present in older infrastructure — internal DNS servers, small hosting providers, and legacy corporate DNS deployments that haven’t been audited. I’ve encountered zone transfer success on internal network assessments far more often than on external targets, particularly against Active Directory DNS servers that weren’t hardened after initial deployment.
securityelites.com
Zone Transfer Attack Chain
STEP 1 — Discover Nameservers
dig target.com NS → reveals ns1.target.com, ns2.target.com
↓
STEP 2 — Attempt Zone Transfer
dig axfr target.com @ns1.target.com → test each nameserver
↓
IF VULNERABLE — All Records Returned
dev.target.com → 192.168.1.50 (INTERNAL IP!)
vpn.target.com → 203.0.113.10
admin.target.com → 203.0.113.11
db-01.target.com → 10.0.0.5 (INTERNAL DB!)
↓
REPORTING — Zone Transfer Misconfiguration
CWE-16: Configuration — Medium to High severity
Fix: restrict AXFR to authorised secondary IPs only
📸 Zone transfer attack chain. The severity rating depends on what the zone reveals — an external DNS zone showing only public-facing hosts is low severity. A zone revealing internal IP addresses, internal hostnames, and infrastructure naming conventions is High to Critical because it hands the attacker a network map they’d otherwise need weeks of scanning to build.
📖 Read the complete guide on SecurityElites
This article continues with deeper technical detail, screenshots, code samples, and an interactive lab walk-through. Read the full article on SecurityElites →
This article was originally written and published by the SecurityElites team. For more cybersecurity tutorials, ethical hacking guides, and CTF walk-throughs, visit SecurityElites.
Top comments (0)