BIND 9のチューニングと大規模運用：実用 BIND 9で作るDNSサーバ（11）（1/2 ページ）

今回は、大規模運用において特に必要となるBIND 9のチューニング方法を中心に紹介する。また、設定ファイルをチェックするためのツールにも触れる。（編集局）

[鶴長鎮一，＠IT]

　BINDの主な設定はnamed.confとゾーンファイルに集約されています。特に、named.confに1行加えるだけでBINDの振る舞いは大きく変わります。今回は、BIND 9のチューニングと、大きなゾーンファイルを扱うような場合の注意点を紹介します。

OSリソースのチューニング

　named（BIND）が扱えるOSのリソースは無限ではありません。Linuxでは、1つのプロセスに割り当てられるリソースがあらかじめ決められています。ulimitコマンド（Cシェル系はlimitコマンド）で、現在の上限値が確認できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　これらの値はulimit／limitコマンドで変更します（コラム「ulimitとlimit」参照）が、namedプロセスに割り当てるリソースはnamed.confファイルでも設定できます。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　（1）〜（3）の<値>は、k／m／g（kbyte／Mbyte／Gbyte）を単位とする数値指定に加え、default／unlimitedを用いることができます。defaultはサーバの規定値（「ulimit -a」で表示される値）が使用され、unlimitedは取り得る最大の値を確保します。数値はlong integerの範囲（0〜2147483647）が指定できますが、安全な設定を施す場合はunlimitedを指定します。

（1）データセグメントサイズの上限

　「ulimit -a」の結果からも分かるように、カーネル2.4ではデータセグメントサイズはすでにunlimitedが指定されており、特に変更の必要はありません。また、データセグメントサイズを小さくしてもキャッシュデータサイズを抑えることはできません。キャッシュデータサイズはmax-cache-size（後述）で決まります。

（2）スタックサイズの上限

　スタックサイズもデフォルトの8192kbytesで十分です。「Segmentation fault」が起こるような場合のみ、より大きな値を指定します。

（3）コアファイルのサイズ上限

　コアファイルのサイズ指定は各管理者のポリシーに委ねられます。コアファイルはプログラムやプロセスが異常終了した際に、メモリの状態をダンプして障害の原因究明に利用します。より詳細な情報が欲しい場合はcoresizeを大きくします。

（4）オープンできるファイルディスクリプタの最大数

　ファイルディスクリプタの最大数のデフォルトは1024です。ゾーンファイルが1024以上ある場合はもちろん、ログに「Too many open files」のようなエラーが記録されるようになった場合に変更すればよいでしょう。

コラム　ulimitとlimit

　ulimitコマンドは以下のように使用します。ただし一般ユーザーで実行した場合は設定の変更はできません。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

-d	データセグメントの最大サイズ
-n	オープンできるファイルディスクリプタの最大数（カーネル2.2ではカーネルの再構築が必要）
-s	最大スタックサイズ
ulimitの主なオプション。詳細は「$ man bash」などで確認できる

　Cシェル系のlimitコマンドは以下のように使用します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

　引数にはdatasize、descriptors、stacksizeのように変更するリソースとその上限値を指定します（limitの詳細は「$ man tcsh」などで確認できます）。

キャッシュサーバのチューニング

　キャッシュサーバに有効な設定は第4回でも紹介していますが、ここでは第9回で紹介した「再帰問い合わせ数の制限」についても補足します。

*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***

（1）ネガティブキャッシュの最大TTL

　デフォルトは10800秒（3時間）です。

（2）キャッシュの最大TTL

　デフォルトは604800秒（1週間）です（第4回参照）。

（3）再帰問い合わせの同時要求数

　デフォルトで1000が指定されていますが、ログに「no more recursive clients: quota reached」のようなメッセージが記録された場合は、直ちにより大きな値を指定する必要があります。ただし、1つのクエリーに対して20kbytesほどのメモリを必要とするため、recursive-clients×20kbytesがサーバに搭載されているメモリ容量を上回らないように注意しなければなりません。

　ワームなどに侵されたPCによる攻撃で一時的にクエリーが増加する場合もあるため、単純にrecursive-clientsを増やすのみではサーバのリソースを浪費するだけです。第10回を参考に、日ごろのメンテナンスや運用監視を怠らないようにしましょう。

（4）キャッシュデータ中のTTL切れのデータを整理する間隔

　BIND 4では、キャッシュの整理は問い合わせクエリーに返答する際にTTLが切れているか否かを問い合わせごとに照合し、切れていればキャッシュデータを無視して新しく問い合わせを行っていました。この方法では、TTLが切れているキャッシュ情報もキャッシュデータに残ったままとなります。

　BIND 9では、一定時間ごとにTTLが切れているか否かを照合し、キャッシュデータの整理を行うように修正されました。cleaning-intervalは、その整理を行う間隔を指定します。デフォルトでは60分に1度クリーニングプロセスが起動しますが、キャッシュデータが頻繁に書き換わらないような環境であれば間隔を長く、キャッシュデータが目まぐるしく変化し、少しでもキャッシュデータ容量を稼ぎたい場合は間隔を短くします。BIND 4と同様に、キャッシュの整理を行わないようにするには0を指定します。

（5）lame情報のTTL

　lame情報を保持することで、BIND 9は無駄な問い合わせを減らすことができます。デフォルトで600秒が指定されており、特に変更の必要はありません。0〜1800（30分）の設定が可能ですが、0を指定してlame情報を保持しないようにすることはあまり行われません。意外に多くのlame情報がはんらんしています。

（6）キャッシュデータに使用するメモリの最大量

　キャッシュのデータサイズがmax-cache-sizeに達すると、BIND 9はキャッシュのTTLを意図的にタイムアウトさせます。するとクリーニングプロセスが起動されたときに強制的に削除されるため、キャッシュデータが指定サイズに収まるというわけです。デフォルトはunlimited（無制限）で、意図的なTTLのタイムアウトは行われません。キャッシュデータでメモリを食い尽くされたくない場合に指定します。