Bind Resolver Statistics Test

A resolver is a program that resolves questions about names by sending those questions to appropriate servers and responding appropriately to the servers’ replies. In the most common application, a web browser uses a local stub resolver library on the same computer to look up names in the DNS. That stub resolver is part of the operating system. (Many operating system distributions use the BIND resolver library.) The stub resolver usually will forward queries to a caching resolver, a server or group of servers on the network dedicated to DNS services. Those resolvers will send queries to one or multiple authoritative servers in order to find the IP address for that DNS name.

This means that latencies/errors experienced by the resolver can cause overall query processing by BIND DNS to significantly slow down. This is why, where name resolution queries take too long to provide answers, administrators should look at how much time the resolver program took to process those queries and if any queries failed at the resolver. The Bind Resolver Statistics test provides administrators with this insight.

This test monitors the queries sent/forwarded by the resolver program , and measures the average round trip time of the queries. Administrators are alerted if even one query registers an abnormally high round trip time. Query failures are also brought to the immediate attention of administrators, so that they can investigate the reason for the same and fix it. In addition, the test also tracks the responses received by the resolver program to queries it forwarded. In the process, the test sheds light on error responses and the probable reason for those errors.

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 queries sent

Indicates the number of IPv4 queries sent by the resolver.

Number

These are good measures of the current workload of the resolver program.

IPv6 queries sent

Indicates the number of IPv6 queries sent by the resolver.

Number

IPv4 responses received

Indicates the number of IPv4 responses received by the resolver.

Number

IPv6 responses received

Indicates the number of IPv6 responses received by the resolver.

Number

Queries resulted in successful answer

Indicates the number of queries which returned a NOERROR response.

Number

A high value is desired for this measure.

Queries with RTT less than 10ms

Indicates the number of queries with round trip time (RTT) less than 10 ms.

Number

A high value is desired for this measure.

Queries with RTT 10 to 100ms

Indicates the number of queries with round trip time (RTT) between 10 ms and 100 ms.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more queries are slow.

Queries with RTT 100 to 500ms

Indicates the number of queries with round trip time (RTT) between 100 ms and 500 ms.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more queries are slow.

Queries with RTT 500 to 800ms

Indicates the number of queries with round trip time (RTT) between 500 ms and 800 ms.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more queries are slow.

Queries with RTT 800 to 1600ms

Indicates the number of queries with round trip time (RTT) between 800 ms and 1600 ms.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more queries are slow.

Queries with RTT more than 1600ms

Indicates the number of queries with round trip time (RTT) over 1600 ms.

Number

Ideally, the value of this measure should be 0. A non-zero value indicates that one/more queries are slow.

NXDOMAIN received

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.

SERVFAIL received

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.

FORMERR received

Indicates the number of queries that resulted in FORMERR error.

Number

A non-zero value of this measure indicates that one/more FORMERR errors have occurred.

A FORMERR refers to a DNS query format error.

Other errors received

Indicates the number of queries that resulted in errors other than the NXDOMAIN, SERVFAIL, and FORMERR errors.

Number

Ideally, the value of this measure should be 0.

Query retries

Indicates the number of query retries that were performed by the resolver program.

Number

Higher the number of retries slower will be query processing. Ideally therefore, this measure value should be very low.

Query timeouts

Indicates the number of query timeouts.

Number

The default timeout value for the first round of queries at the resolver is 5 seconds er name server. After each round of queries, the resolver doubles the initial timeout. BIND 8.2 and previous resolvers send a total of four rounds of queries; BIND 8.2.1 and later resolvers send two. There is no way to modify the timeouts in a Windows resolver. However, the default timeouts are fairly short in newer Windows resolvers (one second for the first query in Windows 2000, for example), so adjusting them may not be necessary.

Lame delegations received

Indicates the number of queries that could not be serviced due to lame delegations.

Number

A lame delegation occurs when an authoritative DNS server (eg. .com) has a delegation (eg.lamedelegation.com) to other DNS server that are not authoritative for this zone.

Ideally, the value of this measure should be 0.

IPv4 NS address fetches

Indicates the number of IPv4 NS address fetches invoked.

Number

IPv4 NS address fetch failed

Indicates the number of IPv4 NS address fetches failed.

Number

Ideally, the value of this measure should be 0.

EDNS(0) query failures

Indicates the number of EDNS(0) query failures.

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-RR"s) 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.

Ideally, the value of this measure should be 0.