【BIND9講座 番外編】プロの現場はここまでやる！TSIGによるゾーン転送の暗号化と、BINDの健康診断「Statistics」活用術

「動く」の先にある「堅牢」と「可視化」

こんにちは！「リナックス先生」です。
全12回のBIND9講座、完走お疲れ様でした。

本編では、ゼロからDNSサーバーを立ち上げ、DNSSECやIPv6に対応させるまでの「王道ルート」を解説しました。
しかし、実際のインフラ運用の現場では、教科書通りにはいかないケースや、より高いセキュリティ要件を求められることがあります。

「IPアドレス偽装に対抗して、もっと安全にゾーン転送したい」
「ログを見るだけじゃなく、グラフでクエリの傾向を見たい」
「digコマンドだけでは分からない、謎の通信エラーを解析したい」

今回は「番外編」として、これら上級エンジニアの悩みを解決するテクニックを紹介します。
これをマスターすれば、あなたのDNSスキルは頭一つ抜けた存在になるでしょう。

コウ君

先生、まだ続きがあったんですね！
正直、第12回で「終わったー！」と思ってましたが、現場の話と聞くと気になります。
特に「グラフで見たい」っていうのは、上司への報告とかで役立ちそうですね。

リナックス先生

その通り！
「なんとなく重い気がします」より「秒間クエリ数が先週比200%です」と言えるのがプロよ。
今回は少し難しい概念も出てくるけど、BINDの奥深さを楽しんでちょうだい！

1. TSIG（共通鍵）によるゾーン転送の完全ロック

第5回では、マスターからスレーブへのゾーン転送を許可する際、IPアドレス（ACL）で制限しました。

allow-transfer { 192.168.1.11; };

しかし、IPアドレスは偽装される可能性があります。
より厳密な環境では、TSIG（Transaction SIGnature） という「合言葉（共通鍵）」を使った認証を行います。
これを使えば、たとえIPが合っていても、合言葉を知らないサーバーにはデータを渡しません。

1-1. 鍵の生成

まず、マスターサーバー上で鍵を作成します。
tsig-keygen コマンドを使います。

# 鍵の名前は "transfer-key" とします
tsig-keygen -a HMAC-SHA256 transfer-key

▼出力例

key "transfer-key" {
    algorithm hmac-sha256;
    secret "bXlzdXBlcnNlY3JldGtleXRoYXRzaG91bGRub3RiZXNoYXJlZA==";
};

この出力結果（secret文字列）をコピーしておきます。
これはマスターとスレーブの両方で使います。

1-2. マスター側の設定 (named.conf)

/etc/named.conf に鍵を定義し、スレーブサーバーに対して「この鍵を使うこと」を強制しませんが、許可設定に追加します。

# 鍵の定義（ファイルの先頭付近に記述）
key "transfer-key" {
    algorithm hmac-sha256;
    secret "さっきの文字列をここに貼る";
};

# ゾーン転送の許可設定を修正
options {
    # IPアドレスだけでなく、鍵を持っている相手も許可する
    allow-transfer { key "transfer-key"; 192.168.1.11; };
};

1-3. スレーブ側の設定 (named.conf)

スレーブ側にも全く同じ鍵定義を記述し、「マスター(192.168.1.10)と話す時はこの鍵を使う」という設定を入れます。

key "transfer-key" {
    algorithm hmac-sha256;
    secret "さっきの文字列をここに貼る";
};

# マスターサーバーに対して鍵を使う設定
server 192.168.1.10 {
    keys { "transfer-key"; };
};

zone "kou-house.lan" IN {
    type slave;
    masters { 192.168.1.10; }; # ここのIP設定はそのまま
    file "slaves/kou-house.lan.db";
};

1-4. 動作確認

設定反映後、ログを確認します。
TSIG署名付きで転送が行われている場合、ログに以下のように記録されます。

client @0x... 192.168.1.11#.../key transfer-key: transfer of 'kou-house.lan/IN': ...

key transfer-key の文字があれば成功です。
これで、万が一ネットワーク内に不正な端末が接続されても、ゾーンデータを盗まれるリスクは激減します。

2. Statistics Channelによる「BINDの見える化」

BINDには、現在のクエリ数やキャッシュヒット率などの統計情報を、HTTP（XMLやJSON）で出力する機能があります。
これを有効にすると、PrometheusやZabbixなどの監視ツールでデータを収集し、Grafanaでカッコいいグラフを描画できるようになります。

2-1. Statistics Channelの設定

named.conf に以下のブロックを追加します。
セキュリティのため、ローカルホスト（127.0.0.1）または監視サーバーからのアクセスのみ許可します。

statistics-channels {
    inet 127.0.0.1 port 8053 allow { 127.0.0.1; };
    # 外部監視サーバーがある場合はIPを追加
    # inet 192.168.1.10 port 8053 allow { 192.168.1.0/24; };
};

2-2. データの取得

BINDを再起動後、curl コマンドでアクセスしてみます。

curl http://127.0.0.1:8053/

XML形式で大量のデータが返ってくれば成功です。
ここには以下のような宝の山が埋まっています。

  • AuthQryRej: 認証失敗（拒否）回数。急増したら攻撃の予兆。
  • CacheHits / CacheMisses: キャッシュの効率。チューニングの指標になる。
  • QrySuccess: 正常に解決できた回数。

これを bind_exporter などのツール経由でPrometheusに送れば、プロバイダのような監視ダッシュボードが作れます。

3. “dig” だけじゃない！プロのトラブルシューティング・ツール

DNSSECの検証エラーや、ネットワーク経路の問題は、dig だけでは見えにくい場合があります。
AlmaLinux 9 (bind-utils) に含まれる、より高度なツールを紹介します。

① delv：DNSSECの深層を見る

DNSSECのエラーで「SERVFAIL」になった時、なぜ失敗したのか（署名切れ？鍵の不一致？）を調査するのは大変です。
delv コマンドは、ルートゾーンから順に署名の検証プロセス（信頼の連鎖）をトレースし、どこで検証が失敗したかを教えてくれます。

delv @127.0.0.1 google.com

正常なら ; fully validated と表示されます。
異常がある場合、; validation failure: key missing のように具体的な理由を出してくれます。

② tcpdump：パケットの生データを見る

「設定は合っているはずなのに、なぜか返事が来ない」「Firewallで落ちている気がする」。
そんな時は、サーバーに入ってくるパケットを直接覗き見ます。

# ポート53 (DNS) のパケットを監視
sudo tcpdump -i any port 53 -nn

▼読み方

10:00:01 IP 192.168.1.20.54321 > 192.168.1.10.53: 1234+ A? google.com. (28)
10:00:01 IP 192.168.1.10.53 > 192.168.1.20.54321: 1234 1/0/0 A 142.250.196.14 (44)
  • > の向き: どちらからどちらへ送られたか。
  • 1行目: クライアント(.20)からサーバー(.10)へ「google.comのAレコード」を質問。
  • 2行目: サーバー(.10)からクライアント(.20)へ「答えは…」と返信。

もし1行目（質問）しか表示されなければ、サーバーが無視しているか、返信パケットがFirewalldでブロックされている可能性があります。
「証拠」を掴むための最強のツールです。

4. コラム：なぜ本講座では “chroot” を使わなかったのか？

古くからのLinuxユーザーの中には、第2回のインストールで bind-chroot パッケージを入れなかったことに違和感を覚えた方もいるかもしれません。

Chroot（Change Root） は、BINDを特定のディレクトリ（監獄）に閉じ込め、万が一乗っ取られてもOS全体への被害を防ぐ技術です。
しかし、本講座では以下の理由から採用を見送りました。

理由①：SELinuxの方が強力だから

AlmaLinux 9（RHEL 9）の標準セキュリティ機能である SELinux は、ファイルパスだけでなく、プロセスが「何をできるか（ネットワーク接続、ファイル書き込み等）」をカーネルレベルで厳格に制御します。
現代においては、ChrootよりもSELinuxを正しく運用する方がセキュリティ強度は高いとされています。

理由②：SystemdのSandbox機能

現在のBINDの起動ユニット（systemd）には、ProtectSystem や ProtectHome といった設定が含まれており、BINDプロセスがOSの重要ファイルに触れないよう、すでに隔離されています。

Chroot環境はディレクトリ構成が複雑になり（/var/named/chroot/var/named/... など）、パス間違いによるトラブルの元凶になりがちです。
「シンプル・イズ・ベスト」。OS標準のセキュリティ機構を信じるのが、現代的なRHEL系OSの運用スタイルです。

コウ君

なるほど…！
昔の本には必ず「chrootしろ」って書いてあったけど、今はOS自体が進化してるから不要なんですね。
tcpdump でパケットが見えた時、「あ、本当に通信してるんだ」って実感できて感動しました！

全12回・記事リンク集

改めて、過去の記事へのインデックスを掲載します。
実務で困った際は、辞書代わりにご活用ください。

【基礎・構築編】

【冗長化・便利機能編】

【セキュリティ・高度運用編】

まとめ：技術は繋がりの中にこそある

今回の番外編で紹介した「TSIG」「Statistics」「tcpdump」といった技術は、DNS単体の知識ではありません。
暗号化、Web技術、ネットワーク基礎といった周辺知識があって初めて使いこなせるものです。

DNSサーバーを構築した経験は、必ず他のサーバー構築（Web、メール、DB）にも活きてきます。
この講座が、あなたのエンジニアとしての視座を高めるきっかけになれば幸いです。
それでは、またどこかの記事でお会いしましょう！

▼高度な実験を行うためのVPS

TSIGの設定実験や、tcpdumpによるパケットキャプチャは、ネットワーク構成を自由にいじれるVPS環境が最適です。壊してもすぐに再構築できる、エンジニアの実験場としておすすめのVPSはこちら。

【2026年最新】Linuxサーバー構築におすすめのVPS比較3選！現役エンジニアが速度とコスパで厳選
Linuxの勉強、まだ「自分のPC」でやって消耗していませんか？「Linuxを覚えたいけど、環境構築でエラーが出て先に進めない…」「VirtualBoxを入れたらパソコンが重くなった…」これは、Linux学習を始める9割の人がぶつかる壁です...
www.linuxkoubou.com
2026.01.05

コメント