How to Fix DNS Server Zone Transfer Information Disclosure (AXFR)

DNS Server Zone Transfer Information Disclosure (AXFR) means your name server hands a full copy of a zone to any host that asks. Fix it by allowing zone transfers only to your secondaries. In BIND, set allow-transfer to their IPs or a TSIG key. In Windows DNS, choose Only to the following servers or turn transfers off.

What the scanner is actually detecting

The scanner sends a standard AXFR query (a request for a full zone transfer) over TCP port 53 for a zone the server is authoritative for. If the server returns the zone’s records instead of refusing, the finding fires. Nothing on the server is changed.

• Nessus plugin 10595, “DNS Server Zone Transfer Information Disclosure (AXFR)”: family DNS, severity Medium, CVSS v2 base score 5.0, references CVE-1999-0532. Tenable’s recommended solution is to limit zone transfers to the servers that need them.
• Greenbone / OpenVAS runs an equivalent zone transfer check. Older feeds built it on Nmap’s dns-zone-transfer script, so the title in your report depends on your feed version. The condition and the fix are the same.

Two details affect how you should read the result:

• An AXFR request names a single zone, so a server can refuse one zone and hand over another, reverse zones included.
• The answer depends on the scanner’s source address. A scanner inside a range you allowed gets the zone even when outside hosts would be refused.

Real-world risk, stated honestly

DNS records exist to be looked up, so a transfer reveals nothing a resolver would not return one name at a time. The difference is that nobody has to guess the names. As Tenable notes, hostnames often reveal what a server does, so a full transfer becomes a ready-made target list and a rough network map.

In practice the exposure looks like this:

• Forgotten hosts. A transfer lists staging and test systems, old VPN portals and vendor CNAMEs that still resolve but are missing from your inventory. Records that point at deprovisioned cloud resources can lead directly to dangling DNS and subdomain takeover.
• Internal addressing. An Internet-facing server that also carries internal zones, or a public zone that contains private IPs, gives away your internal layout.
• No direct compromise. This finding does not let anyone change records (that is a separate dynamic update issue), run code or read other data. Tenable lists no known exploits, but none are needed: a single dig command is the whole attack.

Fix an Internet-facing server that transfers public zones to anyone promptly; the change is small. A domain controller flagged by an internal scanner is lower risk but still worth closing, because anything on the network, malware included, can pull the zone. Closing AXFR does not make hostnames private: certificate transparency logs and passive DNS data expose many of them, and a passive DNS subdomain inventory shows what outsiders can already see.

How to confirm it on the host

Run the test from a host that is not one of your secondaries, ideally the scanner itself or an external VM:

dig @203.0.113.53 example.com AXFR

An open server returns the SOA, every record in the zone, the SOA again and an “XFR size” summary. A refusal prints ; Transfer failed. A timeout means something on the path blocks TCP 53, which says nothing about the server’s own configuration.

Nmap has an equivalent script:

nmap -Pn -p 53 --script dns-zone-transfer --script-args dns-zone-transfer.domain=example.com 203.0.113.53

Repeat the test for every zone the server hosts, forward and reverse, and on every server that holds a copy, because secondaries can serve transfers too.

On BIND, check the version and the effective configuration:

named -v
named-checkconf -p | grep -n "allow-transfer"

If the grep returns nothing, the built-in default applies, and it changed between releases: the BIND 9.18 manual documents transfers to all hosts when allow-transfer is unset, while the 9.20 manual documents none. A 9.18 server with no allow-transfer statement is open.

On Windows DNS (PowerShell):

Get-DnsServerZone | Where-Object { $_.ZoneType -eq "Primary" } |
    Format-Table ZoneName, IsDsIntegrated, SecureSecondaries, SecondaryServers

TransferAnyServer means the zone is open to everyone. Microsoft documents transfers as disabled by default for AD-integrated zones and limited to Name Servers tab entries for file-backed zones, so an open zone usually means someone selected To any server. Each server keeps this setting in its own registry, under HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDNS ServerZones<zone> (value SecureSecondaries, where 2 means only listed servers and 3 means transfers are disabled).

How to fix it

BIND 9: deny by default, allow per zone

Set a restrictive global default, then open each primary zone to its secondaries only. An allow-transfer in a zone block overrides the one in options or view.

options {
    // ...existing options...
    allow-transfer { none; };
};

zone "example.com" {
    type primary;               // "type master" in older configs
    file "example.com.zone";
    allow-transfer { 192.0.2.10; 198.51.100.20; };   // your secondaries only
};

Zones without secondaries inherit none. allow-transfer also applies to secondary zones, so the global none matters on your secondaries as well. On 9.18 and earlier, a secondary without it passes the zone on to anyone. Check the syntax and apply the change:

named-checkconf
rndc reconfig

BIND 9: authenticate secondaries with TSIG

An IP list is enough to close the finding. A TSIG key adds authentication, so only a server holding the shared secret can transfer the zone. Generate a key (HMAC-SHA256 by default), keep the file out of world-readable locations and copy it to the secondary over a secure channel:

tsig-keygen xfr-example > /etc/bind/xfr-example.key
chmod 640 /etc/bind/xfr-example.key    # group-readable by the named/bind group only

On the primary:

include "/etc/bind/xfr-example.key";

zone "example.com" {
    type primary;
    file "example.com.zone";
    allow-transfer { key "xfr-example"; };
};

On the secondary:

include "/etc/bind/xfr-example.key";

zone "example.com" {
    type secondary;             // "type slave" in older configs
    file "example.com.zone";
    primaries { 203.0.113.53 key "xfr-example"; };   // "masters" on older releases
};

Any address holding the key can transfer the zone, so guard the key file; add a firewall rule if you also want to limit source addresses.

Windows Server DNS

In DNS Manager, expand the server, right-click the zone and choose Properties, then open the Zone Transfers tab. Either clear Allow zone transfers, or leave it checked, select Only to the following servers and add your secondaries’ IP addresses. Microsoft’s guidance is to disable transfers unless you need them and, if you do, to restrict them to specific IP addresses. The PowerShell equivalents:

# Zone has secondaries: allow only their IPs
Set-DnsServerPrimaryZone -Name "example.com" -SecureSecondaries TransferToSecureServers -SecondaryServers 192.0.2.10,198.51.100.20

# Zone has no secondaries: turn transfers off
Set-DnsServerPrimaryZone -Name "example.com" -SecureSecondaries NoTransfer

With dnscmd (the . means the local server):

dnscmd . /ZoneResetSecondaries example.com /SecureList 192.0.2.10 198.51.100.20
dnscmd . /ZoneResetSecondaries example.com /NoXfr

These settings are not stored in Active Directory and do not replicate, so apply them on every domain controller hosting the zone (for example with -ComputerName DC02). Only to servers listed on the Name Servers tab (TransferToZoneNameServer) also restricts transfers, but Microsoft documents a known issue where it breaks incremental transfers on servers with multiple IP addresses, so an explicit IP list is more predictable.

How to verify the fix and rescan

1. From an untrusted host, repeat dig @server zone AXFR for every zone, forward and reverse. Expect ; Transfer failed.
2. From each secondary, confirm that legitimate transfers still work. With TSIG, run dig -k /etc/bind/xfr-example.key @203.0.113.53 example.com AXFR. On BIND secondaries, run rndc retransfer example.com and check the log. On Windows secondaries, run Start-DnsServerZoneTransfer -Name “example.com” -FullTransfer.
3. Compare SOA serials on the primary and the secondaries: dig @192.0.2.10 example.com SOA +short.
4. Rescan from the same scanner position that raised the finding, with plugin 10595 (or the Greenbone equivalent) enabled.

What can break and how to roll back

• Missed secondaries. They serve their last copy until the SOA expire timer runs out, then stop answering for the zone, so failures can surface days later. Check secondary logs for refused transfers right away.
• Hosted secondary DNS providers. Get their transfer source addresses, or set up TSIG, before tightening the ACL.
• Tools that pull zones with AXFR. IPAM, backup scripts and monitoring may rely on transfers; allow their addresses explicitly.
• Windows replication scope changes. Microsoft documents that changing an AD-integrated zone’s replication scope resets the transfer settings on the other DCs: transfers are disabled and the server list is removed. Re-apply the settings afterwards.

Record the current state before you change anything so that rollback is quick:

# Windows: save current settings, restore a zone later with Set-DnsServerPrimaryZone
Get-DnsServerZone | Select-Object ZoneName, SecureSecondaries, SecondaryServers |
    Export-Clixml C:Tempzone-xfer-before.xml

# BIND: keep a copy of named.conf; to roll back, restore it, then
named-checkconf
rndc reconfig

Common false positive reasons

• The scanner is inside the allowed range. The ACL uses a broad internal network or localnets, and the scanner sits inside it. Narrow the list to the exact secondary IPs, or record the finding as expected.
• The IP is not your DNS server. A firewall, load balancer or DNS proxy on port 53 may be the device that answered.
• You fixed the primary but not the copies. Secondaries, anycast nodes or load-balanced backends still allow transfers.
• One zone or view was missed. The scanner tested a reverse zone, a lab zone, or a BIND view whose own allow-transfer overrides options.

FAQ

Is allow-transfer { none; } in options enough on BIND?

It closes every zone that does not set its own value. View-level and zone-level statements override it, so search for those too. Zones with secondaries need their own allow-transfer.

Can I just block TCP port 53?

No. AXFR runs over TCP, but ordinary DNS responses that are too large for UDP also fall back to TCP, so blocking it breaks legitimate lookups. Restrict transfers in the DNS server configuration instead.

Does restricting zone transfers affect Active Directory replication?

No. AD-integrated zones replicate through Active Directory, not through zone transfers, and Microsoft documents transfers as disabled by default for them. Only standard secondary zones depend on this setting.

Do I need TSIG to fix Nessus 10595?

No. An IP-restricted list closes the finding. TSIG adds authentication and is worth using when secondary addresses change or belong to a DNS provider.

Tracking this finding across many hosts

Plugin 10595 tends to appear on primaries, secondaries and domain controllers at once, and fixing one server does not fix its copies. SITEY, a self-hosted vulnerability management platform, imports findings from 16 scanners, including OpenVAS and Nessus (Nessus results are imported by uploading the exported .nessus file). It merges duplicates per scanner and can retest an individual Nessus finding to confirm it has closed.

Sources

• Tenable: Nessus plugin 10595, DNS Server Zone Transfer Information Disclosure (AXFR)
• ISC BIND 9 Administrator Reference Manual: configuration reference (allow-transfer, primaries)
• ISC BIND 9 Administrator Reference Manual: security configurations (TSIG)
• Microsoft Learn: Manage DNS zones using DNS server in Windows Server (zone transfer settings)
• Microsoft Learn: DNS zone transfer options are unexpectedly reset