Articles

Fix DNS Zone Transfer Failed Between Primary and Secondary (2026)

April 16, 2026 6 min read

The primary DNS server is refusing to send zone data to the secondary DNS server, breaking the replication of DNS records.

Common Causes and Fixes:

1. Incorrect allow-transfer Directive in Primary’s named.conf

  • Diagnosis: On the primary DNS server, check the zone definition in its named.conf (or equivalent configuration file). Look for the allow-transfer directive.
    grep "allow-transfer" /etc/named.conf
  • Cause: The secondary server’s IP address is not listed or is incorrectly specified in the allow-transfer list for the zone.
  • Fix: Add the secondary DNS server’s IP address to the allow-transfer list. For example, if your secondary is at 192.168.1.10 and your primary is at 192.168.1.5:
    zone "example.com" {
    type master;
    file "zones/db.example.com";
    allow-transfer { 192.168.1.10; }; // Add or verify this line
};
    Then, reload the primary DNS server’s configuration:
    systemctl reload named
  • Why it works: This directive explicitly grants permission to specific IP addresses to request zone transfers from the primary. Without it, the primary denies all such requests.

2. Firewall Blocking Port 53 (TCP/UDP)

  • Diagnosis: From the secondary DNS server, attempt to connect to the primary DNS server on port 53 using telnet or nc.
    # On secondary server
telnet <primary_ip> 53
# Or
nc -vz <primary_ip> 53
    If it times out or connection is refused, the firewall is likely the culprit. Also, check firewall rules on both the primary and secondary servers, and any network firewalls in between.
  • Cause: A firewall on the primary server, the secondary server, or in the network path is preventing traffic on UDP port 53 (for queries) and TCP port 53 (for zone transfers).
  • Fix: Allow traffic on TCP and UDP port 53 between the primary and secondary DNS servers.
    • firewalld (CentOS/RHEL/Fedora):
      # On primary server
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload
# On secondary server (if it has outbound restrictions)
firewall-cmd --permanent --add-port=53/tcp
firewall-cmd --permanent --add-port=53/udp
firewall-cmd --reload
    • iptables (Debian/Ubuntu/older systems):
      # On primary server
iptables -A INPUT -p tcp --dport 53 -s <secondary_ip> -j ACCEPT
iptables -A INPUT -p udp --dport 53 -s <secondary_ip> -j ACCEPT
service iptables save # or equivalent command to persist rules
# On secondary server (if it has outbound restrictions)
iptables -A OUTPUT -p tcp --dport 53 -d <primary_ip> -j ACCEPT
iptables -A OUTPUT -p udp --dport 53 -d <primary_ip> -j ACCEPT
service iptables save # or equivalent command to persist rules
  • Why it works: Zone transfers use TCP port 53 to reliably transfer the entire zone file. DNS queries typically use UDP port 53. Allowing traffic on these ports ensures the secondary can communicate with the primary for DNS lookups and zone data retrieval.

3. Incorrect masters Directive in Secondary’s named.conf

  • Diagnosis: On the secondary DNS server, check the zone definition in its named.conf. Look for the masters directive.
    grep "masters" /etc/named.conf
  • Cause: The IP address of the primary DNS server is not correctly specified in the masters list for the zone on the secondary.
  • Fix: Ensure the primary DNS server’s IP address is listed correctly in the masters directive.
    zone "example.com" {
    type slave;
    file "slaves/db.example.com";
    masters { 192.168.1.5; }; // Ensure this is the primary's IP
};
    Then, reload the secondary DNS server’s configuration:
    systemctl reload named
  • Why it works: This directive tells the secondary server where to fetch the zone data from. An incorrect IP here means the secondary is trying to contact the wrong server.

4. named Service Not Running on Primary

  • Diagnosis: Check the status of the BIND (named) service on the primary DNS server.
    systemctl status named
  • Cause: The BIND service on the primary server is stopped or has crashed, meaning it cannot respond to any requests, including zone transfer requests.
  • Fix: Start and enable the BIND service on the primary server.
    systemctl start named
systemctl enable named
  • Why it works: The named process is the daemon that handles DNS requests. If it’s not running, no DNS functionality, including zone transfers, can occur.

5. SELinux or AppArmor Restrictions

  • Diagnosis: Check the system logs (e.g., /var/log/audit/audit.log for SELinux, or /var/log/syslog for AppArmor) for any AVC denial messages related to named or network operations.
    sudo ausearch -m avc -ts recent | grep named
# Or
sudo grep named /var/log/syslog
  • Cause: Security Enhanced Linux (SELinux) or AppArmor policies are preventing the named process from binding to network sockets or performing necessary file operations for zone transfers.
  • Fix:
    • SELinux: Temporarily set SELinux to permissive mode to test: sudo setenforce 0. If zone transfers work, you need to create or adjust SELinux policies. A common fix is to ensure the named process can access network ports and has the correct context for its zone files. For example, to allow transfers to a specific port: sudo semanage port -a -t named_port_t -p tcp 53. More specific rules might be needed depending on the exact denial. Re-enable enforcing mode with sudo setenforce 1 after testing.
    • AppArmor: Edit the AppArmor profile for named (usually in /etc/apparmor.d/named.conf or /etc/apparmor.d/local/named.conf) to allow necessary network access or file permissions. Reload AppArmor profiles: sudo service apparmor reload.
  • Why it works: SELinux and AppArmor enforce mandatory access control. Incorrect policies can block legitimate operations by the named service, even if standard firewall rules permit the traffic. Adjusting these policies allows named to perform its required functions.

6. Incorrect Zone File Permissions on Primary

  • Diagnosis: Check the permissions of the zone file on the primary DNS server.
    ls -l /var/named/zones/db.example.com
# Or wherever your zone files are located
  • Cause: The named process (often running as user named or bind) does not have read permissions on the zone file it’s serving. While this typically affects serving queries, it can sometimes manifest as transfer issues if the process can’t access the data it’s supposed to send.
  • Fix: Ensure the named user has read access to the zone file.
    chown named:named /var/named/zones/db.example.com
chmod 644 /var/named/zones/db.example.com
systemctl reload named
  • Why it works: The named service needs to read the zone file from disk to send its contents during a zone transfer. Correct ownership and read permissions ensure the service can access the file.

After resolving these issues, you should see the secondary server successfully perform a zone transfer. The next error you might encounter is a "SERVFAIL" response for DNS queries if the secondary server itself is misconfigured or if there are still network issues preventing it from responding to queries.

Want structured learning?

Take the full Dns course →