| dnsperf(1) | General Commands Manual | dnsperf(1) |
dnsperf - test the performance of a DNS server
dnsperf [-a local_addr] [-b bufsize] [-B] [-c clients] [-d datafile] [-D] [-e] [-E code:secret] [-f family] [-h] [-l limit] [-m mode] [-n runs_through_file] [-p port] [-q num_queries] [-Q max_qps] [-s server_addr] [-S stats_interval] [-t timeout] [-T threads] [-u] [-v] [-W] [-x local_port] [-y [alg:]name:secret] [-O option=value]
dnsperf is a DNS server performance testing tool. It is primarily intended for measuring the performance of authoritative DNS servers, but it can also be used for measuring caching server performance in a closed laboratory environment. For testing caching servers resolving against the live Internet, the resperf program is preferred.
It is recommended that dnsperf and the name server under test be run on separate machines, so that the CPU usage of dnsperf itself does not slow down the name server. The two machines should be connected with a fast network, preferably a dedicated Gigabit Ethernet segment. Testing through a router or firewall is not advisable.
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.
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.
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
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.
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.
-a local_addr
-b bufsize
-B
These binary datafiles can be generated using arbitrary TCP listeners such as netcat (nc) and sockat. TCP must be used so that the length is prepended. Following example shows how to generate a datafile with two query and then using it, you need two terminals.
(terminal 1) $ nc -l 127.0.0.1 5300 > dns.blob (terminal 2) $ echo "example.com A" | dnsperf -s 127.0.0.1 -p 5300 -m tcp (terminal 1) $ nc -l 127.0.0.1 5300 >> dns.blob (terminal 2) $ echo "example.com AAAA" | dnsperf -s 127.0.0.1 -p 5300 -m tcp (terminal 1) $ dnsperf -B -d dns.blob -s $IP
-c clients
-d datafile
-D
-e
-E code:value
-f family
-h
-l limit
-n runs_through_file
-p port
-q num_queries
-Q max_qps
-m mode
-s server_addr
-S stats_interval
-t timeout
-T threads
-u
-v
-W
-x local_port
If acting as multiple clients and the wildcard port is used, each client will use a different random port. If a port is specified, the clients will use a range of ports starting with the specified one.
-y [alg:]name:secret
-O option=value
doh-uri=URI
doh-method=HTTP_METHOD
tls-sni=SERVER_NAME
suppress=MESSAGE[,MESSAGE,...]
timeouts: Suppress messages about queries being timed out
congestion: Suppress messages about network congestion
sendfailed: Suppress messages about failure to send packets or if only
parts of the packet were sent
sockready: Suppress messages about socket readiness
unexpected: Suppress messages about answers with an unexpected message
ID
verbose-interval-stats
Please note: Min/max values for latency and connections are not available in interval statistics. Number of answers received within stats_interval can legitimately exceed number of queries sent, depending on answer latency, configured timeout, and stats_interval.
Only available in dnsperf.
latency-histogram
Only available in dnsperf and if compile time support was detected.
qps-threshold-wait=<microseconds>
If the time between queries is lower then this, then no wait is performed in order to have more precision on when to send the next query. This is because during high QPS rate limiting it can take more time just calling the functions to wait for when to send the next query then the actually time between queries.
If not set, the average call-time to nanosleep() will be measured during startup.
Only available in dnsperf.
resperf(1)
Nominum, Inc.
Maintained by DNS-OARC
For issues and feature requests please use:
For question and help please use:
| 2.14.0 | dnsperf |