Zone Maintenance Statistics Test

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 Bind Zone Maintenance Statistics 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.

Target of the test : A BIND DNS server

Agent deploying the test : An internal agent

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

Configurable parameters for the test
Parameter	Description
Test Period	How often should the test be executed.
Host	The IP address of the host for which this test is to be configured.
Port	Refers to the port at which the specified host listens to. By default, this is 53.
Path of RNDC	To monitor BIND DNS, this test uses a name server control utility in bind called Remote Name Daemon Control (RNDC). RNDC is a command line utility that allows command line control of the administration and operations of a name server, both locally and remotely. Periodically, this test runs the rndc stats command of this utility to pull metrics of interest. To enable the test to run this command, configure the full path to the folder where RNDC is located, against Path of RNDC. The default location of RNDC is /usr/sbin. If it is installed in a different location in your environment, then specify the same here.
Path of RNDC Output File	This test runs the rndc stats command of to pull metrics of interest from the target BIND DNS server. This command instructs BIND to dump the statistics to a statistics-file configured in the configuration file for the named server - /etc/named.conf. To enable this test to read from this statistics-file, specify the full path to the statistics-file against Path of RNDC Output File. By default, metrics are written to the named_stats.txt file in the /var/named/data/ folder. If chroot is enabled, then this file will typically be available in the /var/named/chroot/var/named/data folder.
Use SUDO	To run this test and report metrics, the eG agent install user should have permissions to run the rndc stats command and read from the statistics-file. If the eG agent install user possesses these privileges, then set the Use SUDO flag to No. If the eG agent install user does not have the required permissions, then do the following: Edit the sudoers file on the target host and append an entry of the following format to it: <eG_agent_install_user>; ALL=(ALL) NOPASSWD:<Command>; For instance, if the eG agent install user is eguser, then the entry in the sudoers file should be: eguser ALL=(ALL) NOPASSWD: rndc stats Then, save the file. Finally, set the Use SUDO parameter to Yes.

Measurements made by the test
Measurement	Description	Measurement Unit	Interpretation
IPv4 notifies sent	Indicates the number of IPv4 notifies sent during zone transfers.	Number
IPv4 notifies received	Indicates the number of IPv4 notifies received during zone transfers.	Number
IPv6 notifies sent	Indicates the number of IPv6 notifies sent during zone transfers.	Number
IPv6 notifies received	Indicates the number of IPv6 notifies received during zone transfers.	Number
Transfer requests succeeded	Indicates the number of zone transfer requests that succeeded.	Number	A high value is desired for this measure.
Transfer requests failed	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;
Notifies rejected	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.