Name Server Statistics Test
The efficiency of BIND DNS depends upon how well it handles the name resolution queries it receives. If BIND DNS is able to successfully service very few queries, and has been unable to service majority of the queries, it is a clear indicator of the poor health of BIND DNS. The Bind Name-Server Statistics test sheds light on such irregularities, prompts administrators to rapidly initiate corrective actions, and thus restore the BIND DNS to normalcy.
This test tracks the name resolution queries to BIND DNS and reports the count of queries that were processed successfully, the number of queries that failed, and the number that was dropped/rejected. This way, the test points to issues in query processing. Additionally, the test also captures the response codes returned by BIND DNS , thereby revealing error responses to administrators and their probable causes.
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
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:
|
Measurement | Description | Measurement Unit | Interpretation |
---|---|---|---|
IPv4 requests received |
Indicates the number of IPv4 requests received by BIND DNS. |
Number |
These are good measures of the current workload of BIND DNS. |
IPv6 requests received |
Indicates the number of IPv6 requests received by BIND DNS. |
Number |
|
Queries resulted in successful answer |
Indicates the number of query which returns a NOERROR response. |
Number |
A high value is desired for this measure. |
Queries resulted in authoritative answer |
Indicates the number of queries that obtained response from the name servers, that have been configured by an original source. |
Number |
An authoritative name server provides actual answer to your DNS queries such as – mail server IP address or web site IP address (A resource record). It provides original and definitive answers to DNS queries. It does not provide just cached answers that were obtained from another name server. Therefore it only returns answers to queries about domain names that are installed in its configuration system. The value of this measure represents the count of queries that were processed by authoritative name servers. |
Queries resulted in non-authoritative answer |
Indicates the number of queries that obtain response from the Non-Authoritative name servers. |
Number |
|
Queries resulted in nxrrset |
Indicates the number of queries for which the name server returned the response NXRRSET. |
Number |
The value of this measure denotes the number of queries the name server handled that resulted in responses saying that the type of record the querier requested did not exist for the domain name it specified. Ideally, the value of this measure should be 0. |
Queries resulted in SERVFAIL |
Indicates the number of queries that resulted in SERVFAIL error. |
Number |
The value of this measure indicates the number of queries that the server failed to complete because of errors when communicating with the delegated name server. Ideally, the value of this measure should be 0. |
Queries resulted in NXDOMAIN |
Indicates the number of queries that resulted in NXDOMAIN error. |
Number |
The NXDOMAIN error occurs when the domain name queried does not exist. Ideally, the value of this measure should be 0. |
Queries resulted in referral answer |
Indicates the number of queries that resulted in a referral answer. |
Number |
The term referral indicates a response to a query which does not contain an answer section (it is empty) but which contains one or more authoritative name servers that are closer to the required query question. |
Duplicate queries received |
Indicates the number of queries which the server attempted to recurse, but discovered an existing query with the same IP address, port, query ID, name, type and class already being processed. |
Number |
|
TCP requests received |
Indicates the number of TCP requests received. |
Number |
|
Auth queries rejected |
Indicates the number of authoritative queries rejected. |
Number |
Ideally, these measures should report the value 0.
|
Recursive queries rejected |
Indicates the number of recursive queries rejected. |
Number |
|
Update requests rejected |
Indicates the number of update requests rejected. |
Number |
|
Responses sent |
Indicates the number of responses sent. |
Number |
|
Queries dropped |
Indicates the number of recursive queries dropped as there exists an excessive number of queries of same name, type and class. |
Number |
Ideally, the value of this measure should be 0. |
Other query failures |
Indicates the number of other query failures. |
Number |
Ideally, the value of this measure should be 0. |
Queries caused recursion |
Indicates the number of NS records that pointed to an incorrect host. |
Number |
A recursive query is one which the server attempts to service using its local cache. If it cannot find an answer, it will query other DNS servers until it finds the answer. The server will then respond to the original query with the results from each server's query. Ideally, the value of this measure should be 0 - i.e., recursion should be disabled. This is because, servers that support recursive queries are vulnerable to fake requests from a spoofed IP address (the victim of the attack). The spoofed IP address can get overwhelmed by the number of DNS results it receives and be unable to serve regular Internet traffic. This is called an Amplifier attack because this method takes advantage of DNS servers to reflect the attack onto a target while also amplifying the volume of packets sent to the victim. A consequence of this activity is that third party Network administrators who detect these requests may block your IP addresses. Your server could even be placed upon DNS blacklists. |
Requests with EDNS(0) received |
Indicates the number of EDNS(0) messages received. |
Number |
Extension mechanisms for DNS (EDNS) is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol which had size restrictions that the Internet engineering community deemed too limited for increasing functionality of the protocol. EDNS adds information to DNS messages in the form of pseudo-Resource Records ("pseudo-RRs") included in the "additional data" section of a DNS message. Note that this section exists in both requests and responses. EDNS introduces a single pseudo-RR type: OPT. As pseudo-RRs, OPT type RRs never appear in any zone file; they exist only in messages, fabricated by the DNS participants. The OPT pseudo-record provides space for up to 16 flags and it extends the space for the response code. The overall size of the UDP packet and the version number (at present 0) are contained in the OPT record. A variable length data field allows further information to be registered in future versions of the protocol. |
Requests with EDNS(0) sent |
Indicates the number of EDNS(0) messages sent. |
Number |