Zone Transfer (AXFR) Check

AXFR is the DNS protocol's full zone transfer. It exists so that a secondary nameserver can download a complete copy of a zone from a primary, including every record: every subdomain, every internal hostname, every CNAME pointing at a SaaS vendor, every staging or admin host that has a DNS entry. When AXFR is open to the world, an attacker pulls that entire inventory with one query and skips weeks of subdomain enumeration.

Fail: a nameserver returned a successful zone transfer

RedScore opens TCP/53 to each of your authoritative nameservers (up to four) and sends an AXFR query for your zone. A correctly configured server refuses, returns an empty answer, or drops the connection. A vulnerable server returns the full zone. Per-NS results in the evidence are one of: possible_axfr_success (vulnerable), axfr_refused_or_empty (correct), connect_failed, no_response, ns_resolve_failed.

Almost every open AXFR finding is the same root cause: the nameserver was configured before TSIG or IP allow-lists were standard practice, or a migration inherited a permissive default. The fix is restricting AXFR to a known short list of secondary nameservers, either by source IP or by TSIG shared secret.

BIND (named)

Set a deny-by-default at the global options level, then explicitly allow your secondaries per zone. Use a TSIG key wherever possible:

options {
    allow-transfer { none; };
};

key "secondary-key" {
    algorithm hmac-sha256;
    secret "...base64-shared-secret...";
};

zone "yourdomain.tld" {
    type master;
    file "yourdomain.tld.zone";
    allow-transfer { key "secondary-key"; };
    also-notify { 192.0.2.10 key "secondary-key"; };
};

If you cannot use TSIG, fall back to an IP allow-list (allow-transfer { 192.0.2.10; }), but understand that source-IP trust is fragile behind NAT or shared transit. Reload BIND (rndc reconfig) and re-probe.

Microsoft Windows DNS Server

DNS Manager: right-click the zone, Properties, Zone Transfers tab. Either uncheck "Allow zone transfers" entirely, or set it to "Only to servers listed on the Name Servers tab" (use this only if the NS list is locked down), or "Only to the following servers" with explicit IPs.

Set-DnsServerPrimaryZone -Name "yourdomain.tld" \
    -SecureSecondaries TransferToZoneNameServer
Restart-Service DNS

PowerDNS Authoritative

Restrict per-zone using metadata, or globally in pdns.conf:

# Per-zone allow-list:
pdnsutil set-meta yourdomain.tld ALLOW-AXFR-FROM 192.0.2.10

# Or globally in /etc/powerdns/pdns.conf:
allow-axfr-ips=192.0.2.10,2001:db8::10
disable-axfr=no

NSD and Knot DNS

Both are authoritative-only and ship deny-by-default for AXFR. If they are flagged, an explicit provide-xfr (NSD) or acl (Knot) entry is allowing it. Tighten the entry to the secondary's IP and a TSIG key.

Managed DNS providers

Cloudflare, Route 53, Google Cloud DNS, NS1, and Azure DNS do not expose public AXFR. If your scan flags AXFR open against one of their IPs, the probed IP is almost certainly not the provider; check whether your zone has an in-bailiwick NS pointing at a host you operate. If you genuinely need AXFR for a migration, use the provider's secondary-DNS or import API instead of opening transfer publicly.

Verify the fix

• From outside your network, run dig @<ns-ip> yourdomain AXFR. The response should be "; Transfer failed." or a refusal status, never a multi-line zone listing.
• Repeat for every nameserver IP in the evidence. AXFR must be refused on every authoritative NS, not just the primary.
• Test from a cloud VM or other external vantage point. Internal IPs may be allow-listed and pass while the public still allows transfer.
• Re-run the RedScore lookup. The check passes only when no NS returns a successful transfer.

Common pitfalls

• Source-IP allow-lists fail behind NAT. If your edge firewall rewrites source IPs to a single egress address, anyone behind that NAT (including attackers on the same shared network) appears trusted.
• Configuring at the wrong level. BIND's allow-transfer applies at both options (global default) and zone (override) scope. A zone-level setting silently overrides the global deny.
• Forgetting hidden secondaries. After moving to a managed provider, the old self-hosted server is sometimes left running with zone data and a permissive AXFR config. If it is still in the NS list, attackers can transfer from it directly.
• Allowing transfer to "any TSIG-signed request" without restricting which keys count. The TSIG key is only protective if the secret is held by your secondaries and nobody else.