BIND9 Secondaries Inherit the Open AXFR Default
A hardened AXFR policy on the primary nameserver means nothing if the secondaries never got the same allow-transfer ACL. BIND9 falls back to its global any default per zone stanza, so attackers query the slave directly and pull the full zone, exposing every internal hostname without touching the locked-down primary at all.
Operational summary
At a glance
- Symptom
- An external host runs dig axfr directly against a secondary nameserver instead of the hardened primary.
- Likely cause
- allow-transfer left at BIND9's global default of any on secondary nameserver zone stanzas while only the primary is restricted.
- Impact
- The full internal zone, including every internal hostname and infrastructure record, is disclosed to any unauthenticated requester.
- Verification signal
- Re-run the detection test and a controlled negative-path test.
- Safe correction
- Apply explicit TSIG-authenticated allow-transfer ACLs inside every zone stanza on every authoritative server and remove the global any default entirely.
- Rollback or recovery
- Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
The Trap
Inconsistent allow-transfer scoping between primary and secondary BIND9 nameservers. Engineers restrict AXFR on the hidden primary and assume the protection propagates to every server answering for the zone, but each named.conf zone stanza evaluates its own allow-transfer clause independently.
The Default State
BIND9’s global options block ships with allow-transfer { any; } unless explicitly overridden, and that default applies per zone unless a stanza-level ACL is set. Teams typically lock down the primary with allow-transfer { trusted-slaves; } and TSIG keys, then replicate the zone file to secondaries via a provisioning script that copies the zone data but not the matching ACL. The secondary’s zone stanza, or the inherited options default, is left at any. Nobody checks named.conf on the slave because the operational focus is always the write path on the primary.
The Blast Radius
Any host on the internet can run dig axfr @secondary-ns internal.example.com and receive the entire zone: every A, CNAME, MX and TXT record, including vpn-gw01, db-primary, jenkins-internal, and staging hosts never meant for public resolution. This is a full internal topology map handed over in one TCP session, with zero authentication and zero logging beyond a query log entry most teams never review. It bypasses every control applied to the primary, survives firewall rule audits that only test the primary’s IP, and feeds directly into subdomain enumeration for phishing infrastructure targeting or lateral movement planning. The exposure persists indefinitely because secondary AXFR ACLs are rarely part of any change-review checklist.
The Lead Mechanic Fix
Set allow-transfer explicitly inside every zone stanza on every authoritative server, primary and secondary alike, rather than relying on the global options default: allow-transfer { key trusted-secondary-key; }; paired with matching TSIG keys on both ends. Remove any at the options level entirely. Verify with dig axfr @ from an untrusted network segment as part of the deployment pipeline, and fail the build if any transfer succeeds without a valid key. Where possible, disable AXFR entirely and move to catalog zones or provider-native replication that never opens a transfer port to the public internet.
Apply the safer control
Before you change production
Confirm the affected scope, export the current configuration, and test the replacement control in a non-production environment first.
Apply explicit TSIG-authenticated allow-transfer ACLs inside every zone stanza on every authoritative server and remove the global any default entirely.
Validate the vendor-specific syntax in official documentation before applying it.
Verify, roll back or escalate
Verify
Re-run the detection test and a controlled negative-path test. Confirm the unsafe behaviour is blocked while approved traffic still succeeds.
Rollback
Restore the exported configuration if the new control blocks required production traffic, then narrow the policy before redeployment.
Escalate
Escalate when the blast radius is uncertain, the control cannot be tested safely, or remediation requires an outage or security exception.