BINDが正常に動作しているように見えても、実は高負荷で悲鳴をあげているかもしれない。BINDのロギング機能やデバッグ情報出力、MRTGなどを活用して、BINDの状態を把握できるようにしておこう。(編集局)
Webやメール、DNSなど、サーバと呼ばれるものは動いていれば問題ないと考えていないでしょうか? 一度設定が完了したからといって、メンテナンスをおろそかにするようでは にわか管理者のらく印を押されることになります。そこで、メンテナンスの第一歩であるBIND 9の情報収集と分析方法について解説します。
BIND 9は、/var/log/messageなどsyslogデーモンを経由したログだけでなく、BIND 9独自のロギングを備えています。第9回では簡単に紹介しただけでしたが、今回はsecurity/client以外のログカテゴリも見ていきましょう。
BIND 9のロギング制御は、named.confで行います。channelでログの出力方法、categoryで出力するログの種類を指定します。
logging { |
/etc/named.conf |
もう少し詳しく説明しましょう。ログの出力方法は、loggingセクション中のchannelで定義します(2〜8行目)。ローカルファイルにログを出力する場合、出力ファイルをフルパスで指定し、ログローテーションで保存する世代数とローテーションする際の上限ファイルサイズを続けて記述します。「世代数」は0〜2147483647の整数またはunlimitedを指定します。unlimitedを指定した場合、99世代までローテーションします。「サイズ」にはK/k、M/m、G/gを単位に添えることができます。
ログメッセージの保存先はローカルファイル以外に、syslogデーモンに送信したり破棄することができます。
file syslog ( syslogのファシリティ ); |
syslogデーモンに送信する場合 注:syslogのファシリティは「facilityで指定できるキーワード」参照。 |
file stderr; |
標準エラーに出力する場合 |
file null; |
破棄する場合 |
ログを破棄する場合は「file null;」を使うよりも、デフォルトで定義されているnullチャネルを使用するのが便利です。
channel "null" { |
同様に、syslogデーモンや標準エラーに出力させる場合もデフォルトで定義されているdefault_syslogとdefault_stderrチャネルの使用が可能です。
channel "default_syslog" { |
syslogデーモンに送信する場合 |
channel "default_stderr" { |
標準エラーへ出力する場合 |
このほかに、namedのデバッグモードのためのdefault_debugチャネルが定義されています。namedのデバッグモードについては後述します。
channel "default_debug" { |
named.runファイルへ出力する場合 |
channelの説明に戻ります。print-time、print-severity、print-categoryはログファイル中の日時、ログレベル、ログカテゴリの表示・非表示を切り替えます。
Sep 30 13:34:35.878 general: info: zone localhost/IN: loaded serial 42 |
例:print-time、print-severity、print-categoryをyesにした場合。 Sep 30 13:34:35.878:日時表示 general:カテゴリ表示 info:ファシリティ表示 |
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を指定します。複数指定することも可能です。
category カテゴリ名 { |
前回、攻撃元を特定するため、問い合わせクエリーをすべて記録する手法としてクエリーログを紹介しました。
logging { |
named.conf |
この方法はサーバのリソースを多く消費します。そこで、欲しいときに、それもnamedの再起動を伴わずにクエリーログを取得する方法がrndcコマンドで提供されています。rndcコマンドにquerylogを指定すると、いままでクエリーログが無効であれば有効に、有効であれば無効に変わります。
# rndc querylog ←1回目の実行 |
BINDには、より詳細な動作検証を行うため、デバッグ情報を段階的に出力できます。本来、デバッグ情報はnamedなど特定ソフトウェアのバグ取り作業に用いられますが、メッセージをうまくくみ取ることでBINDの動作検証に活用できます。
デバッグメッセージを出力させるには、named起動時にオプションを指定するか、rndcコマンドで出力を制御します。
# /usr/local/sbin/named -u named -d デバッグレベル |
named起動時のオプションで指定する方法 |
# rndc trace デバッグレベル |
rndcコマンドでデバッグ出力を切り替える方法 注:rndcのインストールについては第5回参照。 |
デバッグメッセージは/var/named/named.runファイル(注)に出力されます。
デバッグレベルには0〜99の整数を指定します。デバッグレベルが大きい(高い)ほど、表示されるメッセージが詳細になります。デバッグレベルを付加せずにtraceとだけすると、デバッグレベルが1段上がります。デバッグ出力の停止はrndcコマンドでnotraceまたはtrace 0を指定します。
# rndc trace |
デバッグレベルを現在より1段上げる |
# rndc notrace |
デバッグ出力の停止 |
出力先は、前述したチャネル定義「default_debug」が使用されます。ファイル名やファイルサイズなど、出力方法を変更する場合はloggingセクション中のchannel文でdefault_debug定義を上書きします。
logging { |
/var/named/debug.fileへ出力する場合 |
Oct 03 00:27:55.131 general: debug 1: now using logging configuration from config file |
デバッグレベル1起動時のメッセージ(print-time、print-severity、print-categoryをyesにした場合) 注:本来ソフトウェアのバグ取りのための機能ですが、ある程度は解読可能です。 |
サーバの正しいIPアドレスが得られない場合はdigやhostコマンドで確認しますが、キャッシュされているメモリ内のデータを出力させることもできます。
# rndc dumpdb |
/var/named/named_dump.db |
デフォルトの出力先は、ワークディレクトリ(/var/named)のnamed_dump.dbファイルです。出力先を変更したい場合は、named.confで新しい出力先を指定します。
options { |
named_dump.dbファイルに出力されるキャッシュ情報には、
などの見出しが付加されます。
; authauthority |
/var/named/named_dump.dbの一例 |
Copyright © ITmedia, Inc. All Rights Reserved.