DNS 用のストレスツールを比較しました。
※ここでは実際に設定、動作したものを掲載していますが、内容について保証するものではありません。流用される場合は各自の責任でお願いします。
評価対象のストレスツールは以下のとおりです。
- dnsperf
- kxdpgun
- dnstcpbench
検証環境の物理構成およびソフトウェアスタックは下図のとおりです。

ツール検証の詳細については以下をご参照ください。
主な比較項目は下表のとおりです。
dnsperf | kxdpgun | dnstcpbench | |
---|---|---|---|
1.RD(Recursion desired) | 1 | 1 | 0 |
2.トランスポート | UDP | UDP | TCP |
3.TCP フォールバック | 非対応 | 非対応 | 対応 |
4.試験期間の指定 | 可 | 可 | 不可 |
5.qps の指定 | 可 | 可 | 不可 |
6.timeout の指定 | 可 | 不可 | 可 |
1.RD(Recursion desired)
DNS パケットの RD フラグが 1 ならば再帰問い合わせ、0 ならば非再帰問い合わせ(反復問い合わせ)です。再帰問い合わせは、クライアント(スタブリゾルバ)からキャッシュ DNS への問い合わせ、非再帰問い合わせは、キャッシュ DNS から権威 DNS への問い合わせです。
2.トランスポート
以前は UDP が優先だったようですが、現在は UDP と TCP のどちらが優先ということはないようです。dnsperf と kxdpgun のデフォルトは UDP ですが、オプション指定で TCP での送信も可能です。dnstcpbench のデフォルトは TCP ですが、オプション指定で UDP での送信も可能です。ただし、dnstcpbench で試験を行う場合は TCP が基本で、UDP は TCP フォールバックを確認するためにあるようです。dnstcpbench の結果表示では、UDP のクエリは正しく集計されていないように見えます。
3.TCP フォールバック
UDP でのクエリの際、要求した RR(Resource Record)のサイズが大きいと、レスポンスの truncated フラグが 1(切り捨て)で返ることがあります。このレスポンスを受けて、同じクエリを TCP でやり直す処理を TCP フォールバックといいます。ちなみに dig は TCP フォールバックに対応しています。
4.試験期間の指定
dnsperf と kxdpgun には試験期間を指定するオプションがありますが、それぞれ考え方が少し異なります。
dnsperf では指定時間までクエリ処理を継続しますが、クエリデータが尽きれば時間前でもクエリ処理を終了します。kxdpgun でも指定時間までクエリ処理を継続しますが、クエリデータが尽きると再利用され、時間いっぱいまでクエリ処理を継続します。
dnstcpbench には試験期間を指定するオプションは見当たりませんでした。
5.qps の指定
dnsperf と kxdpgun では qps の指定が可能です。内部仕様を確認したわけではないのでここからは憶測になります。
dnsperf では指定した qps をリミット(上限)として、環境にあわせてクエリの送信量を調整しているようです。例えば、timeout が頻発するような環境では送信量を意図的に下げて、timeout の発生を抑えているように見えます。
kxdpgun では指定した qps をリミット(上限)として、環境のスペックが許す限りできるだけ多くのクエリリクエストを送信しようとしているように見えます。timeout の発生を抑える等の調整等は行われていないようです。
dnstcpbench には qps を指定するオプションは見当たりませんでした。
6.timeout の指定
dnsperf と dnstcpbench では クエリ毎の timeout 値の指定が可能です。kxdpgun では timeout 値を指定するためのオプションは見当たりませんでした。dnsperf と dnstcpbench の結果には timeout 件数が集計されていますが、kxdpgun の結果にはその集計もありません。timeout のデフォルト値も示されておらず、timeout という概念があるかどうかも不明です。あえて確認するならば、リクエスト件数(total queries)とレスポンス件数(total replies)は出力されているので、その差分が timeout 件数ではないかと推測できます。