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
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 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. |