SOA Serial number check
Prerequisites:
None.
Package:
Integrity.
Executed on:
All nameserver IP addresses.
Check interval:
Every 5 minutes.
Impact on Availability:
None.
Impact on Integrity:
High.
Purpose
The check compares 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 contents in sync with each other. When a zone is updated on a master, the serial number should be incremented to mark the update. A zone update is usually initiated by the master server by sending a notification with the new serial number to the slave servers, which in turn initiate zone transfers to download the latest zone information if required. If this process fails, the zone content can become inconsistent between authoritative servers and, in the worst case, cause clients to be routed to the wrong destination.
The SOA refresh timer sets an interval at which the slave server will attempt to contact the master server to check if an update is required. Again, if the slave server can’t contact the master server, this will eventually result in unsynchronised zone data.
There are cases where different sets of SOA serial numbers are a side-effect of a distributed DNS design (if you have a setup with multiple DNS providers). In these cases you can either choose to disable this check (and probably the SOA Master Name check as well) or configure two or more monitoring instances, one for each service provider.
NOTE!
If a name server is found with a non-matching serial number we have elected to mark that name server as untrusted. We will still run most checks on them but the checks will produce a Warning severity and the message will display the text “Zone is out of sync so the content shouldn’t be fully trusted”.
Event severities and messages
INFO
Matching serial numbers was found on all authoritative DNS servers.
ERROR
Expected serial number #, got #.
If this status remains after two consecutive check cycles, this could indicate some serious problems, like network outage or a server issue.
Probable causes
Assuming that the synchronisation between the DNS servers has previously been established and working.
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 related 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.