Configuring the name server

If using dnsperf to test an authoritative server, the name server under test should be set up to serve one or more zones similar in size and number to what the server is expected to serve in production.

Also, be sure to turn off recursion in the server's configuration (in BIND 8/9, specify "recursion no;" in the options block). In BIND 8, you should also specify "fetch-glue no;"; otherwise the server may attempt to retrieve glue information from the Internet during the test, slowing it down by an unpredictable factor.

Constructing a query input file

A dnsperf input file should contain a large and realistic set of queries, on the order of ten thousand to a million. The input file contains one line per query, consisting of a domain name and an RR type name separated by a space. The class of the query is implicitly IN.

When measuring the performance serving non-terminal zones such as the root zone or TLDs, note that such servers spend most of their time providing referral responses, not authoritative answers. Therefore, a realistic input file might consist mostly of queries for type A for names *below*, not at, the delegations present in the zone. For example, when testing the performance of a server configured to be authoritative for the top-level domain "fi.", which contains delegations for domains like "helsinki.fi" and "turku.fi", the input file could contain lines like

www.turku.fi A
www.helsinki.fi A

where the "www" prefix ensures that the server will respond with a referral. Ideally, a realistic proportion of queries for nonexistent domains should be mixed in with those for existing ones, and the lines of the input file should be in a random order.

Constructing a dynamic update input file

To test dynamic update performance, dnsperf is run with the -u option, and the input file is constructed of blocks of lines describing dynamic update messages. The first line in a block contains the zone name:

example.com

Subsequent lines contain prerequisites, if there are any. Prerequisites can specify that a name may or may not exist, an rrset may or may not exist, or an rrset exists and its rdata matches all specified rdata for that name and type. The keywords "require" and "prohibit" are followed by the appropriate information. All relative names are considered to be relative to the zone name. The following lines show the 5 types of prerequisites.

require a
require a A
require a A 1.2.3.4
prohibit x
prohibit x A

Subsequent lines contain records to be added, records to be deleted, rrsets to be deleted, or names to be deleted. The keywords "add" or "delete" are followed by the appropriate information. All relative names are considered to be relative to the zone name. The following lines show the 4 types of updates.

add x 3600 A 10.1.2.3
delete y A 10.1.2.3
delete z A
delete w

Each update message is terminated by a line containing the command:

send

Running the tests

When running dnsperf, a data file (the -d option) and server (the -s option) will normally be specified. The output of dnsperf is mostly self-explanatory. Pay attention to the number of dropped packets reported - when running the test over a local Ethernet connection, it should be zero. If one or more packets has been dropped, there may be a problem with the network connection. In that case, the results should be considered suspect and the test repeated.

Using DNS-over-HTTPS

When using DNS-over-HTTPS you must set the -O doh-uri=... to something that works with the server you're sending to. Also note that the value for maximum outstanding queries will be used to control the maximum concurrent streams within the HTTP/2 connection.