SOA Serial number validation
The check compare the SOA serial numbers from all authoritative name servers to validate that the monitored domain is synchronised.
The SOA serial number is used by the DNS servers to keep the zone content in sync between each other. When a zone is updated on a maser the serial number should be incremented to mark this update. A zone update is usually prompted from the master server by sending a notification containing the new serial number to the slave servers, which in turn initiate zone transfers to download the latest zone information if needed. If this process fail the zone content may become inconsistent between the authoritative servers and in worst case result in routing clients to the wrong destination.
The SOA Refresh timer sets an interval by which the slave server will try to contact the master server to check if an update is required. Once again, if the slave server can't contact the master server it will eventually result in unsynchronised zone data.
There are instances when different sets of SOA Serial numbers are a side effect of a distributed DNS design (if you have a setup of multiple DNS providers). In these cases you can either opt to turn off this check (and probably the SOA Master Name check as well) or configure two or more monitoring instances, one for each service provider.
Event severities and messages
ERROR
SOA serial number XXXX, is out of sync. Expected serial number was YYYY.
The check have discovered one or more discrepancy between the monitored servers. The check always compare with the highest serial number found.
Note. If this check happens to run during a master-slave update cycle it could cause a false positive result. This happens if the slave server is currently transferring the zone.
Probable causes
We assume that the synchronisation between the servers has been established and has worked prior to the event. Below are a list of possible causes.
Name server process is down or not responding. Check the process table on both master and slave.
Name server fails to load zone file. This is usually caused by a configuration error. Please consult the log file to find out why the zone file isn't loaded.
Communication failure between the master and slave. This can be caused by network outage, routing issues, firewall rule changes and a host of other man-made problems.
Master and/or Slave server configuration issue. Verify that notification is configured correctly on the master and that the slave server is configured to accept notifications from the sending source.
TSIG authentication failure. If using TSIG keys as authentication method verify that the keys are identical, the clock on both sides are synchronised and the access control lists are in order.
The zone file and quite possibly the DNS server have been hijacked and the attacker has disabled updates from the master server in order to secure modifications to the zone data.
Solutions, tips & tricks
The techniques described below assumes a configuration where standard ports and protocols are used.
Consult the log files on each server. Search for events that relates to notifications, zone transfers and security.
Try to resend the notification from the master server and check if it reaches the failed slave server. This process differs between name server software. Consult the documentation for your specific DNS server how to perform this action.
Validate that the master and slave server is able to communicate. The notification is sent from the master to the slave using UDP on port 53 and the zone transfer is requested from the slave to the master using TCP on port 53.