Detect Unauthorized DNS Zone Transfer (AXFR) and Bulk Record Enumeration Against Authoritative Nameservers in Elastic Security
Adversaries scoping an external attack surface frequently target the victim's authoritative nameservers directly, attempting a full DNS zone transfer (AXFR, and its incremental sibling IXFR) in the hope of finding a misconfigured 'allow-transfer any' ACL. A successful AXFR dumps every record in the zone in one response — internal hostnames, mail server (MX) and SPF/DKIM/DMARC TXT records revealing third-party SaaS relationships, service discovery (SRV) records, and sometimes internal IP addressing exposed through stale A/PTR entries — handing the adversary a ready-made map of the organization's external and semi-external footprint without a single port scan. When the transfer is refused (the common case on a correctly configured server), adversaries and OSINT/recon tooling such as dnsrecon, fierce, dnsenum, and dig-based scripts fall back to bulk enumeration: rapid, scripted queries across many record types (NS, MX, TXT, SOA, ANY) and many candidate subdomains against the authoritative server itself, rather than a passive third-party database. This detection targets that server-side behavioral signature — AXFR/IXFR requests and abnormal query-type/query-name diversity from a single external client hitting the authoritative nameserver in a short window — as observed in the nameserver's own query and transfer logs, distinct from the OSINT-tool-execution coverage on the T1590.002 technique page, which keys on endpoint process telemetry for the same tools rather than the server-side query pattern. Sandworm Team, APT41, and Magic Hound have all been documented conducting broad DNS and network-infrastructure reconnaissance ahead of infrastructure acquisition and initial-access operations, and the same fingerprint is produced just as often by legitimate DNS hygiene audits, misconfiguration scanners, and unauthorized red-team activity.
MITRE ATT&CK
- Tactic
- Reconnaissance
Elastic Detection Query
dns where dns.question.type : ("AXFR", "IXFR", "252", "251")Elastic EQL filter identifying candidate DNS zone-transfer request events using ECS dns.question.type. EQL has no aggregation functions, so this rule surfaces individual AXFR/IXFR candidate events directly (any hit here from outside the secondary-NS allowlist warrants immediate review); pair it with a companion Kibana Threshold rule bucketing on source.ip with a count aggregation (>=30) and a cardinality aggregation on dns.question.type (>=4) and dns.question.name to reproduce the full bulk-enumeration branch of the KQL/SPL scoring model.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate secondary/slave nameserver replication from documented secondary NS IPs
- Managed DNS or anycast providers pulling zone data via scheduled AXFR from a documented set of provider IPs
- Internal DNS-as-code tooling or configuration-drift auditors performing scheduled AXFR checks against test zones
- Authorized penetration testing or DNS hygiene audits explicitly scoped to probe zone-transfer misconfiguration
Other platforms for THREAT-Recon-DNSZoneTransferReconAttempt
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Simulate External AXFR Zone Transfer Attempt via dig
Expected signal: DNS server query/transfer log entry showing a TCP/53 session and an AXFR-type request for df00tech-zonetransfer-test.internal from the test host; if no authoritative nameserver is listening on 127.0.0.1 the request fails immediately, but the outbound TCP/53 attempt and (on a lab BIND/Windows DNS instance) the query log entry are still generated for detection validation.
- Test 2Simulate Bulk Multi-Type DNS Record Enumeration via Scripted dig Loop
Expected signal: DNS server query log records approximately 40 queries from the test host spanning 8 distinct query types (NS/MX/TXT/SOA/A/AAAA/CNAME/SRV) and 5 distinct subdomain names within a short window.
- Test 3Simulate Bulk ANY-Type Query Sweep via nslookup on Windows
Expected signal: Windows DNS Server analytic log / DnsEvents entries for 12 ANY-type queries from the test host against 12 distinct subdomain names within a short window, ingested via Azure Monitor Agent.
References (7)
Response Playbook
Triage
- Confirm whether the source ClientIP is a documented secondary/slave nameserver authorized for zone replication by cross-checking the zone's NS records and any managed-DNS provider's published transfer-source IP ranges before treating the event as malicious.
- Determine whether the zone transfer actually succeeded rather than being refused — check the nameserver's response/result code for the AXFR/IXFR request. A successful transfer from an unauthorized IP is a confirmed information-disclosure event, not just an attempt.
- If the transfer succeeded, obtain the transferred record set (from the DNS server's own transfer log or a controlled re-query) to scope exactly what was disclosed: internal hostnames, MX/mail infrastructure, SPF/DKIM/DMARC TXT records revealing third-party SaaS usage, SRV records, and any stale internal A/PTR entries.
- Review the QueryTypesSeen/query_types_seen and SampleNames/sample_names fields for the bulk-enumeration branch — a scripted mix of NS, MX, TXT, SOA, and ANY queries across many sequential or wordlist-style subdomains indicates automated tooling (dnsrecon, fierce, dnsenum) rather than a single manual lookup.
- Perform WHOIS, reverse-DNS, and threat-intel reputation lookups (GreyNoise, Shodan, AbuseIPDB, VirusTotal) on the source ClientIP to separate known passive-DNS/OSINT crawler infrastructure from unattributed hosts.
- Check the authoritative nameserver's zone-transfer ACL (the `allow-transfer` directive in BIND, or the Zone Transfer tab in Windows DNS Manager) for a misconfiguration allowing transfers to any client — this is the root cause that makes the technique viable at all and should be remediated independent of attribution.
- Correlate the enumeration or transfer window with subsequent activity — new lookalike-domain registrations, phishing infrastructure, or initial-access attempts against hostnames or IP ranges revealed by the query.
Containment
- If a zone transfer succeeded and the ACL is misconfigured, immediately restrict the transfer ACL on the authoritative nameserver to an explicit allowlist of documented secondary NS IPs — this single fix removes the exposure regardless of who else attempts it.
- Block the offending source IP (and its /24 or ASN, if abuse is repeated) at the firewall in front of the authoritative nameserver, particularly for bulk-enumeration sources not present on the secondary-NS allowlist.
- Enable Response Rate Limiting (RRL) or equivalent query-rate throttling on the authoritative nameserver to blunt further high-volume enumeration while the ACL fix is validated.
- If a successful transfer exposed internal hostnames, service names, or an addressing scheme, treat that disclosure as permanent — plan renaming/re-addressing of sensitive internal assets rather than assuming the information can be withdrawn.
Evidence Collection
- Full DNS server query/transfer log (Windows DNS Server analytic log, or BIND named querylog/xfer-log) for the source ClientIP across the full activity window, including the result code for each AXFR/IXFR request.
- The zone-transfer ACL / allow-transfer configuration for the targeted zone at the time of the incident, to establish whether the transfer should have been refused.
- If the transfer succeeded, a copy of the transferred record set (from the server's transfer log or a controlled re-query) to precisely scope what was disclosed.
- Perimeter firewall or NetFlow session records for the TCP/53 connection used for the transfer — AXFR/IXFR use TCP, unlike the UDP/53 typical of ordinary single-record lookups, which is a useful corroborating signal.
- Threat intelligence enrichment (WHOIS, ASN ownership, reputation classification) for the source ClientIP.
Escalation Criteria
- !A zone transfer actually succeeded against an unauthorized client — this is a confirmed information-disclosure event and should be escalated regardless of the source's attribution or apparent intent.
- !The exposed or enumerated data reveals internal hostnames, IP addressing, or service names for sensitive systems (VPN concentrators, domain controllers, backup infrastructure, dev/staging environments).
- !The same source IP or ASN conducts bulk enumeration or transfer attempts against multiple owned zones/domains, indicating a coordinated reconnaissance campaign rather than a one-off probe.
- !Enumeration or a successful transfer is followed within 24-72 hours by lookalike-domain registration, phishing infrastructure setup, or initial-access/scanning activity targeting the disclosed hostnames or IP ranges.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Windows DNS Server analytic/debug log (DnsEvents via Azure Monitor Agent, or the native dns.log debug output) showing per-query client IP, query type, query name, and result code - >
BIND named query log (querylog) or Infoblox NIOS DNS query audit log for non-Windows authoritative nameservers - >
The zone's transfer ACL configuration (`allow-transfer` in named.conf, or the Zone Transfer tab in Windows DNS Manager) at the time of the incident - >
Perimeter firewall / NetFlow session records for TCP/53 connections to the authoritative nameserver, since AXFR/IXFR use TCP rather than the UDP typical of ordinary lookups - >
Passive DNS history for the affected zone from third-party providers (SecurityTrails, Farsight/DNSDB) to establish whether the exposed record set has already propagated to public archives
Tuning Guidance
Start by building an allowlist of every legitimate zone-transfer source: the IPs of your own secondary/slave nameservers, any managed-DNS or anycast provider's documented transfer-source ranges, and DNS-as-code tooling that performs scheduled AXFR checks against test zones. Suppress all of these on ClientIP before tuning volumetric thresholds further. Keep the zone-transfer branch of this detection effectively zero-tolerance (any AXFR/IXFR from outside the allowlist alerts) since legitimate ad-hoc AXFR from an unlisted IP is rare; reserve threshold tuning (MinBulkQueries, MinUniqueQueryTypes) for the bulk-enumeration branch, where a single engineer troubleshooting mail delivery with a few manual dig/nslookup calls should stay below the 30-query/4-type floor. Note that AXFR and IXFR use TCP/53 rather than the UDP/53 used by ordinary single-record lookups — if your perimeter firewall or NetFlow logs are available, layering a supplemental rule on unexpected inbound TCP/53 sessions to the authoritative nameserver can corroborate or independently surface zone-transfer attempts that DNS server logging alone might miss. Feed confirmed-benign source IPs (secondary NS additions, new managed-DNS provider ranges) back into the allowlist promptly, since DNS infrastructure changes are infrequent but disruptive to this rule's signal-to-noise if left untracked.
Hunting Queries
Hunts for source IPs probing the authoritative nameserver (zone-transfer attempts or multi-type enumeration) across two or more distinct days within a 7-day window, distinguishing a persistent reconnaissance campaign from a single opportunistic probe.
// Hunt: recurring bulk-enumeration or zone-transfer probing from the same client across multiple days
DnsEvents
| where TimeGenerated > ago(7d)
| where isnotempty(ClientIP)
| where not(ClientIP has_any (dynamic(["10.", "192.168.", "172.16.", "127."])))
| where QueryType in ("AXFR", "IXFR", "252", "251", "ANY", "NS", "SOA", "TXT", "MX")
| summarize TotalQueries = count(), UniqueDays = dcount(bin(TimeGenerated, 1d)), UniqueQueryTypes = dcount(QueryType), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by ClientIP
| where UniqueDays >= 2 and TotalQueries >= 20
| sort by TotalQueries descindex=dns OR index=network sourcetype=*dns* earliest=-7d
| eval client_ip=coalesce(client_ip, src_ip, q_ip)
| eval qtype=coalesce(qtype, query_type, rrtype)
| where isnotnull(client_ip)
| where NOT cidrmatch("10.0.0.0/8", client_ip) AND NOT cidrmatch("172.16.0.0/12", client_ip) AND NOT cidrmatch("192.168.0.0/16", client_ip)
| eval scan_day=strftime(_time, "%Y-%m-%d")
| stats count as total_queries, dc(scan_day) as unique_days, dc(qtype) as unique_query_types, min(_time) as first_seen, max(_time) as last_seen by client_ip
| where unique_days >= 2 AND total_queries >= 20
| sort - total_queriesHunts specifically for AXFR/IXFR requests that completed successfully (result code NOERROR) rather than being refused, over a longer 30-day window — since a successful unauthorized transfer should be rare-to-never on a correctly configured server, any hit here is a high-priority confirmed-disclosure candidate independent of the volumetric thresholds used in the primary detection.
// Hunt: any AXFR/IXFR request that actually succeeded (not refused), across a longer 30-day window
DnsEvents
| where TimeGenerated > ago(30d)
| where QueryType in ("AXFR", "IXFR", "252", "251")
| where ResultCode == "0" or ResultCode =~ "NOERROR"
| project TimeGenerated, Computer, ClientIP, QueryType, Name, ResultCode
| sort by TimeGenerated descindex=dns OR index=network sourcetype=*dns* earliest=-30d
| eval qtype=coalesce(qtype, query_type, rrtype)
| eval result=coalesce(result_code, rcode, result)
| where match(qtype, "(?i)^(axfr|ixfr|252|251)$") AND match(result, "(?i)^(0|noerror)$")
| table _time, host, client_ip, qtype, qname, result
| sort - _timeAtomic Red Team Tests
Uses dig to issue an AXFR (full zone transfer) request against a lab authoritative nameserver, simulating the primary zone-transfer-attempt signal this detection keys on. Targets a local/lab test zone and nameserver so the query attempt is captured in server logs regardless of whether the transfer is refused or (in a deliberately misconfigured lab zone) succeeds.
Command
dig +time=2 +tries=1 axfr df00tech-zonetransfer-test.internal @127.0.0.1 > /tmp/axfr_test_output.txt 2>&1; echo "AXFR attempt complete"Cleanup
rm -f /tmp/axfr_test_output.txtExpected Telemetry
DNS server query/transfer log entry showing a TCP/53 session and an AXFR-type request for df00tech-zonetransfer-test.internal from the test host; if no authoritative nameserver is listening on 127.0.0.1 the request fails immediately, but the outbound TCP/53 attempt and (on a lab BIND/Windows DNS instance) the query log entry are still generated for detection validation.
Expected Detection
KQL/SPL detection flags the client IP with ZoneTransferAttempts/zone_transfer_attempts >= 1 within the 10-minute bucket, given a DNS server (or lab BIND/Windows DNS instance) is logging the AXFR request for the test zone.
Issues a rapid, scripted sequence of dig queries across multiple record types and multiple candidate subdomains against a lab authoritative nameserver, simulating the query-volume and query-type-diversity fingerprint produced by dnsrecon/fierce/dnsenum-style enumeration tools when a zone transfer is refused.
Command
for qtype in NS MX TXT SOA A AAAA CNAME SRV; do for i in $(seq 1 5); do dig +time=1 +tries=1 "$qtype" "sub${i}.df00tech-zonetransfer-test.internal" @127.0.0.1 >/dev/null 2>&1; done; done; echo "Bulk enumeration simulation complete: 40 queries across 8 record types"Cleanup
trueExpected Telemetry
DNS server query log records approximately 40 queries from the test host spanning 8 distinct query types (NS/MX/TXT/SOA/A/AAAA/CNAME/SRV) and 5 distinct subdomain names within a short window.
Expected Detection
KQL/SPL bulk-enumeration branch: total_queries reaches ~40 (exceeding the MinBulkQueries=30 threshold) and unique_query_types reaches 8 (exceeding MinUniqueQueryTypes=4) — the alert fires as 'Bulk DNS Record Enumeration' even though zone_transfer_attempts is 0.
Issues a rapid sequence of ANY-type nslookup queries against a lab authoritative nameserver from a Windows host, simulating the bulk-enumeration signal on a Windows DNS Server-fronted zone (DnsEvents-based detection) rather than a BIND/Linux server.
Command
1..12 | ForEach-Object {
nslookup -type=ANY "test$_.df00tech-zonetransfer-test.internal" 127.0.0.1 2>$null | Out-Null
}
Write-Host 'Windows DNS bulk-query simulation complete: 12 ANY-type queries issued'Expected Telemetry
Windows DNS Server analytic log / DnsEvents entries for 12 ANY-type queries from the test host against 12 distinct subdomain names within a short window, ingested via Azure Monitor Agent.
Expected Detection
KQL bulk-enumeration branch counts TotalQueries and UniqueQueryNames for the client IP; lower MinBulkQueries in a lab environment to validate that a 12-query run at realistic thresholds triggers the same 'Bulk DNS Record Enumeration' alert type as the production 30-query floor.