DNS Zone Transfer (AXFR) Recon for Bug Bounty Hunters
AXFR is the blunt instrument of DNS recon. Ask a name server for the whole zone; if it answers, you get hostnames, mail exchangers, and sometimes internal naming schemes the marketing site never linked.
Most public authoritative servers refuse transfers. The wins are misconfigured secondaries, forgotten lab NS records, and corporate DNS appliances left open on VPN-adjacent networks that still sit in scope.
Enumerate NS, then ask politely
Resolve NS for the apex and for interesting subdomains. Transfer permission is per server, not per domain label you happen to like.
dig NS target.example +short
dig AXFR target.example @ns1.target.example
Try every NS hostname, including ones that resolve to unexpected ranges. I've watched apex NS refuse AXFR while ns-legacy.corp.target.example dumped the zone. Also try the zone name with and without trailing dot, and child zones discovered from NS delegations in the parent.
IXFR with a serial of 0 sometimes behaves differently on broken stacks. If AXFR fails cleanly with REFUSED, do not hammer. Note the refusal and move to passive DNS.
Reading a dump without overselling
A successful transfer is recon, not remote code execution. Triage wants:
- Confirmation the NS is in scope (or the program accepts DNS findings for the brand)
- A sample of sensitive names:
staging,vpn,jira,localhostaliases, RFC1918 glue, old product hosts - Proof you did not need credentials beyond public DNS
Do not paste the entire zone into the report. Summarize counts, highlight high-value records, and attach a redacted excerpt. Customer or employee personal names in PTR-like naming deserve careful handling under the program's data rules.
TXT records may hold SPF, verification tokens, or leftovers from migrations. SRV records point at SIP, LDAP, and Minecraft-for-some-reason. Map them; do not connect to every port on day one.
When AXFR is closed
Closed AXFR is normal. Continue with certificate transparency, search engine dorks, and brute force under rate limits. Zone walking via NSEC/NSEC3 is a different technique—mention it only if you actually walked it.
Some "transfers" you see in writeups were actually large ANY responses or provider APIs. Say AXFR only when the opcode and answer section match a zone transfer.
Compare SOA serials across NS hosts. If one secondary is weeks behind, dig into why—stale secondaries sometimes keep looser ACLs from an older ops era. That alone is not a bounty, but it tells you which server deserves a second look.
Scope and manners
Many VDP policies welcome DNS misconfiguration reports. Some ignore them as informational. Ask whether the open transfer exposes internal hostnames not already public. That framing beats "AXFR works" as a one-liner.
Recommend restricting AXFR to explicit secondary IPs with TSIG, removing forgotten NS hosts, and splitting public and internal zones so a public secondary cannot serve intranet names.
Run the transfer once or twice for proof. Repeated full-zone pulls against a production NS look like abuse, not research.