DNS Server Zone Transfer Information Disclosure

Plugin tenable:10595 is not a software bug or patchable CVE; it detects an *authoritative DNS server* that will answer a full zone transfer (AXFR) to the scanner's source IP. That can expose the zone's DNS records in bulk, including A, MX, NS, and sometimes internal-looking hostnames, mail routes, VPN names, backup systems, and delegated subzones. Affected scope is version-agnostic: *any* DNS product is in scope if it is configured to permit AXFR too broadly, including Windows DNS and BIND.

Tenable calling this MEDIUM is defensible in the abstract, but for enterprise patch triage it is usually a notch too hot. The decisive friction is that this is *information disclosure only* with no code execution, no auth bypass, and no persistence; plus many findings are only reachable from an internal scanner, which means the attacker is already on-net. I would downgrade to LOW by default, while explicitly fast-tracking any case where an *internet-facing authoritative zone* is leaking sensitive records to arbitrary clients.

Why this verdict

• Baseline starts at Medium because AXFR is unauthenticated, remotely testable, and can dump a whole zone in one request if misconfigured.
• Downgrade for impact type because the result is information disclosure, not code execution, auth bypass, privilege escalation, or service takeover.
• Downgrade for exposure friction because only authoritative servers that both answer TCP/53 and explicitly permit transfer to the requestor are affected; that sharply narrows the reachable population in mature deployments.
• Keep it above IGNORE because a leaked zone can materially accelerate phishing, password spray, perimeter mapping, and lateral movement by exposing hostnames and service layout.

Why not higher?

There is no direct system compromise here. Even a complete zone dump still requires a separate second-stage path—credential abuse, another vulnerability, or social engineering—to create real business impact.

Why not lower?

If the affected server is a public authoritative DNS host and it will transfer to arbitrary internet clients, exploitation is immediate and anonymous. That kind of bulk reconnaissance leak is still a real weakness, especially when the zone contains admin, mail, VPN, backup, or environment-identifying records.

1. Restrict AXFR to explicit secondaries — Allow zone transfers only to the exact secondary servers that need them, using name-server-listed or IP-specific ACLs and TSIG where supported. For a LOW verdict there is no SLA (treat as backlog hygiene), but if this is a public authoritative zone leaking meaningful records, do not leave it for a generic backlog window.
2. Block untrusted TCP/53 paths — Enforce firewall rules so only legitimate secondaries can reach TCP/53 on authoritative servers. This removes the most practical remote path because AXFR runs over TCP; for LOW, treat as backlog hygiene unless external exposure makes the risk concrete.
3. Separate public and private DNS — Keep internal hostnames and service names out of public authoritative zones through split-horizon DNS or separate private zones. This reduces the value of any accidental transfer and is worth doing even when the transfer is already restricted.
4. Log and alert on AXFR attempts — Enable authoritative DNS logging for transfer requests and alert on unexpected client IPs, especially internet sources or non-secondary hosts. This is cheap detection depth and can be implemented during normal operations with no formal LOW mitigation SLA.

Run this from an auditor workstation or scanner host that can reach the target authoritative DNS server on TCP/53. Invoke it as ./check-axfr.sh example.com 192.0.2.53; no privileges are required, but dig must be installed and the result is only valid from the network location where you run it.

#!/usr/bin/env bash
# check-axfr.sh
# Usage: ./check-axfr.sh <zone> <dns_server>
# Exit codes:
#   0 = VULNERABLE (AXFR succeeded)
#   1 = PATCHED (AXFR refused / not allowed)
#   2 = UNKNOWN (connectivity / tooling / ambiguous result)
#   3 = USAGE ERROR

set -u

ZONE="${1:-}"
SERVER="${2:-}"
TIMEOUT=5
TRIES=1

if [[ -z "$ZONE" || -z "$SERVER" ]]; then
  echo "UNKNOWN - usage: $0 <zone> <dns_server>" >&2
  exit 3
fi

if ! command -v dig >/dev/null 2>&1; then
  echo "UNKNOWN - 'dig' not found in PATH"
  exit 2
fi

# First, confirm the server appears authoritative / reachable for the zone.
SOA_OUT=$(dig +time=${TIMEOUT} +tries=${TRIES} +tcp @"$SERVER" "$ZONE" SOA +noall +answer +comments 2>&1)
SOA_RC=$?

if [[ $SOA_RC -ne 0 ]]; then
  echo "UNKNOWN - SOA query failed to execute against $SERVER for $ZONE"
  exit 2
fi

if ! grep -Eq "\sSOA\s" <<< "$SOA_OUT"; then
  # If there is no SOA answer, the server may not be authoritative, may be filtered,
  # or the zone argument may be wrong. Do not call it patched.
  echo "UNKNOWN - no SOA answer from $SERVER for $ZONE"
  exit 2
fi

# Attempt AXFR over TCP. Successful transfers typically end with 'XFR size:' and include records.
AXFR_OUT=$(dig +time=${TIMEOUT} +tries=${TRIES} +tcp @"$SERVER" "$ZONE" AXFR 2>&1)
AXFR_RC=$?

if [[ $AXFR_RC -ne 0 ]]; then
  echo "UNKNOWN - AXFR command failed to execute"
  exit 2
fi

# Successful AXFR indicators.
if grep -q "XFR size:" <<< "$AXFR_OUT" && ! grep -Eqi "Transfer failed|connection timed out|communications error|no servers could be reached" <<< "$AXFR_OUT"; then
  echo "VULNERABLE"
  exit 0
fi

# Common denied / safe indicators.
if grep -Eqi "Transfer failed|REFUSED|NOTAUTH|NOTIMP|connection reset|connection refused" <<< "$AXFR_OUT"; then
  echo "PATCHED"
  exit 1
fi

# Timeouts and network failures are ambiguous from this vantage point.
if grep -Eqi "timed out|no servers could be reached|communications error|network is unreachable|host unreachable" <<< "$AXFR_OUT"; then
  echo "UNKNOWN"
  exit 2
fi

# Fallback: if we did not see an explicit success marker, do not overstate.
echo "UNKNOWN"
exit 2

Sources

1. Tenable Nessus Plugin 10595 Changelog
2. Microsoft Learn - DNS zones in DNS Server on Windows Server
3. Microsoft Learn - Manage DNS zones using DNS server in Windows Server
4. ISC BIND 9 Configuration Reference - allow-transfer
5. Nmap NSE - dns-zone-transfer
6. RFC 5936 - DNS Zone Transfer Protocol (AXFR)
7. NIST SP 800-81-2 Secure DNS Deployment Guide
8. Censys Active DNS Documentation