TinyDNS を監視する手順｜svstat での死活確認、外部からの応答チェック、data.cdb の更新漏れとログの見方

TinyDNS（djbdns の権威DNS）を監視するときは、「プロセスが落ちずに動き続けているか」「外から問い合わせて正しい答えが返るか」「data を編集したのに data.cdb が古いままになっていないか」「ログに異常な傾向が出ていないか」の4点を押さえると、障害の大半を早く見つけられます。この記事では、それぞれをどのコマンドで確かめ、監視ツールにどう組み込むかを順に説明します。

tinydns はとても単純なサーバーで、統計情報を返す仕組みや管理用のコマンドを持っていません。そのため、監視は「プロセス管理側の情報」「外部からの問い合わせ」「ファイル」「ログ」という周りの情報を組み合わせて行います。

監視1：プロセスの死活と再起動の繰り返し

daemontools で動かしている場合

svstat で状態と、起動してからの秒数がわかります。

sudo svstat /service/tinydns /service/tinydns/log

/service/tinydns: up (pid 2345) 86400 seconds
/service/tinydns/log: up (pid 2344) 86400 seconds

ここで見るべきなのは up かどうかだけではありません。supervise は落ちたプロセスをすぐに起動し直すため、起動直後に落ちる状態が続いても、たまたま up と表示されることがあります。秒数がいつ見ても数秒しかない場合は、起動と停止を繰り返しています。 監視では「up で、かつ秒数が一定以上（たとえば60秒以上）」を正常とみなす条件にすると、この状態を拾えます。

#!/bin/sh
# 簡易チェック: up かつ 60 秒以上動いていれば OK
out=$(svstat /service/tinydns)
echo "$out" | grep -q ': up ' || { echo "CRITICAL: $out"; exit 2; }
sec=$(echo "$out" | sed -n 's/.*) \([0-9]*\) seconds.*/\1/p')
[ "${sec:-0}" -ge 60 ] || { echo "WARNING: restarting? $out"; exit 1; }
echo "OK: $out"; exit 0

終了コード 0・1・2 は Nagios 系の監視ツールで OK・WARNING・CRITICAL と扱われる慣習に合わせています。ログ用のサービス（/service/tinydns/log）も止まると記録が残らなくなるので、同じように確認します。

systemd で動かしている場合

systemctl is-active tinydns
systemctl show -p NRestarts -p ActiveEnterTimestamp tinydns

NRestarts は自動で再起動された回数です。この値が増え続けていれば、何かが原因で落ちています。unit 名は自分で作ったものに合わせてください。

再起動を繰り返す原因で多いのは、53番ポートをほかのプロセスが使っている、設定の IP アドレスがそのサーバーに付いていない、data.cdb が読めない、の3つです。ss -lunp | grep :53 とログを確認します。

監視2：外部からの応答を確かめる

プロセスが動いていても、ネットワークやファイアウォールの変更で外から届かなくなることがあります。監視は、できればそのサーバーとは別のネットワークにある監視サーバーから行います。

dig @192.0.2.53 www.example.com A +norec

確認するのは次の3点です。

• status が NOERROR（存在しない名前を問い合わせたなら NXDOMAIN）であること
• flags に aa が付いていること。権威サーバーとして答えている印です。
• ANSWER の値が期待どおりであること

tinydns は自分が管理していないゾーンへの問い合わせには応答しません。監視で問い合わせる名前を、data に書いたゾーンの中から選ぶことが大事です。

監視ツールに組み込む

Nagios や Icinga で使われる monitoring-plugins には check_dig があり、期待するアドレスと比べられます。

check_dig -H 192.0.2.53 -l www.example.com -T A -a 192.0.2.80 -w 0.5 -c 2

Prometheus を使っている場合は、blackbox_exporter の dns プローバーで同じことができます。

modules:
  dns_tinydns:
    prober: dns
    timeout: 5s
    dns:
      query_name: "www.example.com"
      query_type: "A"
      recursion_desired: false
      valid_rcodes:
        - NOERROR

どちらもオプションや設定項目は版によって増減するため、使っている版のドキュメントで確認してください（2026年10月現在）。axfrdns でゾーン転送を提供している場合や、大きな応答がある場合は、dig +tcp で TCP の応答も監視対象に入れておきます。

監視3：data.cdb の更新漏れとシリアルのずれ

tinydns が読むのは data ではなく、make（tinydns-data）で変換した data.cdb です。data を編集したまま make を忘れたり、data の書式誤りで tinydns-data が失敗したりすると、data.cdb は古いまま残り、tinydns は古い内容を答え続けます。エラーで止まるわけではないので気づきにくい障害です。

data の方が data.cdb より新しい状態を検出するには、更新日時を比べます。

cd /service/tinydns/root
if [ data -nt data.cdb ]; then
  echo "WARNING: data is newer than data.cdb (make not run or failed)"
  exit 1
fi
echo "OK"

data を編集してから make するまでの短い時間にも反応するので、チェックの頻度と通知までの猶予を調整してください。

複数台のシリアルを比べる

data.cdb を rsync などで複数台に配っている場合は、各サーバーの SOA シリアルを比べます。Z 行でシリアルを省略していると、tinydns-data は data ファイルの更新日時からシリアルを作るため、配布が漏れたサーバーだけ値が古くなります。

for ns in 192.0.2.53 198.51.100.53; do
  printf '%s ' "$ns"
  dig +short +norec @"$ns" example.com SOA | awk '{print $3}'
done

値が揃っていなければ、配布の仕組み（cron やデプロイスクリプト）の失敗を疑います。

監視4：ログの見方

daemontools の構成では、ログは /service/tinydns/log/main/current に multilog で書かれます。先頭のタイムスタンプは tai64n 形式なので変換して読みます。

tai64nlocal < /service/tinydns/log/main/current | tail -n 20

問い合わせの行は、問い合わせ元の IP アドレス・ポート・問い合わせ ID が16進数で並び、そのあとに結果を表す記号、問い合わせタイプ（16進数）、名前が続きます。記号のうち、+ は応答したもの、- は自分の管理外の名前で応答しなかったものです。そのほかにも不正な問い合わせなどを表す記号があります。

監視で役に立つのは、行の数の変化です。

• **+ の行が急に減った**：上位のネットワーク経路や委任（NS レコード）に問題が出て、問い合わせが届いていない可能性があります。
• **- の行が急に増えた**：管理外のゾーンが自分に委任されたままになっている、あるいはスキャンを受けている可能性があります。

multilog は標準では小さなファイルを数個まで残して古いものを消すため、ディスクがあふれる心配は少ない一方、さかのぼれる期間が短くなります。長く残したい場合は log/run の multilog にサイズと個数の指定を加えるか、別のログ収集の仕組みへ転送します。問い合わせ元の IP アドレスが記録されるので、保存期間と閲覧できる人も決めておいてください。

通知の設計

最後に、検出した異常をどう知らせるかを決めます。

• 外部からの応答が返らない場合は、すぐに通知します（重大度が高い）。
• 再起動の繰り返し、data.cdb の更新漏れ、シリアルのずれは、数分続いたら通知します。
• ログの件数の変化は、日ごとの傾向として見る程度にとどめ、誤報を減らします。

権威DNSが1台だけ止まっても、ほかの NS が答えていれば利用者への影響は小さく済みます。逆に、全台で同時に同じ異常が出たら、データ配布や設定変更が原因であることが多いので、直前の変更を確認します。

まとめ

• svstat（または systemctl）で up の状態に加え、起動してからの時間や再起動回数を見ます。
• 別のネットワークから dig +norec で aa 付きの正しい応答が返るかを確認し、check_dig や blackbox_exporter に組み込みます。
• data と data.cdb の更新日時を比べ、複数台では SOA シリアルを揃えて監視します。
• ログは tai64nlocal で読み、+ と - の件数の変化に注目します。

• Nagios のインストールと設定
• dig コマンドでDNSを調べる方法