Benchmarking Authoritative DNS Servers

Abstract

In this paper, we examine the performance of four authoritative DNS server implementations (BIND, NSD, knot DNS, and YADIFA). In our tests, we apply the measurement procedure defined in Section 9 of RFC 8219. Our aim is threefold: to provide DNS operators with ready to use measurement results to support their selection of the best fitting authoritative DNS server implementation for their needs, to assist researchers and DNS64 server developers in finding a suitable authoritative DNS server implementation for their DNS64 benchmarking measurements, and to advance the theory and practice of benchmarking DNS servers. We examine how the different conditions such as the number of active CPU cores, the size of the zone file, the applied timeout, and the type of the processor influence the performance of the tested authoritative DNS server implementations. The performance of all four tested DNS servers scales up more or less well with the number of CPU cores, except for YADIFA. The increase of the size of the zone file causes significant degradation only in the performance of BIND, which shows different anomalies described in the paper. The change of the timeout from 250ms (required by RFC 8219) to 100ms usually causes only a small performance degradation. We point out that NSD and Knot DNS can achieve an order of magnitude higher performance than BIND and YADIFA.

Towards the scalability comparison of the Jool implementation of the 464XLAT and of the MAP‐T IPv4aaS technologies

“…We are aware that it may also be necessary to increase the number of devices at a coarser granularity level, but it is now beyond the scope of our investigations. Now, we follow the same approach as we did when we measured the performance of different DNS64 server or authoritative DNS server implementations as a function of the number of active CPU cores in Lencse and Kadobayashi 12,13 ; that is, we double the number of active CPU cores of the DUT (device under test) and execute the performance measurements using 1, 2, 4, 8, and 16 CPU cores.…”

“…As for the testing tool, we have chosen dns64perf++, which was written as an RFC 8219 compliant benchmarking tool for DNS64 servers, 15 and it was successfully used for that purpose by Lencse and Kadobayashi 12 and later (after the increase of its performance by enabling it to use multiple sending and receiving threads), it was also suitable for benchmarking authoritative DNS servers. 13 Moreover, it was also used as an additional testing tool to measure the scale-up of the performance of the different examined SIIT implementations as a function of the number of active CPU cores. 16 In that paper, we used dns64perf++ as a packet sending and receiving application together with an authoritative DNS server, the task of which was to send replies for the DNS queries.…”

“…Hyper-threading was switched off from the BIOS of the computers to achieve more stable measurement results. 13 The Debian Linux operating system was upgraded to version 10.11 with kernel version 4.19.…”

“…The zone file was created in the same way as described by Lencse. 13 The IPv4 client and IPv4 server computers always used all 32 cores, whereas the number of the active cores of the two other computers was set by the "maxcpus=X" Linux kernel command line parameter to 1, 2, 4, 8, or 16.…”

Adding RFC 4814 Random Port Feature to Siitperf: Design, Implementation and Performance Estimation

“…We believe that the results of such measurements do not reflect the real life performance of a multi-core DUT well enough, because a high number of different IP addresses and different port numbers occur in a real life traffic, thus the interrupts are hashed more or less equally to all CPU cores. Therefore, we were planning to use a non-standard solution of increasing the source port numbers one by one, which we have successfully used with the new version of dns64perf++ [12], when it was necessary for benchmarking high performance authoritative DNS servers [13].…”