「動いている」と「正常である」は違う
こんにちは！「リナックス先生」です。
BIND9講座、第9回へようこそ。
ここまでサーバーを作り込んできましたが、あなたは今、自分のDNSサーバーが「誰からどんな質問を受けているか」把握できていますか？
「動いているから大丈夫」と思っているなら、それは危険信号です。
DNSサーバーは沈黙の臓器のようなもので、攻撃を受けていても、設定ミスでエラーを吐いていても、表面上は静かに動き続けます。
いざ「繋がらない！」とクレームが来てから慌てても、ログがなければ原因は永遠に分かりません。
今回は、BIND9の「Logging（ロギング）」機能をフル活用して、サーバーの健康状態とアクセスの流れを「見える化」します。
プロの現場では、ログ設定のないサーバーはサーバーとは呼びません。しっかり設定していきましょう！
先生、ログなら /var/log/messages に出てるのを見たことがあります！
あれじゃダメなんですか？
なんか他のアプリのログと混ざってて見づらいなぁとは思ってましたが…。
そう、それが問題なの。
重要なDNSのエラーが、SSHのログイン履歴やシステムメッセージに埋もれて見逃されてしまうのよ。
それに、「誰がどのドメインを検索したか」というクエリログは、デフォルトでは一切記録されない設定になっているの。
今日はこれを整理整頓して、有益な情報に変えるわよ！
1. BINDログ設定の基本概念
BINDのログ設定は、少し独特な用語を使います。
まずはこの2つの概念を理解しましょう。
① チャネル (Channel)
「どこに、どうやって捨てるか（出力先）」を定義します。
「ファイルに書き込む」「syslogに送る」「捨ててしまう（null）」などを決めます。
また、ファイルの場合は「何世代残すか（ローテーション）」や「どれくらいのサイズで切り替えるか」もここで指定します。
② カテゴリ (Category)
「どんな種類の情報を拾うか（情報の種類）」を定義します。
BINDには多くの定義済みカテゴリがありますが、主によく使うのは以下の通りです。
- default: 通常のシステムログやエラー。
- queries: 「誰が何のアドレスを聞いてきたか」という問い合わせ記録。
- security: 承認されていないアクセス（ACL拒否など）の記録。
- lame-servers: 設定ミスの疑いがある外部サーバーの情報（ノイズになることが多い）。
【設定のイメージ】
「queries（カテゴリ）」という種類のゴミを、「query_log_file（チャネル）」というゴミ箱に捨てる。
このように紐付けていきます。
2. ログ保存場所の作成と権限設定
設定ファイルを書く前に、ログファイルを保存するディレクトリを用意します。
BIND（namedユーザー）が書き込める権限がないと、起動時にエラーになります。
2-1. ディレクトリ作成
今回は /var/log/named/ という専用ディレクトリを作成します。
sudo mkdir /var/log/named
2-2. 権限の付与
このディレクトリの所有者を named ユーザーに変更します。
sudo chown named:named /var/log/named sudo chmod 750 /var/log/named
【プロの注意点：SELinux】
AlmaLinux 9 ではSELinuxが有効になっています。
標準以外の場所にログを出力しようとするとブロックされる可能性がありますが、/var/named/data/ は最初から許可されています。
もしSELinuxの設定が面倒な場合は、上記の代わりに /var/named/data/ を使うのが一番安全です。
（本記事では、分かりやすさ重視で /var/log/named/ を使いますが、エラーが出る場合は /var/named/data/ に読み替えてください）
3. named.conf への logging 設定
それでは、/etc/named.conf を編集します。
デフォルトの logging { ... }; ブロックを、以下の内容に丸ごと書き換えます。
sudo vi /etc/named.conf
▼記述内容（プロ推奨設定）
logging {
# --------------------------------------------------------
# 1. チャネル定義（出力先のゴミ箱を作る）
# --------------------------------------------------------
# デフォルトログ用チャネル
channel "default_log" {
file "/var/log/named/default.log" versions 3 size 10m;
severity info; # 重要度: info以上を記録
print-time yes; # 日時を記録
print-severity yes; # 重要度ラベルを記録
print-category yes; # カテゴリ名を記録
};
# クエリログ用チャネル（アクセス解析用）
channel "query_log" {
file "/var/log/named/query.log" versions 5 size 100m;
severity info;
print-time yes;
};
# セキュリティログ用チャネル（攻撃検知用）
channel "security_log" {
file "/var/log/named/security.log" versions 3 size 10m;
severity info;
print-time yes;
};
# --------------------------------------------------------
# 2. カテゴリ定義（情報の種類をチャネルに紐付ける）
# --------------------------------------------------------
category default { default_log; };
category queries { query_log; };
category security { security_log; };
# ノイズ対策: lame-servers は捨てても良い
category lame-servers { null; };
};
設定の解説
- versions 3 size 10m:
「ファイルサイズが10MBを超えたらローテーション（世代交代）し、過去3世代まで残す」という設定です。これを入れておかないと、ログファイルが無限に肥大化してディスクを食いつぶします。 - severity info:
情報の詳細度です。debugにすると詳しすぎ、errorにすると重要な情報を見逃します。通常運用ではinfoまたはnoticeが適正です。 - category queries:
これが今回の一番の目玉です。デフォルトでは記録されない「問い合わせ内容」をquery.logに書き出します。
4. 反映と動作確認
設定を保存したら、構文チェックをして再起動します。
sudo named-checkconf sudo systemctl restart named
起動後、ログファイルが生成されているか確認しましょう。
ls -l /var/log/named/
default.log などのファイルが出来ていれば成功です！
もし出来ていない（またはBINDが起動しない）場合は、ディレクトリの権限（chown）かパスのミスを疑ってください。
5. クエリログを見てみよう
実際に問い合わせを行って、ログがどう記録されるか見てみましょう。
リアルタイムでログを見るには tail -f コマンドを使います。
sudo tail -f /var/log/named/query.log
この状態で、別のターミナルから dig を打ちます。
dig @127.0.0.1 google.com
▼ログ出力例
15-Jan-2026 10:00:01.123 queries: info: client @0x7f... 127.0.0.1#45678 (google.com): view internal: query: google.com IN A +E(0)K (127.0.0.1)
非常に詳細な情報が取れましたね！
読み解き方は以下の通りです。
- 127.0.0.1#45678: アクセス元のIPアドレスとポート番号。
- (google.com): 問い合わせ対象のドメイン。
- view internal: どのView（内部/外部）で処理されたか。
- IN A: どんなレコード（Aレコード）を求めたか。
「最近ネットが遅いな？」と思った時にこれを見れば、「あ、誰かのPCが大量に怪しい通信をしてる！」といった犯人探しが一瞬で終わります。
6. セキュリティログの活用
次に、第7回で設定したACL（アクセス制限）が効いているか確認しましょう。
許可されていないIPからのアクセスは security.log に記録されます。
▼ログ出力例（拒否された場合）
15-Jan-2026 10:05:00.999 security: info: client @0x... 192.168.1.99#54321 (secret.lan): view external: query (cache) 'secret.lan/A/IN' denied
denied（拒否） という文字が見えます。
これが大量に出ている場合、あなたのサーバーは攻撃を受けているか、設定ミスで正規のユーザーを弾いている可能性があります。
セキュリティログは定期的にチェックする癖をつけましょう。
7. 【重要】クエリログの運用注意点
クエリログは非常に便利ですが、「諸刃の剣」でもあります。
ディスク容量への影響
アクセス数の多いサーバーでクエリログを常時ONにすると、とんでもない勢いでディスク容量を消費します。
また、書き込み処理によるCPU負荷（I/O負荷）もバカになりません。
プロの運用テクニック：rndc querylog
普段はクエリログをOFFにしておき、トラブル調査の時だけONにする、という運用がスマートです。
named.confのcategory queriesをコメントアウトしておく（またはnullにする）。- 調査が必要になったら、以下のコマンドを打つ。
sudo rndc querylog
このコマンドを打つたびに、クエリログの記録機能が ON/OFF と切り替わります（トグル動作）。
再起動なしで切り替えられるため、障害対応時に非常に重宝します。
rndc コマンド、便利ですね！
ログを見ていると、自分のPCが裏で勝手にいろんな通信をしてるのが見えて面白いです。
「何もしてないのにネットが遅い」なんて嘘だって、ログを見れば一発で分かっちゃいますね（笑）。
まとめ：ログはサーバーのカルテ
第9回では、BIND9のログ機能を強化しました。
- デフォルトのログはシステムログと混ざって見にくい。
- channel で出力先とローテーション（世代管理）を決める。
- category で情報の種類（default, queries, security）を振り分ける。
- クエリログ は便利だが負荷が高いので、rndc querylog で適宜切り替えるのがプロの技。
- ディレクトリの権限（named）を忘れないこと。
これで、トラブルが起きても「何が起きているか」を即座に把握できるようになりました。
ここまでの知識で、構築・運用・監視の基本サイクルは完成です。
次回（第10回）からは、さらに高度なセキュリティ技術「DNSSEC（ディーエヌエスセック）」に挑戦します。
昨今、DNSの応答を偽装して偽サイトに誘導する「DNSキャッシュポイズニング」という攻撃が増えています。
これを電子署名技術で防ぐDNSSECは、現代のDNSサーバーに必須の要件となりつつあります。
難解と言われるDNSSECを、どこよりも分かりやすく解説します。お楽しみに！
▼ログ解析の練習に最適なVPS
大量のクエリログを吐き出させたり、わざと攻撃パケットを送ってログを確認したりといった実験は、他者に迷惑をかけない自分専用のVPS環境で行うのが鉄則です。学習用におすすめの環境はこちら。
コメント