Restricting AXFR by Source IP Alone Still Lets a Secondary Nameserver Leak the Full DNS Zone

Symptom

An external DNS reconnaissance check or vulnerability scan reports a successful unauthenticated zone transfer against one of the domain’s published nameservers, even though the primary authoritative server correctly refuses the same request. Running an AXFR query against each name server (NS) record individually shows that most refuse the transfer, but at least one secondary responds with the complete zone contents, including subdomains, internal hostnames and every record type present.

False Assumption

The operating assumption was that restricting zone transfers by source IP address on the primary server was sufficient to secure the zone, because the primary is the server administrators actively manage and monitor. IP-address matching was treated as equivalent to authentication. In practice, IP-based access control identifies a network path, not a verified identity: it does not authenticate the requester, and it applies only to the server on which it was configured. This analysis assumes a BIND9-style authoritative deployment; PowerDNS, Knot and Windows DNS use different configuration syntax for the same underlying AXFR (RFC 5936) mechanism, so the specific directive names will differ even though the exposure pattern is the same.

Root Cause

The allow-transfer restriction was applied only to the primary master’s configuration file, using an IP address control list (ACL) with no transaction-signature (TSIG) key requirement. One or more secondary authoritative servers listed in the zone’s NS delegation retained the platform default transfer setting, or used a broader ACL than intended, so any client able to reach that secondary directly over TCP/53 could complete an AXFR and obtain the entire zone. Because DNS resolvers and clients are free to query any of the published authoritative servers, restricting only the primary leaves the zone protected on one server and open on another.

Impact

The exposed zone transfer discloses every record in the zone to an unauthenticated party, including internal or staging hostnames, mail and service records, and any subdomains that were not intended to be publicly enumerable. This information materially assists reconnaissance for further attacks such as targeted phishing, subdomain takeover attempts or infrastructure mapping, even though it does not by itself grant access to any system. The severity depends on what the zone actually contains; a zone limited to public-facing records carries lower risk than one that also serves internal or pre-production names.

Diagnosis

Confirm the exposure and its scope before changing any configuration.

• Enumerate every authoritative server published for the zone.
• Test an unauthenticated AXFR against each server individually, not just the primary.
• Inspect the transfer configuration on every server, including any hidden master or secondary, and confirm whether TSIG is required or only an IP ACL is in effect.

dig +short NS example.com
dig @<ns-hostname> axfr example.com
named-checkconf /etc/bind/named.conf

A server that returns full zone data to the AXFR query without presenting a TSIG challenge is the misconfigured server, regardless of what the primary enforces.

Correction

Apply TSIG-based transfer authentication uniformly across every authoritative server for the zone, not only the primary. Generate or reuse an existing TSIG key shared between the primary and each legitimate secondary, replace the IP-only allow-transfer ACL with a key-based restriction on every server, and reload the configuration on each affected server after validating syntax.

# On every authoritative server (primary and secondaries):
# allow-transfer { key transfer-key; };
named-checkconf /etc/bind/named.conf
rndc reconfig

Back up the existing configuration file on each server before editing it, so the prior state can be restored immediately if the change disrupts legitimate replication.

Validation

Repeat the same unauthenticated AXFR test against every NS record and confirm the transfer is refused everywhere except when a valid TSIG-signed request is presented. Then confirm the legitimate secondary can still complete a signed transfer and that its zone serial matches the primary’s serial within one refresh interval, so the fix has not broken intended replication.

• Unauthenticated AXFR against each NS record returns REFUSED or a transfer-failed response.
• A TSIG-signed AXFR from the legitimate secondary succeeds and the resulting zone serial matches the primary.
• DNS resolution for the zone continues to work normally for ordinary queries throughout the change.

Rollback

If the corrected configuration breaks legitimate zone replication, restore the previous configuration on the affected server immediately rather than leaving replication broken while troubleshooting.

• Restore the pre-change configuration file from backup on the affected server.
• Reload the configuration (for example, rndc reconfig) to reapply the prior allow-transfer setting.
• Confirm the secondary resumes normal transfers and the zone serial converges again before considering the rollback complete.
• Treat sustained SOA serial drift beyond one full refresh interval as the stop condition that triggers rollback rather than continued live troubleshooting.

Prevention

Treat zone transfer restriction as a per-server control, not a per-zone one: every authoritative server for a zone, including hidden masters and any future secondary, must enforce the same TSIG-based restriction before it is added to the NS delegation. Add an automated, recurring external AXFR probe against every published NS record as a regression check, and record the assumption that IP-based ACLs alone are not authentication in the runbook for anyone provisioning a new secondary.