Network & Infrastructure / DNS, DNSSEC & Service Discovery
DNS NOTIFY delivery versus successful zone replication
A primary sends notifications after every update, but one secondary remains stale. Notification is only a prompt to check; the transfer path can still fail authentication or reachability.
Environment and inputs: Authoritative and recursive DNS infrastructure; BIND examples are conceptual and require release-matched configuration. Diagnostic/design example; not tested on production equipment.
Collect the evidence
Capture NOTIFY receipt, subsequent SOA checks, transfer attempts, authentication results and network decisions. Compare expected primary addresses with what the secondary actually uses.
Explain the result
Receiving a change notification does not transfer the zone. Successful replication depends on a valid source, permitted transfer, supported authentication and a usable transport path.
Plan the fix
Repair the first failed replication stage using narrowly scoped transfer permissions. Keep notification ACLs and transfer authorization distinct rather than broadly trusting every notifying server.
Check the result and rollback
Publish a harmless controlled record change and verify serial and content convergence. Restore previous transfer settings if authorization expands beyond designated secondaries or unsigned unexpected transfers become possible.