DNSを「ブラックボックス」にするな：ZabbixによるBIND/Unbound深層監視の極意
DNSはインフラの背骨だ。ここが揺らげば、どんなに優れたアプリケーションも、どんなに洗練されたマイクロサービスも、瞬時に「接続不能」という名の死を迎える。
多くの現場では、Zabbixの標準的な「ICMP Ping」や「ポート監視」でDNSを監視した気になっている。だが、それでは「名前解決が遅い」「一部のゾーンで転送が失敗している」といった、ユーザー体験を損なう微細な予兆は一切検知できない。
今日は、DNSインフラを完全に掌握するための「深層監視」の設計思想と、明日から現場で使える実装テクニックを伝授する。
—
1. DNS監視における「真の指標」：何を計測すべきか
DNS監視において、死活監視（UP/DOWN）は最低限のラインに過ぎない。真のプロが追うべきは以下の3点だ。
- 名前解決遅延（Latency）: 再帰クエリの応答速度。P95/P99で計測し、ISP側の輻輳やキャッシュ枯渇の予兆を捉える。
- ゾーン転送の整合性: `NOTIFY`や`AXFR/IXFR`の失敗履歴。マスター・スレーブ間のデータ乖離は、サービス障害のサイレントキラーだ。
- クエリの異常増大（Anomaly）: キャッシュポイズニングの試行や、DDoS攻撃（DNSアンプ）の兆候。秒間クエリ数（QPS）の急増を検知する。
—
2. 高精度監視の実装：Zabbix + `dig` の神髄
Zabbix標準のAgentでは得られない情報を、外部スクリプトで叩く。重要なのは「外部エージェントからの名前解決」と「サーバー内部の統計情報」の二段構えだ。
実装のベストプラクティス：カスタムスクリプト
`dig` コマンドで統計情報を取得し、Zabbixトラッパーに投げるのが最も効率的だ。
!/bin/bash
DNS応答速度計測スクリプト (dns_check.sh)
TARGET_DOMAIN=”example.com”
DNS_SERVER=”127.0.0.1″
digの出力からQuery timeのみを抽出
QUERY_TIME=$(dig @$DNS_SERVER $TARGET_DOMAIN +stats | grep “Query time” | awk ‘{print $4}’)
応答がない場合は-1を返す（アラートトリガーの判定用）
echo ${QUERY_TIME:-“-1”}
これを `UserParameter` として定義する。
/etc/zabbix/zabbix_agentd.d/userparameter_dns.conf
UserParameter=dns.query.time[],/usr/local/bin/dns_check.sh $1
—
3. DNS攻撃を早期検知する閾値チューニング
「CPU使用率」でアラートを出すのは素人だ。DNSでは「QPS（Query Per Second）」と「キャッシュヒット率」の推移を見ろ。
- 閾値設計の鉄則:
- QPSの急増: 直近1時間の移動平均と比較し、200%を超えたら「警告」、500%で「重要」。
- キャッシュヒット率の急落: Unboundであれば `unbound-control stats` から算出。これが落ちる＝外部への再帰クエリが急増している＝踏み台攻撃の可能性大。
—
4. チーム開発で差がつく！Zabbix運用の「プロの流儀」
チーム開発を加速させる「設定共有化」ルール
- テンプレートの階層化: 「DNS共通設定」テンプレートを作り、各OSや役割ごとのテンプレートを継承させる。変更は親で行い、子には継承させる。
- マクロ活用: サーバーのIPやポート、閾値はハードコーディングせず、必ず `{HOST.MACRO}` に切り出す。これにより、新しいDNSサーバーを監視対象にする際、登録作業は数秒で終わる。
劇的に効率が上がるキーボードショートカット
- `G + S` (Latest Data): 障害の切り分け中、即座にグラフを確認するのに必須。
- `G + T` (Triggers): 現在発生中のトリガー一覧へ瞬時にジャンプ。
絶対入れるべき神プラグイン（と連携）
- Grafana: Zabbixをデータソースとして、DNS統計をヒートマップで可視化せよ。時系列での「攻撃パターン」が視覚的に理解できるようになる。
—
5. 実装のためのJSONテンプレート構成（抜粋）
ZabbixのテンプレートをXML/JSON管理する際は、Gitで変更履歴が追えるように「最小単位」でエクスポートし、構造を整理すること。
// DNS監視用テンプレートの一部（概念イメージ）
{
“zabbix_export”: {
“groups”: [“DNS_Servers”],
“templates”: [“Template_DNS_Deep_Monitor”],
“items”: [
{
“name”: “DNS Query Time (ms)”,
“key”: “dns.query.time[example.com]”,
“delay”: “1m”,
“history”: “7d”,
“value_type”: “FLOAT”,
“units”: “ms”
}
],
“triggers”: [
{
“expression”: “last(/Template_DNS_Deep_Monitor/dns.query.time[example.com])>500”,
“name”: “DNS Response Slow: {ITEM.VALUE}ms”,
“priority”: “AVERAGE”
}
]
}
}
—
最後に：オブザーバビリティとは「問い」を立てること
DNSの監視において最も重要なのは、「なぜ今、このクエリが遅延したのか？」という問いを、瞬時にデータから導き出せる状態にあるかだ。
ログを眺めるだけの時代は終わった。Zabbixを「警報装置」から「分析プラットフォーム」に進化させろ。今回紹介した手法をベースに、自社のインフラの特性に合わせた「独自のメトリクス」を付け加えた瞬間、君のチームの運用レベルは一段階上のステージへと到達するだろう。
さあ、今すぐ `dig` の結果をZabbixに流し込み、インフラの深淵を可視化してくれ。