You cannot enumerate a zone
The gotcha that catches every tech once: dig ANY is neutered, AXFR is closed, and there is no public way to dump every record. The calibrated answer when a client says "send me all the records".
Every helpdesk tech eventually runs dig ANY example.com expecting to see the whole zone, then is confused when nothing useful comes back. They reach for AXFR (transfer the zone to me) and that fails too.
Then a client or senior asks what records are on this domain? and the tech doesn’t have an obvious way to answer.
The honest answer is you cannot enumerate a DNS zone from outside without panel access. The practical workarounds are what to reach for instead.
Why dig ANY doesn’t work anymore
Historically, dig ANY example.com returned everything: A, AAAA, MX, TXT, NS, the lot. Since the early 2010s this has been progressively shut down:
- Public recursive resolvers (Google, Cloudflare, OpenDNS) started returning a synthetic “no records” answer for ANY queries to reduce DNS amplification attacks (where an attacker uses ANY queries to amplify a small request into a large response, flooding a victim).
- Authoritative server software returns minimal responses by default.
- RFC 8482 (2019) standardised the behaviour: ANY queries should return a minimal response.
Today, dig ANY example.com returns a short, minimal response and you cannot rely on it for any practical enumeration.
AXFR is closed (and has been for decades)
AXFR is the protocol mechanism for zone transfer: copying a zone’s full contents from a primary authoritative server to a secondary. For public use, AXFR is firewalled off at virtually every authoritative server. A dig AXFR example.com @ns1.cloudflare.com from a non-secondary returns REFUSED or a connection failure.
You may encounter a misconfigured authoritative server that allows AXFR from anyone. That’s a security finding, not an opportunity. Report it; don’t rely on it.
What you can actually do
Since you cannot ask the authoritative server give me everything, the practical options are:
| Option | When |
|---|---|
| Log into the DNS host’s panel | If you manage the DNS for the client, this is the canonical answer. The panel shows the complete list. |
| Query each record type individually | When you don’t have panel access. Gets you the records at the apex; subdomains require knowing the names in advance. |
| Probe common subdomain names | www, mail, webmail, autodiscover, ftp, vpn, _dmarc, _domainkey selectors, _sip._tls. Catches the standard set; misses anything non-standard. |
Certificate Transparency logs (crt.sh) | Lists every subdomain that has had a cert issued. Approximation of what subdomains exist; misses those that never had a cert. |
| Ask the previous DNS host for a zone export | Standard migration practice. Cloudflare’s “Export DNS records” button, similar at others. |
What this is NOT
- “
dig ANYshows everything.” Used to. Has been progressively shut down across the public DNS infrastructure for over a decade. - “AXFR is for diagnostics.” AXFR is for secondaries to copy zones from primaries. Never intended as a public diagnostic mechanism.
- “Online tools must have a way.” They don’t; they run the same queries you can run.
Decision walkthrough
When you produce a probe-based list and the client asks are you sure that’s everything?, the calibrated reply is: those are the records the standard probe found, plus the subdomains visible in Certificate Transparency. There may be subdomains with non-standard names that don’t have certs. The certain way to get the complete list is direct panel access; we can request access from the previous MSP, or replicate the zone during a migration we control.