5.13 Finding Out Who's Querying a Name Server

5.13.1 Problem

You want to find out which resolvers and name servers are querying a name server.

5.13.2 Solution

For BIND 9, turn on query logging with:

# rndc querylog

Or, for BIND 8:

# ndc querylog

Then examine the name server's syslog output. The name server will log a one-line message each time it receives a query. For BIND 9, the messages look like this:

May  4 22:45:14 ns1 named[80090]: client 192.168.0.99#3261: query: www.foo.example IN A

This tells us that our name server received a query from the client at 192.168.0.99, port 3261, for A records attached to www.foo.example in the Internet class.

On a BIND 8 name server, the messages look like this:

May  4 22:53:52 ns1 named[80323]: XX+/192.168.0.99/www.foo.example/A/IN

Most of the same information is there, but in a slightly different format: the address the query was received from, the domain name the query asked about, the type of query, and the class of query, separated by slashes . The "XX+" at the beginning indicates that it is a recursive query. Nonrecursive queries show just "XX."

5.13.3 Discussion

Query logging can come in handy if you're trying to track down a problem. However, it generates a lot of output -- quickly , on a busy name server -- so it's probably a bad idea to use all the time. If you're really just interested in how many queries the name server receives, use the name server's statistics instead (Recipes Section 5.14 and Section 5.15).

You can also turn on query logging by assigning the logging category queries to a particular channel. See Recipe Section 10.4 for details.

There's no indication in the BIND 9 query logging output of which queries were recursive and which not.

5.13.4 See Also

Recipes Section 5.14 and Section 5.15, for measuring the queries a name server receives, and Section 10.4, for sending one category of messages to a particular file.

5.14 Measuring a Name Server's Performance

5.14.1 Problem

You want to measure a name server's performance.

5.14.2 Solution

To measure a name server's real performance (that is, the number of queries it answers on an hourly or daily basis), dump statistics periodically and compare the numbers . On a BIND 9.1.0 or later name server, for example, you could use rndc stats to dump statistics hourly with this crontab entry:

0    *    *    *    *    root    rndc stats

Every hour , the name server will append data like this to the statistics file (called named.stats in the name server's working directory, by default):

+++ Statistics Dump +++ (1021327908)
success 5268
referral 57
nxrrset 7938
nxdomain 127
recursion 1946
failure 153
--- Statistics Dump --- (1021327908)

Add the values of success, nxrrset , and nxdomain , and compute the difference between the sums in two successive statistics blocks. Divide by 3600 (seconds) to get the query rate in queries per second.

With BIND 8, you use ndc stats to induce the name server to dump statistics, but the name server's statistics look considerably different than BIND 9's. Here's an example:

++ Name Server Statistics ++    
(Legend)
        RR      RNXD    RFwdR   RDupR   RFail
        RFErr   RErr    RAXFR   RLame   ROpts
        SSysQ   SAns    SFwdQ   SDupQ   SErr
        RQ      RIQ     RFwdQ   RDupQ   RTCP
        SFwdR   SFail   SFErr   SNaAns  SNXD
        RUQ     RURQ    RUXFR   RUUpd
(Global)  
        94 0 22 0 0  35 0 0 0 0  7 242727 30 36 0  242744 0 30 0 0  22 0 0 24272
5 0  182058 0 0 0
-- Name Server Statistics --

This is just part of the statistics output, printed at the end of each block. The information you need is still there: compute the difference between the values for SAns (sent answers) over time to derive the query rate. To find SAns , look at the line under "(Global)". The second number in the third quintet of numbers (242727 in this example) is SAns .

5.14.3 Discussion

BIND 9 didn't support dumping statistics until 9.1.0. Of course, you shouldn't be running anything that old, anyway. Here's a quick key to the meaning of the various BIND 9 statistics:

success

The number of successful queries (those that return a response other than a referral)

referral

The number of queries that resulted in a referral

nxrrset

The number of queries for domain names that didn't own the type of record requested

nxdomain

The number of queries for domain names that didn't exist

recursion

The number of recursive queries for domain names in the zone that required the name server to send one or more queries

failure

The number of queries that resulted in a failure other than NXDOMAIN

For an explanation of the many statistics kept by a BIND 8 name server, see "Understanding the BIND Statistics" in Chapter 7 of DNS and BIND .

You may also want to test a name server's top-end performance: how quickly it can process queries? There's a program included in the BIND 9 distribution called queryperf that helps with that; you'll find it in the contrib /queryperf subdirectory. Though it's shipped with BIND 9, it works by sending standard DNS queries, so you can use it to measure the performance of any kind of name server -- BIND 9, BIND 8, or "other."

To build it, cd to contrib/queryperf and run configure , then run make :

$ cd contrib/queryperf
$ ./configure
$ make

Next, you need to construct an input file, telling queryperf what queries to send to the name server. Each line in the input file must contain a domain name and a type to look up:

www.foo.example A
foo.example SOA

(The class is assumed to be IN , for Internet. If you want to measure a name server's performance in processing Hesiod queries, you're on your own. You're also a weirdo.)

If you want to test a name server's performance answering queries for authoritative zone data, use domain names in zones that the name server is authoritative for. If you want to test a name server's performance resolving queries that require recursion, use domain names outside of the name server's authoritative zones. Also, make sure you choose lots of different domain names, or the name server will quickly cache the answers and you won't get a representative measurement of performance.

Once you've created the input file, run queryperf . Use the - d command-line option to specify the name of the input file. You can specify how long (in seconds) you want the test to run with - l , or that you want to go through the list of queries just once with - 1 . If you give queryperf a time limit and the program exhausts the queries in the input file before the test is over, it'll start again at the beginning. The - s and - p options allow you to specify the server and port you want to query, respectively. The defaults are the local host and port 53. For other command-line options, run queryperf with an option it doesn't understand, like -? .

Here's a sample run of queryperf :

$ queryperf -d input/foo.example -l 60

DNS Query Performance Testing Tool
Version:  $Id: ch05.xml,v 1.3 2002/10/16 20:08:21 becki Exp $

[Status] Processing input data
[Status] Sending queries
[Status] Testing complete

Statistics:

  Parse input file:     multiple times
  Run time limit:       60 seconds
  Ran through file:     0 times

  Queries sent:         265935 queries
  Queries completed:    265935 queries
  Queries lost:         0 queries

  Percentage completed: 100.00%
  Percentage lost:        0.00%

  Started at:           Mon May 13 16:26:28 2002
  Finished at:          Mon May 13 16:27:28 2002
  Ran for:              60.458815 seconds

  Queries per second:   4398.614164 qps

This was a very short test -- 60 seconds -- of queries for domain names in zones my name server is authoritative for, but the performance is impressive nonetheless: nearly 4,400 queries per second.

Note that you probably don't want to run a stress test like this on a production name server during work hours. You may even want to run the name server you're testing on an alternate port, as described in Section 3.26.

5.14.4 See Also

Section 3.26, "Understanding the BIND Statistics" in Chapter 7 of DNS and BIN D , and "Capacity Planning" in Chapter 8.