The check compare the SOA MNAME field between all authoritative name servers to validate that zone files have the same source of origin.
DNSmonitor KB - DNS check KB

SOA MNAME validation

The check compare the SOA MNAME (Master Name) field between all authoritative name servers to validate that zone files have the same source of origin.

If authoritative name servers use different sources of origin there is no easy way to establish if the zone files in the respective servers are identical.

Other than a DNS infrastructure using multiple masters (and possible not even then) the SOA Master Name should remain consistent across all authoritative name servers. In these cases you can either opt to turn off this check (and probably the SOA Serial number check as well) or configure two or more monitoring instances, one for each service provider.

The SOA Master Name serve also serve the purpose of providing clients with a server destination for dynamic update requests.

Event severities and messages

ERROR

SOA Master name differs between the name servers. This might indicate inconsistent zone data.

Unless the DNS design dictates otherwise, the SOA Master Name field is inconsistent between the name servers. This can be concerning and is a strong indication that the server in question uses a different source of origin to transfer the zone file from.

Probable causes

We assume that the DNS servers are configured to transfer the zones from the same master server and that the setup has worked prior to the event. Below are a list of possible causes.

If you have a DNS setup with "multiple master", i.e. you use two different DNS service providers, this is very likely a false positive.

Name server fails to load zone file from the master and uses an old copy stored on disk. This is usually caused by a configuration error. Please consult the log file to find out why the zone file isn't loaded.

The zone file and possibly the DNS server might have been hijacked. The attacker has disabled updates from the original master server and quite possibly injected a rogue Master Name into the SOA record in order to redirect dynamic update requests that server.

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.

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.