Introduction

A secondary DNS server only stays accurate if it can pull fresh zone data from the primary. When zone transfer fails, the secondary keeps serving stale records or eventually stops answering authoritatively for the zone. The fastest path to recovery is to verify whether the failure comes from access control, authentication, networking, or a primary zone that is not actually signaling a new version.

Symptoms

  • DNS changes appear on the primary but never show up on the secondary
  • Monitoring shows one nameserver serving different answers than the others
  • Zone transfer logs mention refused, failed, or unauthorized AXFR requests
  • The SOA serial differs between primary and secondary servers
  • The problem started after a firewall, DNS software, or TSIG change

Common Causes

  • The primary server does not allow zone transfers from the secondary IP
  • TSIG keys or algorithms differ between the primary and secondary configuration
  • The primary zone serial was not incremented after editing records
  • Firewalls or ACLs block TCP port 53 between the servers
  • The secondary is requesting the wrong zone name or primary endpoint

Step-by-Step Fix

  1. Compare the SOA serial served by the primary and secondary so you can confirm whether the issue is stale data or a completely failed transfer path.
  2. Review the primary DNS server configuration and verify the secondary IP is explicitly allowed to request AXFR or IXFR for the zone.
  3. Check whether TSIG is required and confirm both sides use the same key name, secret, and algorithm.
  4. Make sure the primary zone serial increases whenever records change, because a secondary will not pull a new copy without a newer version.
  5. Test TCP reachability on port 53 between the two servers instead of checking only UDP resolution.
  6. Inspect DNS logs on both servers so you can see whether the transfer is refused, unauthenticated, timing out, or never attempted.
  7. Correct the ACL, TSIG, endpoint, or serial issue and trigger a manual retransfer if your DNS platform supports it.
  8. Verify the secondary now serves the same SOA serial and representative records as the primary.
  9. Keep transfer permissions, key rotation, and serial management documented together so future DNS changes do not silently desynchronize the cluster.