When DNS zone transfer failed troubleshooting begins, the visible symptom may be simple: a secondary nameserver still returns old records. The real cause can sit between the primary server, the secondary server, and the firewall between them.
A zone transfer copies DNS data from an authoritative primary server to a secondary server. An AXFR copies the complete zone. An IXFR copies changes since an earlier version. Secondary servers use these copies to answer queries when the primary is unavailable or when DNS traffic is distributed across multiple systems.
This guide follows a safe diagnostic order. First establish which server is primary, which servers are secondary, and which data is stale. Then inspect permissions, notifications, serial numbers, network access, and authentication.
Confirm the authoritative roles before DNS zone transfer troubleshooting
Start with documentation or the DNS management system. Identify the primary server for the zone and list every configured secondary. Do not assume that the server accepting administrative changes is also the transfer source. Some hosted DNS platforms use different control planes.
Next, compare the SOA record from each authoritative server. The SOA, or Start of Authority, contains the zone serial number and timing values. Query each nameserver directly rather than relying on a local resolver cache.
dig @primary.example.net example.com SOA
dig @secondary.example.net example.com SOAReplace the hostnames with nameservers you control. On Windows, use an approved DNS query tool or PowerShell equivalent. The exact command syntax depends on the operating system and installed tools.
A lower serial on the secondary usually means it has not received the latest zone version. However, a matching serial does not prove that every record is correct. The primary may contain an incorrect record, or the secondary may serve data from another view.
For background, review Cloudflare’s explanation of DNS, nameservers, and records. Also compare results from the authoritative servers before testing recursive resolvers.
Check primary-secondary permissions for a failed transfer
The primary must explicitly permit the secondary to request a transfer. Many DNS servers use an allow-transfer policy containing the secondary’s source IP address. A typo, changed address, or incorrect address family can block the request.
Check the following items on the primary:
- The secondary’s current public or private source address.
- The correct zone name and configuration view.
- Allow-transfer rules for AXFR and, where supported, IXFR.
- ACL ordering that might deny the request before an allow rule matches.
- Whether transfers are limited to an expected transport address.
Do not broadly allow transfers to the internet. A permitted transfer can expose the zone’s hostnames, service names, and network structure. Restrict access to known secondary servers and use transfer authentication where practical.
Then inspect the secondary. It must identify the correct primary address and zone. A secondary configured for dns1.example.net will not synchronize from a different server merely because both servers host the same domain name. This is a common point in DNS zone transfer failed troubleshooting.
Configuration changes require human verification. Vendor syntax, DNS software behavior, views, and managed-service controls differ. Save a backup and record the previous policy before editing it.
Verify NOTIFY settings and SOA serial numbers
After changing a zone, the primary can send a DNS NOTIFY message to configured secondaries. The secondary then checks the SOA serial and starts a transfer if its copy is older. NOTIFY speeds convergence, but it does not replace permission checks.
Confirm that the primary sends notifications to the correct secondary addresses. Check whether the secondary accepts NOTIFY from the primary address. Some systems ignore notifications from unexpected sources as a security measure.
Review the zone’s SOA serial policy as well. The serial must increase when zone content changes. If an administrator edits a record but leaves the serial unchanged, a secondary may correctly decide that no update is needed.
Use a consistent serial format. Date-based formats are common, but the important rule is monotonic increase. A new serial must be greater than the previous serial. Accidental rollback can cause secondaries to reject an update or retain newer data.
Check the SOA refresh, retry, expire, and minimum or negative-cache values. These values affect timing and failure behavior. They do not, by themselves, repair a blocked transfer.
If a manual refresh option exists, use it only after capturing logs and confirming the primary. A forced transfer can create load and may hide a recurring notification problem.
Test firewall access during DNS zone transfer failed troubleshooting
DNS zone transfers commonly use TCP port 53. Regular DNS queries often use UDP, but transfers can use TCP because the response may be large. A firewall rule that permits UDP queries does not necessarily permit transfers.
Trace the path from the secondary to the primary. Check local firewalls, perimeter firewalls, cloud security groups, NAT rules, and provider filtering. The secondary usually initiates the transfer request, while the primary returns the transfer data.
Useful evidence includes:
- Connection attempts from the secondary’s actual source address.
- Accepted or denied TCP sessions on both firewalls.
- NAT translations, if either server crosses an address boundary.
- Packets leaving the secondary and replies returning from the primary.
- Timeouts, resets, and protocol errors in DNS service logs.
Test TCP access to port 53 only from an approved administrative system or the secondary itself. A successful TCP connection proves reachability, not authorization or a valid zone transfer.
For a broader explanation of traffic translation, see Cloudflare’s NAT overview. If the primary sits behind NAT, verify that the transfer service receives the expected source identity. NAT can also make an allowlist match the wrong address.
For related firewall and reachability checks, see our guide to remote access that works internally but not externally. Review firewall changes carefully. Avoid opening TCP 53 from every address. Permit only the required secondary sources, and confirm whether IPv4 and IPv6 need separate rules.
Investigate TSIG authentication errors
TSIG, or Transaction Signature, authenticates DNS messages with a shared secret. Administrators often use it for zone transfers and NOTIFY messages. A TSIG failure can look like a network failure when the firewall permits the connection but the DNS server rejects the request.
Compare the key name, algorithm, and secret on both systems. Key names often follow DNS-name rules, so spelling, capitalization rules, and trailing dots may matter to the software. Never paste a secret into a public ticket or unsecured chat.
Check time synchronization as well. TSIG validation includes time checks. A significant clock difference can produce errors such as “request has expired” or “signature out of time.” Confirm system time through the operating system and the DNS service logs.
Use logs to distinguish authentication from authorization. A message about an unknown key differs from a message saying the key is valid but not allowed for the requested zone. This distinction points to different repairs.
After correcting a key, reload the DNS service according to its documented procedure. Validate the configuration before reloading. A syntax mistake can interrupt authoritative service, so plan a rollback.
Handle stale secondary data safely
Stale data means the secondary is serving an older zone version than the primary. First compare SOA serials directly. Then compare the affected record on every authoritative server.
Do not immediately delete the secondary zone. A missing zone can create a larger outage if the registrar or parent delegation still lists that server. Preserve the current configuration and logs before rebuilding anything.
Check the secondary’s expiry behavior. If it cannot contact the primary for long enough, it may stop answering authoritatively. The SOA expire value influences that decision. A server that continues answering old data may also reflect local policy or software behavior.
Once transfer access works, request an update and monitor the serial change. Confirm both AXFR or IXFR completion and the final record set. If IXFR repeatedly fails, the software may fall back to AXFR, or an administrator may need to repair the transfer history. The correct action depends on the DNS implementation. This verification is central to DNS zone transfer failed troubleshooting.
Test from multiple locations only after authoritative servers agree. Recursive resolvers can retain older answers until their TTL expires. This is separate from secondary synchronization. For measuring resolver behavior, see our guide to measuring slow DNS lookup timing.
Build a repeatable verification checklist
After recovery, document the result rather than closing the incident at the first successful query. Record the primary and secondary roles, transfer source addresses, permitted zones, TSIG key references, and firewall policy locations.
- Query SOA serials directly from every authoritative server.
- Confirm the primary permits each secondary’s current address.
- Confirm TCP port 53 access where transfers require it.
- Verify NOTIFY targets and accepted sender addresses.
- Check TSIG names, algorithms, secrets, and system time.
- Compare representative records after synchronization.
- Review logs for repeated failures after the repair.
Use monitoring that checks authoritative serial consistency and transfer failures. Alerts should identify the zone, server, observed serials, and last successful synchronization. Avoid alerts that reveal shared secrets or full internal zone contents.
Google’s effective troubleshooting guidance reinforces this evidence-first approach: observe the failure, test a specific hypothesis, and verify the result.
When to request assistance
DNS zone transfer failed troubleshooting works best when administrators can inspect both DNS servers, network controls, and logs. If the primary serves production domains, the secondary uses a provider, or TSIG keys and delegation remain unclear, pause before making changes.
Tech Rescue Ops LLC can help collect evidence, compare authoritative responses, review transfer policy, and plan a controlled correction. Professional remote assistance is especially appropriate when stale data affects websites, email, VPN access, or other business services.