Reconnaissance

DNS subdomain enumeration: 1,298 misses, two refused transfers

Updated

File
dns-subdomain-enumeration.pcap
Format
pcap, ether
Size
783.05 KB
Packets
5204
Duration
59 s
Captured (UTC)
2026-03-07 08:59:22
SHA-256
f957abc9df683ca437ddabf6db5719274cdf633b25a0374991f28c5ce5b37a8d
Source
A-Packets lab capture
Built
trimmed to the lookups of the enumerated domain

In 59 seconds one client asks its resolver about 1,301 names under forgewize.llc, and 1,298 of them do not exist; along the way it asks two authoritative servers for the whole zone and is refused both times. This DNS enumeration PCAP holds both halves of a thorough subdomain sweep, the dictionary brute force and the zone-transfer shortcut. Before an attacker touches a target, they map it, and DNS is where the mapping often starts. A-Packets groups the queries by client and server and counts the failures, so the brute-force pattern is obvious at a glance.

Subdomain enumeration is reconnaissance that maps an organisation's external footprint without ever touching its hosts, which is what makes it both common and easy to overlook. The signature it leaves in DNS, though, is distinctive. The capture is an authorized run in the A-Packets lab, trimmed to the lookups of the enumerated domain.

DNS view of the DNS enumeration PCAP in A-Packets. The DNS details show queried names under forgewize.llc with Non-Existent Domain markers, rather than the summary chart.
The DNS details show queried names under forgewize.llc with Non-Existent Domain markers, rather than the summary chart.

The signature: many names, one domain, mostly failing

An enumeration tool works through a wordlist of candidate hostnames, www, mail, dev, vpn, staging and thousands more, asking DNS whether each exists under the target domain. Most do not, so most lookups return NXDOMAIN, the "non-existent domain" answer, and only a few hit real records. That ratio is the fingerprint, and A-Packets counts both halves of it.

DNS enumeration count comparison: 1,298 missing names produce 2,596 NXDOMAIN replies; two zone transfers are refused and four replies have no error.
DNS enumeration count comparison: 1,298 missing names produce 2,596 NXDOMAIN replies; two zone transfers are refused and four replies have no error.
forgewize.llc 1303

The view groups the queries by client and server: 1,301 names in the conversation with the resolver, plus the apex once more in each of the two authoritative-server groups, 1,303 entries in all. Counted by packet, the sweep is 1,301 A queries, 1,298 AAAA queries, one MX query and two AXFR requests, and every one is answered: four NOERROR replies, 2,596 NXDOMAIN and two REFUSED. The NXDOMAIN count is double the 1,298 missing names because each name was tried for both address families, so counting negative packets as missing hosts would double the size of the sweep.

The zone transfer: the shortcut that skips the brute force

Alongside the brute force, the capture contains AXFR requests, the DNS zone-transfer query, sent to the domain's authoritative servers. A zone transfer is the mechanism a primary DNS server uses to hand a complete copy of a zone to its secondaries, every record at once. If a server is misconfigured to answer an AXFR from anyone, an attacker skips the entire wordlist and simply asks for the whole zone, receiving every record in it in one response sequence. It is the difference between guessing names one at a time and being handed the list.

Here frames 9 and 11 carry the two AXFR questions for the apex over separate TCP streams, and frames 10 and 12 answer with response code 5, REFUSED, and no records: both authoritative servers turned this client away, as a server that answers AXFR only to its known secondaries should. That refusal is worth confirming on your own servers, because a successful AXFR is one of the most complete pieces of reconnaissance an attacker can obtain without any exploitation at all. The attempt next to the brute-force queries also tells the defender this was a deliberate enumeration, not stray traffic: the transfer queries come early, before most of the dictionary sweep.

Why DNS reconnaissance is so hard to stop at the source

The uncomfortable truth of subdomain enumeration is that much of it happens without ever querying your servers. Certificate transparency logs, passive DNS databases and search engines already hold large portions of most organisations' subdomains, so an attacker can enumerate from public sources silently. The active brute force in this capture is the part that touches your infrastructure and therefore the part you can see, which is why catching it matters: it is often the point where a quiet reconnaissance phase becomes visible to the defender for the first time.

What the record types and timing add

Beyond the volume and the failure ratio, two more details sharpen the picture. The record types the client asks for are a hint: a sweep that asks only for address records is checking which names resolve, while one that also asks for MX, TXT, SRV or NS records is profiling the services behind the domain. This one asks for A and AAAA for every candidate, one MX for the apex and the two transfers, and it learns little: only the apex, autodiscover and mail resolve, plus the apex's mail route. The timing matters too: enumeration tools fire queries far faster and more regularly than a human or a normal application, so a steady high rate from one source to one domain is itself anomalous even before you count the failures.

Detectors also need the answer codes kept apart. NXDOMAIN means the name does not exist, while NOERROR with no records, often called NODATA, means the name exists without that record type; SERVFAIL points to a broken resolution path and REFUSED to policy, as the DNS negative-response rules define. A resolver failing across many unrelated domains is an outage; thousands of NXDOMAINs under one suffix from one client is a sweep. This is where resolver telemetry beats a single capture for ongoing defence: a resolver that logs every query lets you alert on the pattern continuously, catch slow enumerations spread over hours, and see which internal clients generate lookups they should not. The capture teaches you what the pattern looks like so you can write the resolver-side detection that catches it at scale.

Reducing the footprint and catching the enumeration

The defensive response is twofold. First, refuse zone transfers to anyone but your designated secondary servers, and verify the configuration rather than assuming it, since an open AXFR hands away the whole zone. Second, treat a burst of failing lookups for one domain from a single source as the signal it is, worth logging at the resolver and rate limiting. Watch at the resolver rather than the authoritative server: the resolver still sees the original client, while an authoritative server sees only shared recursive resolvers, with negative caching thinning out the count. Beyond detection, review what the names that did resolve actually expose: every real subdomain an attacker learns is a host they now know to target, so retiring stale DNS records and securing development and staging systems reduces the value of the sweep. A hidden hostname is not an access control.

The DNS view shows the pattern: which client queried which domain and how many lookups failed. The records each answer carried are in the capture, for Wireshark or your resolver logs. In MITRE ATT&CK terms this is T1590.002, Gather Victim Network Information by DNS, and T1595 active scanning; the zone-transfer attempt is the discovery technique T1590 taken to its most efficient form.

For reading DNS, mDNS and NBNS traffic in general, see DNS, mDNS and NBNS traffic analysis in a PCAP, and compare the iodine DNS tunnel, a completely different abuse of the same protocol where DNS is used to carry data rather than to map names. To analyze a capture from your own network, upload a PCAP.

More sample reports