Skip to main content
Default Port: 53 (TCP and UDP) DNS is often treated as background infrastructure, but it’s one of the richest sources of passive recon on an engagement: subdomains, internal hostnames, mail servers, and occasionally entire zone files, all reachable without touching the actual target application. A surprising number of DNS servers are still misconfigured in ways that hand over far more than they should.

Standard Queries

Asking a resolver for specific records, one at a time. Normal, expected DNS traffic that any client generates.

Zone Transfer (AXFR)

Requesting the entire zone file in one go, meant only for secondary nameservers. When misconfigured to allow anyone, it leaks the whole internal DNS map at once.
Always test for an open zone transfer before doing anything else. It’s a single command, and a successful one can replace an entire subdomain enumeration effort.

​
DNS Record Types

Knowing what each record type actually represents is what turns a wall of dig output into useful intelligence rather than noise.
RecordDescription
AMaps a hostname to an IPv4 address
AAAAMaps a hostname to an IPv6 address
CNAMEAlias pointing one hostname to another
MXMail server(s) responsible for the domain
NSAuthoritative nameservers for the domain
TXTFree-form text, often SPF/DKIM records or domain verification strings
SOAAuthority info: primary nameserver, admin contact, zone serial number
PTRReverse mapping from an IP address back to a hostname
SRVService location records, e.g. pointing to AD domain controllers

​
Basic Lookups

Querying a specific record type against a specific nameserver is where dig becomes genuinely useful rather than just a fancier host:
Reverse lookups go the other direction, IP to hostname, which can reveal internal naming conventions even from a single result:
Querying the server’s own version directly sometimes works and can point straight at a known CVE if the software is outdated:

​
Zone Transfers (AXFR)

A zone transfer is meant to replicate the full DNS zone from a primary to a secondary nameserver. If a server doesn’t restrict who can request one, anyone asking gets the entire zone file back: every A record, every subdomain, every internal hostname the domain has defined.
fierce automates a broader recon pass that checks for open zone transfers as part of its normal workflow, rather than needing to test it manually against every nameserver:
A successful AXFR is a serious misconfiguration finding on its own, it exposes the domain’s entire internal structure. Report it even if nothing else comes from it directly.

​
Subdomain Enumeration

When a zone transfer isn’t open, brute-forcing subdomains against a wordlist is the fallback. A few tools each take a slightly different approach.
subfinder pulls from passive sources (certificate transparency logs, search engines, public datasets) instead of brute-forcing directly, which is faster and generates no traffic against the target’s own DNS infrastructure at all:
subbrute resolves a wordlist through a specific resolver list, useful when you want brute-forcing but through your own trusted resolvers rather than the target’s:
dnsdumpster.com runs a lot of this passively through a web UI and is worth checking first, it’s free, requires no setup, and often surfaces subdomains and hosting providers in seconds.

​
Reconnaissance Shortcuts

A couple of quick wins worth checking alongside the standard enumeration above.
The SOA record’s admin contact field often leaks an internal email address or naming convention, and the serial number can hint at how frequently the zone changes.
dnsrecon bundles standard lookups, zone transfer testing, and brute-forcing into a single pass, a reasonable one-command starting point before reaching for the more specialized tools above.

​
DNS Poisoning (Local Network)

This actively intercepts and redirects live traffic for other users on the network. It’s a disruptive, high-impact technique, confirm scope explicitly covers it before running it.
DNS spoofing on a local network answers a victim’s DNS query before the real server can, redirecting them to an attacker-controlled IP instead. ettercap bundles this into a plugin rather than needing a custom responder.
1

Define the spoofed records

Edit ettercap’s DNS config file to map the target domain to your IP:
2

Scan for hosts

Launch ettercap, then go to Hosts → Scan for Hosts to find live targets on the network.
3

Set the targets

Add the victim’s IP as Target1 and the default gateway’s IP as Target2, positioning yourself for a man-in-the-middle between the two.
4

Enable DNS spoofing

Go to Plugins → Manage Plugins and activate dns_spoof. From here, any DNS query from the victim matching your configured domains resolves to your IP instead of the real one.

​
Subdomain Takeover

When a subdomain’s DNS record (usually a CNAME) still points to a third-party service, like a cloud platform or SaaS product, that’s no longer claimed, registering that resource on the provider’s side lets you serve content from the victim’s own subdomain.
A CNAME pointing to an unclaimed GitHub Pages site, an unused S3 bucket, or a deprovisioned SaaS app are all classic signs worth following up on manually.
can-i-take-over-xyz catalogs which services are currently vulnerable to takeover and the exact fingerprint to look for in each case, essential reference once you’ve found a dangling CNAME.

​
Quick Reference Tools

Hackviser: DNS

Quick-reference pentesting guide for the DNS service.

HackTricks: DNS

Deeper breakdown of DNS enumeration and attack techniques.

dnsdumpster.com

Free passive DNS reconnaissance tool, good first stop before active enumeration.

can-i-take-over-xyz

Reference for identifying subdomain takeover vulnerabilities by service.
DNS spoofing and aggressive zone brute-forcing both generate significant, easily noticed traffic. Confirm scope and rules of engagement before running either against a live target.