The secondary area remains expired or obsolete.
Probable causes
- AXFR/IXFR filtered.
- Transfer ACL.
- SoA.
Verifications.
- Limit the impact. — Identify whether an endpoint, service, or whole site is affected.
- Collect evidence. — Keep the exact error message, timestamp, and associated logs.
- Test the simplest hypothesis first. — Compare the affected system with a known-good path.
- Correct the confirmed cause and validate the result. — Apply one controlled change at a time and retest.
Commands
nslookup -type=soa example.comSolutions.
- Correct the confirmed cause rather than the symptom.
- Document the change and its result.
- Establish monitoring if the fault can recur.
When to escalate?
Escalate if the impact expands, data are at risk, or remediation requires an irreversible change.
DNS zone-transfer focus
Compare the SOA serial returned by the primary and secondary servers. If the secondary keeps an older serial or reports the zone as expired, verify that it can reach the authoritative primary on DNS and that the primary still authorizes that secondary to request AXFR or IXFR transfers.
What to verify
- Confirm the configured primary server address and the zone-transfer allow list.
- Check firewall rules, ACLs, TSIG settings when used, and any NAT path between both DNS servers.
- Review DNS server logs for refused transfers, timeout events, malformed responses or authentication failures.
- Check whether NOTIFY messages are received; a missing NOTIFY should not prevent a correctly configured periodic refresh, but it can delay synchronization.
Resolution path
Correct the transfer permission, connectivity or authentication issue, then force a refresh from the secondary. Do not delete and recreate the zone until the primary source, SOA serial and transfer policy have been verified.
Validation
Query the SOA record on both servers and confirm that the serials converge. Then resolve several records directly against the secondary and verify that its expiry or stale-zone warning has cleared.