eG Monitoring
 

Measures reported by BindZoneStatsTest

A zone is a point of delegation in the DNS tree. A zone consists of those contiguous parts of the domain tree for which a name server has complete information and over which it has authority. It contains all domain names from a certain point downward in the domain tree except those which are delegated to other zones. A delegation point is marked by one or more NS records in the parent zone, which should be matched by equivalent NS records at the root of the delegated zone.

The data for each zone is stored in a name server, which answers queries about the zone using the DNS protocol.

Each zone is served by at least one authoritative name server, which contains the complete data for the zone. The authoritative server where the master copy of the zone data is maintained is called the primary master server, or simply the primary. The other authoritative servers, the slave servers (also known as secondary servers) load the zone contents from another server using a replication process known as a zone transfer. Typically the data are transferred directly from the primary master, but it is also possible to transfer it from another slave. In other words, a slave server may itself act as a master to a subordinate slave server.

A zone transfer is typically triggered under the following circumstances:

  • Refresher timer expiry: Each zone's SOA record holds a refresh timer that all slave servers receiving a copy of the zone should use. The refresh timer tells a slave server how often it should ask one of the master servers to which it has been configured to refer for an SOA record. This is then compared to the SOA the slave is holding - if it is the same, there is nothing to be done (and the slave waits until the next refresh interval expiry). There is also a retry timer which is applied if the refresh attempt fails (none of the master servers could be contacted). And finally, there's an expire timer - if the slave has been unable to contact another master for this period, then it stops serving data from that zone. (Note that restarting the slave will reset any ‘expired’ zones, so if they have a copy of the zone backed up to file, they will then resume serving the expired zone).

  • Notify received: When an authoritative (master or slave) server updates a zone, it can send out notifications to other servers that it has changed. This causes the recipients to set their ‘next refresh’ time to ‘now’ and to queue a zone refresh.

Sometimes, zone transfers may fail. If administrators are not promptly alerted to such anomalies, then the zone data on one/more slaves may not be in sync with that of the primary master for long time periods. In some other cases, slaves may reject NOTIFY requests from the primary master. If such inconsistencies go undetected, then some slaves may remain oblivious to changes made to zone data on the master, thereby failing to initiate a much-needed zone transfer. To avoid such abnormalities, it is imperative that zone transfers are monitored. This is exactly what the BindZoneStatsTest test does!

This test monitors zone transfers, tracks the notifies sent and received during the transfers, and in the process, captures transfer failures and rejected notifies. This way, administrators can instantly detect issues hampering zone transfers and can rapidly initiate measures to resolve those issues, so that the zone data on the primary master and slaves remain in sync always.

Outputs of the test : One set of results for the target BIND DNS.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
v4_sent Indicates the number of IPv4 notifies sent during zone transfers. Number  
v4_recvd Indicates the number of IPv4 notifies received during zone transfers. Number  
v6_sent Indicates the number of IPv6 notifies sent during zone transfers. Number  
v6_recvd Indicates the number of IPv6 notifies received during zone transfers. Number  
req_success Indicates the number of zone transfer requests that succeeded. Number A high value is desired for this measure.
req_fail Indicates the number of transfer requests that failed. Number Ideally, the value of this measure should be 0. A non-zero value denotes that one/more transfer requests failed.

Common reasons for zone transfer failures are as follows:

  • If the TCP connection between master and slave is reset, it can cause the zone transfer to fail. This TCP connection can get reset due to the tcp-listen-queue not being increased in line with the real-time load. tcp-listen-queue is a subtle control setting (although not applicable to all OS environments). When there is a high rate of inbound TCP connections, it controls how many connections can be queued before they are accepted by the application. If named has already reached both the limit on concurrent zone transfers, and the limit specified by tcp-listen-queue, then any new inbound TCP connections will be dropped. If you're expecting a high rate of zone transfers or that zone transfer requests will be competing for master server resources, then you should increase this configuration option, whose default is 3 (increased to 10 from BIND 9.10, 9.9.4, 9.8.6 and 9.6-ESV-R10).

  • Master is inaccessible from the slave due to routing or firewall issues;
note_reject Indicates the number of zone transfer requests that were rejected. Number When a slave receives a NOTIFY request for a zone from one of its configured master name servers, it responds with a NOTIFY response.

If a slave is not able to directly communicate with the primary master and uses another slave as their master, it will reject the NOTIFY request from the master.