【入門編】Zabbixを用いたDNSサーバー（BIND/Unbound）の深層監視：ゾーン転送エラーや名前解決遅延を完全検知する専用テンプレートの自作 – 運用監視・オブザーバビリティ活用バイブル

こんにちは！インフラの現場を支えるエンジニアの皆さん、日々の運用お疲れ様です。

突然ですが、システムの「心臓部」は何だと思いますか？データベース？それともロードバランサー？
……いいえ、どれほど強力なDBがあっても、どれほど洗練されたAPIサーバーがあっても、「DNS」が沈黙した瞬間、サービスはこの世界から消滅します。 ユーザーのブラウザには「サーバーが見つかりません」という絶望的なエラーが表示され、問い合わせ対応でチャットが炎上する――そんな悪夢を経験した方もいるのではないでしょうか。

今回は、数ある監視ツールの中でも根強い信頼を誇る「Zabbix」を使って、DNSサーバー（BINDやUnbound）の深層を監視し、障害やその「予兆」を完全に捉えるための専用テンプレートを自作する方法を解説します。

「Zabbixの標準テンプレートだと、ただの死活監視しかできなくて不安…」
「名前解決が遅延している原因を、もっとピンポイントで知りたい」

そんな悩みを抱えるあなたへ。これをマスターすれば、DNSに起因する障害の恐怖から解放され、毎日の運用が劇的に楽になりますよ。さあ、一緒にプロの監視の世界へ踏み出しましょう！

—

1. DNSインフラ監視における「絶対に外せない」重要メトリクス

DNSの監視と聞いて、何を思い浮かべますか？「ポート53番が空いているか（TCP/UDP ping）」だけを確認していませんか？それは監視ではなく、単なる「生存確認」に過ぎません。

DNSインフラストラクチャの健康状態を完全に把握するためには、以下の3つのレイヤーを監視する必要があります。

① 名前解決の「応答速度（Latency）」と「正確性」

ユーザーがURLを叩いてからIPアドレスが返ってくるまでのレイヤーです。単に引けるだけでなく、「期待したIPアドレスが返ってきているか」「タイムアウトせずにミリ秒単位で応答しているか」を監視します。

② 再帰問い合わせ（Recursive Query）とキャッシュの健全性

Unboundなどのフルリゾルバにおいて、キャッシュヒット率や、外部権威サーバーへの問い合わせ（再帰問い合わせ）の負荷が高騰していないかを監視します。ここが詰まると、DNSサーバー全体のレスポンスが雪崩式に悪化します。

③ ゾーン整合性と転送エラー（AXFR/IXFR）

BINDなどの権威サーバーにおいて最も恐ろしいのは、マスター・スレーブ間の「ゾーン転送の失敗」です。片側のレコードが古いままになると、ルーティングの不整合やサービス停止を引き起こします。

—

2. Zabbix × `dig`コマンド：高精度な名前解決・死活監視の構築

Zabbixの標準機能（`net.tcp.service[dns]`など）は便利ですが、細かいエラーコード（SERVFAIL, REFUSEDなど）や、具体的な名前解決の遅延時間を詳細に取得するには限界があります。

そこで、Linuxの標準コマンドである `dig` を活用したカスタムスクリプトをZabbixエージェントに組み込みます。これこそが、プロが現場で使う高精度なアプローチです。

ステップ1: 監視用シェルスクリプトの作成

Zabbixエージェントが実行できる場所に、専用の監視スクリプトを配置します。ここでは`/etc/zabbix/scripts/check_dns.sh`として作成しましょう。

!/bin/bash
==============================================================================
Zabbix用高精度DNS監視スクリプト
引数1: 問い合わせ対象ホスト (例: example.com)
引数2: 問い合わせ先DNSサーバーIP (例: 127.0.0.1)
引数3: レコードタイプ (例: A, MX, SOA)
==============================================================================

TARGET=$1
DNS_SERVER=$2
RECORD_TYPE=${3:-A}

digコマンドを実行し、応答時間(Query time)とステータスを取得
タイムアウトは2秒に設定
DIG_RESULT=$(dig @${DNS_SERVER} ${TARGET} ${RECORD_TYPE} +noall +answer +stats +time=2 +tries=1 2>&1)
EXIT_CODE=$?

digコマンド自体が失敗した場合（ネットワークエラーなど）
if [ $EXIT_CODE -ne 0 ]; then
echo “ZBX_NOTSUPPORTED: DNS query failed (Exit code: $EXIT_CODE)”
exit 1
fi

ステータス行から状態抽出 (NOERROR, SERVFAIL, NXDOMAINなど)
STATUS=$(echo “$DIG_RESULT” | grep “status:” | awk ‘{print $5}’ | tr -d ‘,’)

応答時間を抽出 (Query time: XX ms)
QUERY_TIME=$(echo “$DIG_RESULT” | grep “Query time:” | awk ‘{print $4}’)

簡易的なエラー判定（NOERROR以外は異常値として処理、あるいはメトリクスとして返す）
if [ “$STATUS” != “NOERROR” ]; then
# 異常時はステータス名を返す（例: SERVFAIL）
echo “ERROR_$STATUS”
exit 0
fi

正常時は応答時間（ミリ秒）を出力
echo “${QUERY_TIME}”

スクリプトに実行権限を付与します。

chmod +x /etc/zabbix/scripts/check_dns.sh
chown zabbix:zabbix /etc/zabbix/scripts/check_dns.sh

ステップ2: Zabbixエージェントの設定

作成したスクリプトをZabbixサーバーから呼び出せるように、エージェントの設定ファイル（`/etc/zabbix/zabbix_agentd.d/dns_monitor.conf`）を作成します。

Zabbix Agent UserParameter for DNS Monitoring
書式: dns.perf[対象ドメイン, DNSサーバーIP, レコードタイプ]
UserParameter=dns.perf[],/etc/zabbix/scripts/check_dns.sh “$1” “$2” “$3”

設定を反映するため、Zabbixエージェントを再起動します。

systemctl restart zabbix-agent

ステップ3: 動作確認（HelloWorld的なアプローチ）

まずはZabbixサーバー側（またはエージェントを導入したホスト）から、Zabbixエージェント経由できちんと値が取れるかテストします。`zabbix_get`コマンドを使用します。

zabbix_get -s 127.0.0.1 -k “dns.perf[google.com,127.0.0.1,A]”

ここで「`3`」や「`12`」（ミリ秒を表す数値）が返ってきたら大成功です！
もし「`ERROR_SERVFAIL`」などが返ってきた場合は、DNSサーバーの設定やフォワーダーの向き先を疑ってください。このコマンド一発で、DNSの「今」が手に取るように分かります。

—

3. アラート閾値チューニング：DNSキャッシュポイズニング・DDoS兆候の早期発見

名前解決の速度だけでなく、「セキュリティ上の脅威や異常な負荷」を検知してこそ、真のオブザーバビリティです。ここからは、Zabbixのトリガー設定と組み合わせるべき実践的なチューニングテクニックを伝授します。

① 名前解決遅延（Latency）の動的閾値アラート

DNSの応答速度は時間帯によって変動するため、固定値（例：500ms超えでアラート）では夜間バッチ時のノイズに悩まされます。Zabbixの機能を使って「直近平均と比較して異常に遅い」状態を検知します。

Zabbixトリガー式の例:

`last(/DNS Server/dns.perf[example.com,127.0.0.1,A])>200 and avg(/DNS Server/dns.perf[example.com,127.0.0.1,A],10m)>100`

解説: 単発の遅延（200ms超え）かつ、過去10分の平均が100msを超えている場合にのみ発報します。これにより、一過性のネットワークゆらぎによる誤検知（ノイズ）を完全に排除できます。

② DDoS・キャッシュポイズニング兆候（再帰問い合わせの急増）

Unboundなどのフルリゾルバにおいて、外部からの不正な大量問い合わせ（DDoS攻撃やアンプ攻撃の踏み台にされている兆候）を検知するには、「クエリ処理数の急激なスパイク」を監視します。
Unboundの統計情報（`unbound-control stats_noreset`）をZabbixで定期収集し、以下のトリガーを設定します。

トリガー条件: `tps`（1秒あたりのトランザクション数）が、過去のベースラインから +300%以上 急増した場合。
意味: 通常時のトラフィックを逸脱したリクエストの急増は、DNS水責き攻撃（Random subdomain attack）や、踏み台としての不正利用をいち早く察知する手がかりになります。

③ ゾーン転送エラー（BIND）の即座検知

BIND（named）を使用している場合、スレーブサーバー側でゾーン転送が失敗すると、ログ（`/var/log/messages` や `journalctl`）に以下のようなエラーが出力されます。

> `zone example.com/IN: refresh: failure trying master [IP]: streamgeddon / transfer failed`

これをZabbixのログ監視（`log[/var/log/named/security.log,”transfer failed”]`）と組み合わせ、検知した瞬間にCRITICAL（重大）アラートを飛ばすようにします。ここが遅れると、セカンダリDNSとしての役割を完全に失い、マスター障害時にサイトが沈没します。

—

おわりに：監視とは「未来の自分へのラブレター」

今回は、Zabbixと`dig`コマンドを組み合わせたDNSサーバーの深層監視について解説しました。

「ただ動いているか」を確認するだけの監視は、もう卒業しましょう。

ミリ秒単位の応答遅延を捉え、
セキュリティの異常な兆候を察知し、
ゾーン転送の失敗を未然に防ぐ。

ここまで作り込んだテンプレートがあれば、深夜に突然「サイトが見られない！」と叩き起こされる恐怖から解放されます。あなたが仕込んだ精緻なアラートは、未来のインフラストラクチャ、そして何よりあなた自身の平穏な睡眠時間を守ってくれる「ラブレター」のようなものです。

ぜひ今回のスクリプトと設定をあなたの環境に導入し、揺るぎないオブザーバビリティを手に入れてください。
それでは、次の現場でお会いしましょう！