このページはリンク切れを生じないために残してありますが、内容は古くなっていますのでご注意下さい。

authoritativeサーバの比較

dnsperfによるスループットの比較

結果

	BIND 9.1.0(thread無効)	BIND 9.1.0(thread有効)	BIND 9.4.2(thread無効)	BIND 9.4.2(thread有効)	NSD	MaraDNS
最高	10864.627825	10855.978391	20583.289520	17256.392615	54184.284110	17190.500947
平均	10861.232788	10843.362448	20567.283222	17237.035448	54146.693320	17142.327016
最低	10857.627667	10803.149622	20547.601609	17210.563109	54097.826132	17113.859024

数値はQuery Per Sec
それぞれの実装について、5回ずつ計測したが、NSDは1回だけ11860.488182qpsという結果が出ていたので、上の表ではそのデータを除外し、残り4回の平均/最低を記載した。

NSDが圧倒的に速いです。
MaraDNSは、authoritativeサービスに関しては、BIND 9と同程度の速度が出ることがわかりました。
登場当初はBIND 8と比較して遅いと言われたBIND 9ですが、BIND 9.4.2はBIND 9.1.0と比較して、マルチスレッドを無効にしたバイナリでは2倍、マルチスレッドを有効にしたバイナリでも1.7倍の速度が出るようになりました。
BIND 9はFreeBSDではマルチスレッドを有効にすると却って遅いと言われ、9.4.xからは神明ハックにより改善された模様ですが、今回は、マルチスレッドを有効にしたバイナリの方が遅いという結果が出ています。
今回、authoritativeサーバに用いたハードウェアは、dual coreのPentium 4ですが、BIND 9はコア数ではなくプロセッサ数で起動するスレッドの数を決めている模様で(詳細はlib/isc/unix/os.cを参照)、namedは1スレッドで動作していました。そのため、スレッドは動作するものの「マルチ」スレッドではなく、マルチスレッドを無効にしてコンパイルしたバイナリと比較して、オーバヘッドが生じたのではないかと推測します。

先日、諸先輩との雑談の中でこの話をしたところ、複数の方から、コア数ではなくプロセッサ数を反映してスレッド数が決まるのはおかしいという指摘を受けました。まだ追試験/トラブルシューティングはできていませんが、追記しておきます。
トラブルシュートはできました。どうやら、実験時にSMP enabledカーネルを使っていたつもりなのに、そうではなかったようです。カーネルを再コンパイル/インストールしたら、ちゃんと2スレッド起動しました。

www.example2.jpのquery

それぞれのサーバにwww.example2.jpをqtype ANYでqueryしてみました。

BIND 9.x

結果はこちら。
EDNS0を有効にしてqueryすると、additionalセクションにns.example2.jpのAレコードを含んだ533octetの応答を返し、END0を無効にすると、additionalセクションが空の506octetの応答を返します。いずれの場合にもauthoritativeセクションには、www.example2.jpのすべてのAとAAAAを含んでいます。

NSD

結果はこちら。
BIND 9と同様の応答でした。

MaraDNS

デフォルト設定での結果はこちら。
MaraDNSは設定ファイル(mararc)の中のmax_chainというパラメータで、1つのownerに対して返すRRの個数の上限が設定でき、デフォルト値は8です。挙動から判断すると、この値は、すべてのtypeの合計ではなく、それぞれのtype毎に個数を数える模様です。
上のリンク先の結果には、この制限が適用されており、authorityセクションには、www.example2.jpに設定してあるAとAAAAがそれぞれ8個含まれていました。複数回、queryを繰り返しても、末尾が1～8のRDATAだけが順に返り、登場順が変化したり、末尾が9以降のRDATAが返ることはありませんでした。
max_chain=16の設定での結果はこちら。
max_chain=16に設定すると、EDNS0が有効でも無効でも、authorityセクションには、A RRは11個すべてが返っていますが、AAAAは末尾1～8の8個だけが返っており、additionalセクションは空でした。

authorityを持っていないゾーンについてのqueryに対する応答

statusはNXDOMAIN
answerセクションとadditionalセクションは空
authoritativeセクションにrootのSOAを含む

という応答を返しました。

	status	ANSWER	AUTHORITY	ADDITIONAL
BIND 9(rootゾーンあり/recursion yes)	NXDOMAIN	0	1(rootのSOA)	0
BIND 9(rootゾーンあり/recursion no)	NXDOMAIN	0	1(rootのSOA)	0
BIND 9(rootゾーンなし/recursion yes)	SERVFAIL	0	0	0
BIND 9(rootゾーンなし/recursion no)	SERVFAIL	0	0	0
BIND 9(rootゾーンなし/allow-query-cache外)	REFUSED	0	0	0
NSD(normal)	SERVFAIL	0	0	0
NSD(--enable-root-server)	NXDOMAIN	0	1(rootのSOA)	0
MaraDNS(rootゾーンあり/recursive_acl内)	NXDOMAIN	0	1(rootのSOA)	0
MaraDNS(rootゾーンあり/recursive_acl外)	NXDOMAIN	0	1(rootのSOA)	0
MaraDNS(rootゾーンなし/recursive_acl内)	SERVFAIL	0	0	0
MaraDNS(rootゾーンなし/recursive_acl外)	REFUSED	0	0	0

BIND 9は、rootゾーンのauthorityを持つ場合と持たない場合(file "/dev/null")のそれぞれについてnamed.confに


options {
        recursion no;
};

の設定を入れた場合と入れない場合、加えてrootゾーンのauthorityを持たないサーバにallow-query-cacheの外部からqueryした場合の5通りを試しました。
NSDは、configureに--enable-root-serverを与えてコンパイルしたバイナリと、与えずにコンパイルしたバイナリの2通りを試しました。
MaraDNSはrootゾーンのauthorityを持つ場合と持たない場合について、recursive_aclの範囲内からのqueryと範囲外からのqueryの4通りを試しました。
いずれの実装も、通常の設定であれば、空の応答を返すことがわかりました。statusは、ACLに抵触したか否かによって、SERVFAILであったりREFUSEDであったりするようです。
主要(?)DNSサーバの比較へ|DNS関連の情報へ