Tweet

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

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

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

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

　（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」のようなエラーが記録されるようになった場合に変更すればよいでしょう。

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

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

（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のタイムアウトは行われません。キャッシュデータでメモリを食い尽くされたくない場合に指定します。

1/2

Index 実用 BIND 9で作るDNSサーバ 　第11回　BIND 9のチューニングと大規模運用

Page 1 OSリソースのチューニング キャッシュサーバのチューニング 　 Page 2 ゾーン転送のチューニング 　スレーブサーバ側 　マスターサーバ側 $GENERATEの利用 設定ファイルの確認 　BIND 9ユーティリティの利用 　dnswalkの利用

連載 実用 BIND 9で作るDNSサーバ

	連載：Heartbeatでかんたんクラスタリング（連載中） オープンソースソフトウェアの「Heartbeat」を使ってHAクラスタを実現し、サービスを「落とさない」仕組みを実現します
	特集：Apache 2.2でWebサイトをパフォーマンスアップ！ 最新安定版Apache 2.2は、何が変わったのか？ 最新のApacheを新機能の使い方とともに解説する
	連載：実用 Apache 2.0運用・管理術（全8回） 本連載では、Apache 2.0の運用や管理方法を解説する。まず必須設定と基本的なセキュリティ対策を行い今後の運用に備える
	連載：実用 BIND 9で作るDNSサーバ（全15回） 本連載では、BIND 9の構築／運用方法を解説していく。実際に役立つことを目的に、セキュリティや大規模運用などのテーマを取り上げていく
	連載：実用qmailサーバ運用・管理術（全14回） 本連載を通して、qmailによるメールサーバの高度な構築・運用・管理術を紹介。SPAM対策やML管理からサーバでのウイルスチェックなどまで
	特集：Samba 3.0の全貌 改訂版 Samba 3.0リリースから8カ月。ここであらためて、Samba 3.0系列の新機能、インストール方法、国際化の現状を解説する
	more

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）

RSSフィード