BIND 9の運用情報収集と分析方法：実用 BIND 9で作るDNSサーバ（10）（1/2 ページ）

BINDが正常に動作しているように見えても、実は高負荷で悲鳴をあげているかもしれない。BINDのロギング機能やデバッグ情報出力、MRTGなどを活用して、BINDの状態を把握できるようにしておこう。（編集局）

[鶴長鎮一，＠IT]

　Webやメール、DNSなど、サーバと呼ばれるものは動いていれば問題ないと考えていないでしょうか？ 一度設定が完了したからといって、メンテナンスをおろそかにするようでは にわか管理者のらく印を押されることになります。そこで、メンテナンスの第一歩であるBIND 9の情報収集と分析方法について解説します。

ログ出力の設定

　BIND 9は、/var/log/messageなどsyslogデーモンを経由したログだけでなく、BIND 9独自のロギングを備えています。第9回では簡単に紹介しただけでしたが、今回はsecurity／client以外のログカテゴリも見ていきましょう。

ロギング機能の基礎

　BIND 9のロギング制御は、named.confで行います。channelでログの出力方法、categoryで出力するログの種類を指定します。

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

　もう少し詳しく説明しましょう。ログの出力方法は、loggingセクション中のchannelで定義します（2〜8行目）。ローカルファイルにログを出力する場合、出力ファイルをフルパスで指定し、ログローテーションで保存する世代数とローテーションする際の上限ファイルサイズを続けて記述します。「世代数」は0〜2147483647の整数またはunlimitedを指定します。unlimitedを指定した場合、99世代までローテーションします。「サイズ」にはK／k、M／m、G／gを単位に添えることができます。

　ログメッセージの保存先はローカルファイル以外に、syslogデーモンに送信したり破棄することができます。

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

チャネルの使用

　ログを破棄する場合は「file null;」を使うよりも、デフォルトで定義されているnullチャネルを使用するのが便利です。

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

　同様に、syslogデーモンや標準エラーに出力させる場合もデフォルトで定義されているdefault_syslogとdefault_stderrチャネルの使用が可能です。

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

　このほかに、namedのデバッグモードのためのdefault_debugチャネルが定義されています。namedのデバッグモードについては後述します。

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

　channelの説明に戻ります。print-time、print-severity、print-categoryはログファイル中の日時、ログレベル、ログカテゴリの表示・非表示を切り替えます。

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

カテゴリの定義

　channelだけ定義しても、ロギングそのものは行われません。channel定義は出力方法を規定するだけで、どのようなログを出力するかはcategoryで定義します（10行目）。

　多くの場合、defaultと特別に記録したいもの（マスター／セカンダリサーバであればxfer-in／xfer-out、DDNSを使用している場合はupdateなど）を指定します。使用できるカテゴリは、表1から用途に合わせて1つだけ記述します。

カテゴリ	内容
database	ゾーン情報やキャッシュ情報など、データベースに関連する記録
security	要求の承認／否認の記録
config	構成ファイルの構文解析と処理の記録
resolver	クライアントに代わって実行されるキャッシュサーバの動作に代表される、再帰検索のようなDNS解決の記録
xfer-in	サーバが受信したゾーン転送の記録
xfer-out	サーバが送信したゾーン転送の記録
notify	NOTIFY（通知）プロトコルの記録
client	クライアント要請の処理記録
network	ネットワーク操作の記録
update	DDNSの記録
queries	問い合わせクエリーの記録
dispatch	サーバモジュールへ入ってくるパケットを処理するCPU割り当て（ディスパッチ）の記録
dnssec	DNSSECやTSIG処理の記録
lame-servers	DNS解決の際にほかのサーバで見つけた設定ミス（lame）の記録
general	上記以外の多くのログはカテゴリが未分類であり、それらはgeneralに分類される
default	categoryで意図的に指定された以外のカテゴリがここで定義される
表1　指定できるカテゴリ

　チャネル名には先ほどchannelで定義したチャネル名や、default_syslog、default_stderr、default_debugを指定します。複数指定することも可能です。

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

各種情報出力の活用

クエリーの完全な記録

　前回、攻撃元を特定するため、問い合わせクエリーをすべて記録する手法としてクエリーログを紹介しました。

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

　この方法はサーバのリソースを多く消費します。そこで、欲しいときに、それもnamedの再起動を伴わずにクエリーログを取得する方法がrndcコマンドで提供されています。rndcコマンドにquerylogを指定すると、いままでクエリーログが無効であれば有効に、有効であれば無効に変わります。

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

デバッグ出力

　BINDには、より詳細な動作検証を行うため、デバッグ情報を段階的に出力できます。本来、デバッグ情報はnamedなど特定ソフトウェアのバグ取り作業に用いられますが、メッセージをうまくくみ取ることでBINDの動作検証に活用できます。

　デバッグメッセージを出力させるには、named起動時にオプションを指定するか、rndcコマンドで出力を制御します。

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

　デバッグメッセージは/var/named/named.runファイル（注）に出力されます。

注：named.confでワークディレクトリ（/var/named）を変更している場合は、指定されたディレクトリ下のnamed.run。

　デバッグレベルには0〜99の整数を指定します。デバッグレベルが大きい（高い）ほど、表示されるメッセージが詳細になります。デバッグレベルを付加せずにtraceとだけすると、デバッグレベルが1段上がります。デバッグ出力の停止はrndcコマンドでnotraceまたはtrace 0を指定します。

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

　出力先は、前述したチャネル定義「default_debug」が使用されます。ファイル名やファイルサイズなど、出力方法を変更する場合はloggingセクション中のchannel文でdefault_debug定義を上書きします。

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

キャッシュデータのダンプ

　サーバの正しいIPアドレスが得られない場合はdigやhostコマンドで確認しますが、キャッシュされているメモリ内のデータを出力させることもできます。

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

　デフォルトの出力先は、ワークディレクトリ（/var/named）のnamed_dump.dbファイルです。出力先を変更したい場合は、named.confで新しい出力先を指定します。

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

　named_dump.dbファイルに出力されるキャッシュ情報には、

• glue
• authanswer
• authauthority
• answer
• additional

などの見出しが付加されます。

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