category

 

 

categoly節

既存のカテゴリだけでもたくさんあるので、特に設定しなくても多くの選択肢があります。どこのログを送りたい（送りたくない）のかを設定できる。何もしなければデフォルトチャネルにログが送られます。defaultを指定しない場合default defaultが使用されます。

category default {
??? default_syslog;
??? default_debug;
};

セキュリティイベントをログとして保存したい場合には以下のように設定します。

channel my_security_channel {
??? file “my_security_file”;
??? severity info;
};

category security {
??? my_security_channel;
??? default_syslog;
??? default_debug;
};

全てのログを削除するには以下のように設定します。（おすすめはしませんが＾＾；）

category xfer-out { null; };
category notify { null; };

 

利用可能なカテゴリ

以下に挙げるものが設定されているカテゴリの一覧です。

 

default

デフォルトのログカテゴリです。ログカテゴリが設定されていない場合はココに含まれます。

 

general

どこにも属さないものはこのカテゴリとして扱われます。

 

database

Bindが内部的に保持しているゾーン情報や、キャッシュに関するログカテゴリです。

 

security

リクエストの許可/拒否に関わるログカテゴリです。

 

config

設定ファイルの処理に関するログカテゴリです。

 

resolver

クライアントの依頼で再帰問い合わせを行った場合など、DNSの名前解決を行った場合のログカテゴリです。

 

xfer-in

自Bindに対して転送されたzoneに関するログカテゴリです。

 

xfer-out

自Bindが送信したzoneに関するログカテゴリです。

 

notify

DNSのNotifyプロトコルに関するログカテゴリ。

 

client

クライアントリクエスト処理に関わるログカテゴリ。

 

unmatched

クラスの特定ができなかったり、該当するviewが存在しない場合のログカテゴリです。その場合、clinetカテゴリにも1行のサマリとしてログが出力されます。このカテゴリのログはファイルか標準エラーに送られるのが妥当。デフォルトではNullチャネルに対して送信されます。

 

network

ネットワーク操作に関わるログカテゴリ。

 

update

動的なアップデートに関わるログカテゴリ。

 

update-security

アップデートリクエストの承認と拒否のログカテゴリ。

 

queries

Bindに対して送られたクエリに対するログカテゴリです。query-logオプションが指定されていない場合を除いて、Bind起動時に有効になります。

クエリログには以下の情報が出力されます。

  • クライアントIPアドレス＋port番号
  • リクエストしたクラスとタイプ
  • +/- → 再帰問い合わせ依頼。+は再帰してくれ、-はNot再帰。
  • S → クエリに署名されている
  • E → EDNS（Enhanced DNS）が有効になっている
  • T → TCPが使われた
  • D → DO（Dns-sec Ok）ビットが立ってた
  • C → CD（Checking Disabled）ビットが立ってた

例えばこんな感じ。

client 127.0.0.1#62536: query: www.example.com IN AAAA +SE
client ::1#62537: query: www.example.net IN AAAA -SE

 

query-errors

何かしらのエラーが発生したクエリに関するログカテゴリ。

 

dispatch

受け付けたパケットがnamedのどのモジュールによって処理されたか？という情報。

 

dnssec

DNS-SECとTSIGプロトコル処理のログカテゴリ。

 

lame-servers

Bind9がリモートサーバに問い合わせを行ったときに正しく設定されていないDNSサーバがいた場合にログが出力されるログカテゴリ。（Lameサーバのログカテゴリ）

delegation-only

委譲ゾーンやスタブゾーンに対するクエリ結果がNXDOMAINになった場合のログカテゴリ。

 

edns-disabled

タイムアウト等でEDNSでなく普通のクエリになったときのログカテゴリ。また、rfc1034に従っていないDNSサーバに問い合わせた場合も該当する。これは通信相手のDNSサーバがDNSクエリを理解できない場合も含まれる。このログはパケットロスが発生した場合にも出力される。対向のDNSサーバがrfc1034に従わないDNSサーバと判断する前に、本当にrfc1034に従っていないのかどうかをチェックする。このテストによりFalse-Positiveなリポートを予防することができる。
 

Queryエラーカテゴリ

クエリエラーカテゴリはBind（named）のデバッグのために使われます。例えば、クエリが何故、どうしてエラーになったか？を特定する。このクエリエラーのカテゴリはDebugのログ出力レベルの時に有効になる。

1以上のデバッグレベルの場合、SERVERFAILは以下のように記録される。

client 127.0.0.1#61502: query failed (SERVFAIL) for www.example.com/IN/AAAA at query.c:3880

これは「SERVERFAILはquery.cの3880行目で発生した！」という意味。デバッグレベルが2以上だと再帰問い合わせのコンテキストの詳細もログに出力される。

fetch completed at resolver.c:2970 for www.example.com/A in 30.000183: \\
timed out/success [domain:example.com,referral:2,restart:7,qrysent:8,
timeout:5,lame:0,neterr:0,badresp:1,adberr:0,findfail:0,valfail:0]

コロンの前の一番最初の部分はwww.example.comに対する再帰問い合わせが30.000183秒で完了し、resolver.cの2970行目でSERVERFAILになったとわかる。続く部分は最終的な結果と、DNS-SECの結果が記載されている。DNS-SECについてはバリデーションが行われない場合は成功とみなされる。

以下はDNS問い合わせの場合と、DNS-SECバリデーションの最終的な結果です。DNS-SECバリデーションが行われなかった場合、リクエストは成功とみなされます。ここでの説明するのは、全てのリゾルバがダウンしているか到達できないので30秒のタイムアウトが発生した後、SERVFAILになります。その場合はDNS-SECバリデーションが実施されることはないです。

referal

名前解決の過程で経由したNSの数。example.comの場合は「com」と「example.com」の2個。

restart

あるドメインのNSに対してリゾルバが問い合わせたサイクル数。名前解決に必要な全てのNSに対する問い合わせで1サイクル。

qrysent

あるドメインにの名前解決に対してクエリの数。

timeout

最後のレスポンスを受信してからの時間。

lame

あるドメインの名前解決時にリゾルバが発見したLameサーバの数。リクエストに対して不正な応答が帰ってくるか、Bind9のアドレスデータベース（ADB）の参照でLameサーバとしてキャッシュされていた場合、リゾルバはLameサーバと判定される。

neterr

名前解決中に得られた応答でエラーである応答の数。リゾルバに到達できないか、ICMP unreachableを受け取った場合がこれ。

badresp

期待クエリに対して外れの応答を受け取った数。

 

adberr

アドレスDB（ADB）の中からリモートサーバのアドレス発見が失敗したとき。間違いとして多い例は、リモートサーバの名前に対してアドレスが設定されていなかった場合にこれが出る。

findfail

リモートサーバ自体の名前解決に失敗したときに出る。名前解決の過程で出た全てのフェイルした場合。

valfail

DNS-SECバリデーションの失敗時に出力される。名前解決の過程でバリデーションの失敗はカウントされている。