DNS - Port 53
Cheatsheet
# Nmap
nmap -sV -sC -p53 <IP>
nmap -sU -sV -p53 <IP>
nmap --script "dns-*" -p53 <IP>
# BIND version (CHAOS class no banner exists for DNS)
dig CH TXT version.bind @<IP>
# Zone transfer (highest-value check)
dig axfr <DOMAIN> @<IP>
host -t axfr <DOMAIN> <IP>
# Basic record queries
dig ns <DOMAIN> @<IP>
dig mx <DOMAIN> @<IP>
dig txt <DOMAIN> @<IP>
dig soa <DOMAIN> @<IP>
dig any <DOMAIN> @<IP> # RFC 8482 denies this why? https://blog.cloudflare.com/rfc8482-saying-goodbye-to-any/
dig aaaa <DOMAIN> @<IP>
dig -x <IP> @<IP>
# Subdomain enumeration
dnsenum --dnsserver <IP> --enum -f <WORDLIST> <DOMAIN>
gobuster dns -d <DOMAIN> -w <WORDLIST> -r <IP> -t 50
fierce --domain <DOMAIN> --dns-servers <IP>
subfinder -d <DOMAIN>
dnsx -d <DOMAIN> -w <WORDLIST>
# SRV records (Active Directory)
dig srv _ldap._tcp.dc._msdcs.<DOMAIN> @<IP>
dig srv _kerberos._tcp.<DOMAIN> @<IP>
dig srv _gc._tcp.<DOMAIN> @<IP>
# Cache snooping (non-recursive)
dig +norecurse <DOMAIN> @<IP>
# Open resolver / recursion check
dig google.com @<IP>
nmap --script dns-recursion -p53 <IP>Methodology
Phase 1: Identify and Fingerprint
Ask youself
- What DNS server software and version is running, and does it map to a CVE?
- Is the service answering on UDP, TCP, or both and does that constrain AXFR?
- Is this an AD-integrated DNS server (i.e. a domain controller)?
- Is the version string real, or a deliberately faked value (itself a hardening signal)?
# Service + version detection on both transports
nmap -sV -sC -p53 <IP>
nmap -sU -sV -p53 <IP>
# Version via CHAOS class DNS has no banner (can be faked)
dig CH TXT version.bind @<IP>
dig CH TXT version.server @<IP>-
nmap -sV -sC -p53 <IP>detect server software and version. -
nmap -sU -sV -p53 <IP>confirm UDP 53 is open. Standard queries use UDP; TCP is reserved for zone transfers and oversized responses. A TCP-only DNS server is unusual and worth noting. -
dig CH TXT version.bind @<IP>extract BIND version via the CHAOS class;version.servercovers PowerDNS/Knot/NSD. Many admins forget to disable this, and the version maps directly to known CVEs. -
searchsploit <server>and Google<server> <version> exploitBIND has a long history of remote DoS and occasional RCE bugs. - If the target is a domain controller, AD-integrated DNS leaks the entire domain layout via SRV records jump to Phase 5 immediately.
DNS has no “banner” like FTP or SMTP. The version lives in a special bind/CHAOS namespace queried via dig CH TXT version.bind. A faked version string is itself a fingerprint someone configured it deliberately, suggesting a hardened deployment.
Phase 2: Zone Transfer (AXFR)
Ask youself
- Does the primary nameserver allow AXFR from my IP?
- Are there secondary nameservers with looser, forgotten transfer ACLs?
- Do common internal zone names (
internal.,dev.,corp.) resolve and transfer? - If AXFR is blocked, does IXFR slip through a less-protected path?
- What does a successful dump tell me to prioritize next?
# AXFR against the primary, then every NS
dig axfr <DOMAIN> @<IP>
for ns in $(dig ns <DOMAIN> +short); do echo "=== $ns ==="; dig axfr <DOMAIN> @$ns; done
# Common internal zone names
for z in internal dev staging admin test corp dmz intranet; do
echo "=== $z.<DOMAIN> ==="; dig axfr $z.<DOMAIN> @<IP>
done
# Incremental transfer do sometimes works when AXFR is blocked
dig ixfr=<SERIAL> <DOMAIN> @<IP>-
dig axfr <DOMAIN> @<IP>attempt the transfer on the primary. A misconfiguredallow-transferdumps the entire zone — the most valuable artifact in DNS recon. -
dig axfr <DOMAIN> @<NS_SERVER>against each NS record. Zone transfer ACLs are per-server; secondaries are frequently misconfigured even when the primary is locked down. - Try common internal zone names with the loop above
internal,dev,staging,admin,test,corp,dmz. -
dig ixfr=<SERIAL> <DOMAIN> @<IP>incremental transfer may leak recent changes when servers protect AXFR but forget IXFR. - On success: save the output, extract every hostname and IP, and prioritize internal-only names (
internal.*,dev.*,db.*,dc.*,vpn.*). This is your network map.
Phase 3: Record Enumeration
Ask youself
- Which nameservers, mail servers, and TXT entries does the zone expose?
- Does the SOA
RNAMEfield hand me an admin email (a spray-able username)? - Are there AAAA (IPv6) records that bypass IPv4 firewall rules?
- What hosts appear on reverse lookups that the forward zone omits?
# Core records
dig ns <DOMAIN> @<IP>
dig mx <DOMAIN> @<IP>
dig txt <DOMAIN> @<IP>
dig soa <DOMAIN> @<IP>
dig any <DOMAIN> @<IP>
dig aaaa <DOMAIN> @<IP>
# Reverse lookups (single + /24 sweep)
dig -x <IP> @<IP>
for i in $(seq 1 254); do dig -x <SUBNET>.$i @<IP> +short; done | grep -v "^$"-
dig ns <DOMAIN> @<IP>list nameservers; try AXFR against each. -
dig mx <DOMAIN> @<IP>mail servers; feed into SMTP enumeration → SMTP-25,587,465. -
dig txt <DOMAIN> @<IP>SPF/DKIM/DMARC and verification tokens; occasionally leak API keys or internal hostnames. -
dig soa <DOMAIN> @<IP>theRNAMEfield is the zone admin email with.replacing the first@(soadmin.example.com=admin@example.com). Add this username to every spray list. -
dig aaaa <DOMAIN> @<IP>anddig -x <IP> @<IP>IPv6 records are often unfiltered; reverse sweeps reveal infrastructure hosts missing from the forward zone.
Phase 4: Subdomain Enumeration
Ask youself
- Which subdomains exist that direct queries and AXFR did not reveal?
- Is my wordlist large enough, or do sparse results justify escalating?
- Are there vhost-based sites that only respond to the right
Hostheader? - Which discovered host is the softest target for a first foothold?
# Brute force against the authoritative server
gobuster dns -d <DOMAIN> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -r <IP> -t 50
dnsenum --dnsserver <IP> --enum -f /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt <DOMAIN>
# Passive + active resolution
subfinder -d <DOMAIN>
dnsx -d <DOMAIN> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
fierce --domain <DOMAIN> --dns-servers <IP>-
gobuster dns -d <DOMAIN> -w <WORDLIST> -r <IP> -t 50fast brute force, the workhorse for subdomain discovery. -
dnsenum --dnsserver <IP> --enum -f <WORDLIST> <DOMAIN>combines AXFR attempts, brute force, and reverse lookups in one run. -
subfinder -d <DOMAIN>anddnsx -d <DOMAIN> -w <WORDLIST>passive sources plus fast active resolution catch names brute force alone misse - If results are sparse, escalate wordlists:
subdomains-top1million-110000.txt,dns-Jhaddix.txt,bitquark-subdomains-top100000.txt. - Add every discovered subdomain to
/etc/hosts. Vhost-based sites serve different content perHostheader, so IP scans alone miss them.
When picking a first target among discovered hosts, CI/CD and dev infrastructure (jenkins., gitlab., dev., staging.) usually win they run weaker security, expose default consoles, and frequently leak source code or hardcoded credentials. The lowest-security host is the fastest foothold.
Phase 5: Active Directory DNS Enumeration
Ask youself
- Where are the domain controllers, KDCs, and Global Catalog servers?
- Does AD-integrated DNS expose the full service topology via SRV records?
- Which DC IPs should I feed straight into LDAP/SMB/Kerberos enum?
- Is email spoofing in scope (DMARC policy present or absent)?
# Locate DCs, KDCs, GC servers via SRV records
dig srv _ldap._tcp.dc._msdcs.<DOMAIN> @<IP>
dig srv _kerberos._tcp.<DOMAIN> @<IP>
dig srv _gc._tcp.<DOMAIN> @<IP>
# Enumerate all common AD SRV records at once
for srv in _ldap._tcp _kerberos._tcp _gc._tcp _kpasswd._tcp _ldap._tcp.dc._msdcs; do
echo "=== $srv.<DOMAIN> ==="; dig srv $srv.<DOMAIN> @<IP> +short
done-
dig srv _ldap._tcp.dc._msdcs.<DOMAIN> @<IP>find domain controllers; every AD-joined client uses this query to locate a DC. -
dig srv _kerberos._tcp.<DOMAIN> @<IP>find KDCs (usually the same hosts as the DCs). -
dig srv _gc._tcp.<DOMAIN> @<IP>Global Catalog servers expose forest-wide LDAP on port 3268. -
dig srv _kpasswd._tcp.<DOMAIN>and_sip._tcp.<DOMAIN>password-change servers and VoIP systems (often underprotected, sometimes sharing AD creds). - Feed DC IPs into LDAP/SMB/Kerberos enum → SMB. SRV records reveal this topology with zero credentials.
Phase 6: Cache Snooping and Recursion
Ask youself
- Is the resolver recursive/open, enabling tunneling and amplification?
- Which external domains have internal users queried recently (cache contents)?
- Does cache data reveal internal SaaS apps that might share AD credentials?
- Is DNSSEC absent, widening the cache-poisoning window?
# Open resolver / recursion check
dig google.com @<IP>
nmap --script dns-recursion -p53 <IP>
# Cache snooping non-recursive query returns only cached answers
dig +norecurse <DOMAIN> @<IP>
nmap --script dns-cache-snoop -p53 <IP>
# DNSSEC presence
dig +dnssec <DOMAIN> @<IP>-
dig google.com @<IP>if the server resolves external domains for you, it is an open resolver, exploitable for amplification, poisoning, and tunneling egress. -
dig +norecurse <DOMAIN> @<IP>a cached answer means the domain was queried recently by someone on the network;nmap --script dns-cache-snoopautomates this across a list. - Use cache contents to fingerprint internal services and SaaS apps for targeted phishing or credential-reuse hunting.
-
dig +dnssec <DOMAIN> @<IP>absent DNSSEC makes cache poisoning theoretically viable on a vulnerable resolver; document it.
Move to Phase 7 to formalize the remaining misconfiguration findings for the report.
Phase 7: Misconfiguration Checks
Ask youself
- Is the resolver open to the world, and is recursion exposed externally?
- Does the absence of SPF/DMARC make email spoofing a valid finding?
- Is AXFR blocked at the firewall (TCP 53 closed) versus at the server config?
- Which of these issues is high enough impact to call out explicitly?
# Recursion / open resolver
nmap --script dns-recursion -p53 <IP>
dig google.com @<IP>
# Spoofing posture (no SPF/DMARC = spoofable)
dig txt <DOMAIN> @<IP>
dig _dmarc.<DOMAIN> txt @<IP>
# Is AXFR even reachable? (TCP 53 must be open)
nmap -p53 <IP>-
nmap --script dns-recursion -p53 <IP>/dig google.com @<IP>confirm open-resolver status for the report and for potential tunneling. -
dig _dmarc.<DOMAIN> txt @<IP>anddig txtno SPF/DMARC means email spoofing is possible; high-impact in social-engineering scope. - Check whether TCP 53 is reachable if only UDP is exposed, zone transfers are blocked at the firewall regardless of server config, so a failed AXFR earlier may be a network control rather than a hardened ACL.
- Document version disclosure, open recursion, missing DNSSEC, and spoofable mail as discrete findings with evidence.
Quiz
You run dig axfr against the primary nameserver and get 'Transfer failed.' What's the next move before giving up on AXFR?
Overview
DNS resolves domain names to IP addresses through a distributed hierarchical system. It is the foundation of every network and the most fundamental protocol for recon both because it is almost always exposed and because it leaks more about a target’s internal structure than any other service.
Server Types
| Type | Description | Pentest Relevance |
|---|---|---|
| Authoritative NS | Holds zone data, answers definitively for owned zones | Zone transfer target |
| Recursive Resolver | Resolves queries on behalf of clients by walking the DNS tree | Cache snooping, open resolver abuse |
| Forwarding Server | Forwards queries to an upstream DNS instead of resolving itself | May reveal upstream infrastructure |
| Caching Server | Stores responses for the TTL duration | Cache snooping for recon |
DNS Record Types
| Record | Description | Pentest Value |
|---|---|---|
A | IPv4 address | Host discovery |
AAAA | IPv6 address | Often unfiltered by firewall rules |
NS | Nameservers for the zone | Zone transfer targets |
MX | Mail servers (with priority) | SMTP enumeration → SMTP-25,587,465 |
TXT | SPF, DKIM, DMARC, verification tokens | Email spoofing assessment, occasionally leaks API keys |
CNAME | Alias to another domain | Subdomain takeover if target is dangling |
PTR | Reverse lookup (IP → hostname) | Host discovery from IPs |
SOA | Zone admin email, serial, timers | Username enumeration from admin email |
SRV | Service location (port, host, priority) | AD enumeration DCs, KDCs, GC servers |
HINFO | Host hardware/OS info | Rarely populated, but free info if present |
Quick Reference
| Task | Command |
|---|---|
| Basic lookup | dig <DOMAIN> @<IP> |
| All records | dig any <DOMAIN> @<IP> |
| Nameservers | dig ns <DOMAIN> @<IP> |
| Mail servers | dig mx <DOMAIN> @<IP> |
| TXT records | dig txt <DOMAIN> @<IP> |
| SOA record | dig soa <DOMAIN> @<IP> |
| IPv6 records | dig aaaa <DOMAIN> @<IP> |
| Zone transfer | dig axfr <DOMAIN> @<IP> |
| Reverse lookup | dig -x <IP> @<IP> |
| BIND version | dig CH TXT version.bind @<IP> |
| Short output | dig +short <DOMAIN> @<IP> |
| Cache snoop | dig +norecurse <DOMAIN> @<IP> |
DIG Deep Dive
dig is the default DNS query tool on every Linux pentest distro. It supports every record type, every transport (UDP, TCP, DoT, DoH), and produces parseable output. Learn it well it replaces nslookup for almost every situation.
# Standard query with full output
dig <DOMAIN> @<IP>
# Short output (just the answer)
dig +short <DOMAIN> @<IP>
# Query specific record types
dig ns <DOMAIN> @<IP>
dig mx <DOMAIN> @<IP>
dig txt <DOMAIN> @<IP>
dig soa <DOMAIN> @<IP>
dig any <DOMAIN> @<IP>
dig aaaa <DOMAIN> @<IP>
dig srv _ldap._tcp.<DOMAIN> @<IP>
# Reverse lookup
dig -x <IP> @<IP>
# BIND version (CHAOS class)
dig CH TXT version.bind @<IP>
dig CH TXT version.server @<IP>
# Zone transfer
dig axfr <DOMAIN> @<IP>
# Incremental zone transfer (may work when AXFR is blocked)
dig ixfr=<SERIAL> <DOMAIN> @<IP>
# Cache snooping (non-recursive only returns cached results)
dig +norecurse <DOMAIN> @<IP>
# Trace query path (shows full resolution chain)
dig +trace <DOMAIN>
# DNSSEC check
dig +dnssec <DOMAIN> @<IP>nslookup (Interactive Mode)
Useful when dig is not available Windows hosts, minimal Linux installs, or compromised servers without package managers. Interactive mode lets you switch query types without retyping the server address.
nslookup
> server <IP>
> set type=any
> <DOMAIN>
> set type=ns
> <DOMAIN>
> set type=mx
> <DOMAIN>
> set type=srv
> _ldap._tcp.dc._msdcs.<DOMAIN>:: Windows query specific DNS server
nslookup <DOMAIN> <IP>
nslookup -type=any <DOMAIN> <IP>
nslookup -type=srv _ldap._tcp.dc._msdcs.<DOMAIN> <IP>Zone Transfers (AXFR)
Zone transfers replicate an entire DNS zone between servers. They exist so secondary nameservers can sync from a primary, but if allow-transfer is misconfigured to allow any IP, you receive a complete dump of every record in the zone — hostnames, IPs, mail servers, SRV records, TXT comments. It is the single most valuable misconfiguration in DNS.
# Attempt zone transfer
dig axfr <DOMAIN> @<IP>
# Using host command
host -t axfr <DOMAIN> <IP>
# Try all discovered nameservers
for ns in $(dig ns <DOMAIN> +short); do
echo "=== Trying AXFR on $ns ===" && dig axfr <DOMAIN> @$ns
done
# Try common internal zone names
for zone in internal dev staging admin test corp dmz intranet; do
echo "=== Trying $zone.<DOMAIN> ===" && dig axfr $zone.<DOMAIN> @<IP>
doneOPSEC: Zone transfers are logged by every modern DNS server. A failed AXFR attempt is conspicuous in DNS logs and frequently triggers detection rules in mature SOCs. In a real engagement, one attempt per nameserver is enough do not loop AXFR queries against every guessed zone name from a noisy IP.
Subdomain Enumeration
Gobuster DNS
# Fast subdomain brute force
gobuster dns -d <DOMAIN> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt -r <IP> -t 50
# Larger wordlist for thorough scan
gobuster dns -d <DOMAIN> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-20000.txt -r <IP> -t 50gobuster dns is the fastest pure brute force tool. Use the 5k wordlist for a quick first pass, then escalate to 20k or 110k if results are sparse.
DNSenum
# Full enumeration: zone transfer + brute force + reverse lookups
dnsenum --dnsserver <IP> --enum -p 0 -s 0 \
-o subdomains.txt \
-f /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt \
<DOMAIN>dnsenum runs everything in one shot: AXFR attempt, A/MX/NS/SOA queries, brute force, and reverse lookups on adjacent IPs. The -p 0 -s 0 flags disable Google scraping, which is rate-limited and rarely useful in labs.
subfinder and dnsx (ProjectDiscovery)
# Passive subdomain discovery from many sources
subfinder -d <DOMAIN> -o subs.txt
# Resolve / brute force with dnsx
dnsx -d <DOMAIN> -w /usr/share/seclists/Discovery/DNS/subdomains-top1million-5000.txt
cat subs.txt | dnsx -respFierce
# Automated recon: zone transfer attempt + brute force + reverse lookups
fierce --domain <DOMAIN> --dns-servers <IP>fierce is older but still valuable — it expands brute force results with reverse lookups on adjacent IPs, often catching hosts the wordlist missed.
Reverse Lookup Sweep
# Discover hostnames for a subnet
for i in $(seq 1 254); do
result=$(dig -x <SUBNET>.$i @<IP> +short)
[ -n "$result" ] && echo "<SUBNET>.$i => $result"
done | tee reverse_lookups.txtReverse lookup sweeps reveal hosts that are not in the forward zone but still have PTR records — typically infrastructure devices, monitoring systems, and forgotten servers.
Recommended Wordlists
| Wordlist | Size | Use Case |
|---|---|---|
subdomains-top1million-5000.txt | 5k | Quick first pass |
subdomains-top1million-20000.txt | 20k | Standard enumeration |
subdomains-top1million-110000.txt | 110k | Thorough enumeration |
dns-Jhaddix.txt | ~2M | Exhaustive (slow, use only when needed) |
bitquark-subdomains-top100000.txt | 100k | Alternative comprehensive list |
Nmap DNS Scripts
Nmap’s NSE engine ships with a full set of DNS scripts that automate the most common checks. Run them in parallel with dig enumeration they are fast and free.
# All DNS scripts
nmap --script "dns-*" -p53 <IP>| Script | Purpose |
|---|---|
dns-zone-transfer | Attempt AXFR |
dns-brute | Subdomain brute force |
dns-cache-snoop | Reveal cached queries (what users are browsing) |
dns-recursion | Check if server is an open resolver |
dns-nsid | Get nameserver ID |
dns-service-discovery | Find services via DNS-SD |
dns-srv-enum | Enumerate SRV records |
DNS Attacks
Subdomain Takeover
If a CNAME record points to an external service (AWS S3, GitHub Pages, Heroku, Azure) and that service is no longer claimed, you can register the dangling resource to control the subdomain. Anyone visiting subdomain.target.com then lands on your content — perfect for phishing and bypass of CSP/CORS restrictions tied to the parent domain.
# Find dangling CNAMEs
dig cname <SUBDOMAIN>.<DOMAIN> @<IP>
# If it points to something like *.s3.amazonaws.com, *.herokuapp.com, *.github.io
# and the resource returns 404 / "NoSuchBucket" potential takeoverDNS Cache Poisoning
Inject false records into a resolver’s cache to redirect traffic. Modern resolvers are well-protected against the classic Kaminsky attack (random source ports, random transaction IDs), but the absence of DNSSEC widens the window. Rarely exploitable on the exam, but flag DNSSEC absence in the report.
BIND9 Configuration Reference
When you compromise a DNS server (or read its config via LFI), these are the files and settings that matter.
Config files (Linux):
/etc/bind/named.confmain configuration/etc/bind/named.conf.localzone definitions/etc/bind/named.conf.optionsglobal options (recursion, forwarders, transfer ACLs)/etc/bind/db.<DOMAIN>zone file/var/log/named/DNS logs
Zone File Structure
$ORIGIN <DOMAIN>.
$TTL 86400
@ IN SOA ns1.<DOMAIN>. admin.<DOMAIN>. (
2024010101 ; serial
21600 ; refresh (6 hours)
3600 ; retry (1 hour)
604800 ; expire (1 week)
86400 ) ; minimum TTL (1 day)
IN NS ns1.<DOMAIN>.
IN NS ns2.<DOMAIN>.
IN MX 10 mail.<DOMAIN>.
IN A 10.10.1.5
www IN CNAME @
ftp IN A 10.10.1.10
mail IN A 10.10.1.20
dc01 IN A 10.10.1.2Dangerous Settings
| Setting | Risk |
|---|---|
allow-transfer { any; }; | Zone transfer to anyone full domain dump |
allow-query { any; }; | Anyone can query information disclosure |
allow-recursion { any; }; | Open resolver DNS amplification, cache poisoning, tunneling |
version "9.x.x"; | Version disclosure targeted exploits |
allow-update { any; }; | Dynamic DNS updates inject arbitrary records |
dnssec-validation no; | DNSSEC disabled cache poisoning viable |
Common Mistakes
- Only attacking the primary nameserver AXFR ACLs are per-server; the forgotten secondary is usually the one that allows the transfer. Always enumerate NS records and try each.
- Forgetting UDP
nmap -sU -p53matters; a server answering only TCP (or only UDP) changes whether AXFR is even possible. - Ignoring the SOA admin email the
RNAMEfield is a free, often-privileged username for spraying. Add it to every list. - Not adding discovered hosts to
/etc/hostsvhost-based sites only respond to the correctHostheader, so IP-only scans miss them entirely. - Looping noisy AXFR/brute force from one IP zone transfers and large brute runs are logged and alerted; pace them and prefer one attempt per NS.
- Skipping SRV records on a DC AD-integrated DNS hands you the entire domain topology with zero credentials; never enumerate AD by hand when SRV records exist.
Quiz
You pulled 50+ hostnames from a successful zone transfer: dc01, dc02, sql01, jenkins, gitlab-internal, vpn, and dozens of generic app servers. You have no credentials yet. Where do you focus next?
#PenetrationTesting #Linux #RedTeam #Certification #DNS #AXFR #ZoneTransfer #SubdomainEnum #ActiveDirectory #ServiceEnum #Recon #BIND #Gobuster #Nmap #OSINT