2026年6月12日

Knot DNS の監視方法｜プロセス・外部応答・シリアル・DNSSEC 署名期限・統計を見張る

DNS・名前解決

Knot DNS の監視は、「プロセスが動いているか」だけでは足りません。外部から実際に正しい答えが返るか、プライマリとセカンダリのシリアルが揃っているか、DNSSEC の署名が期限切れに近づいていないかまで見て、はじめて「名前が引けなくなる前」に気づけます。この記事では、監視すべき項目を層ごとに整理し、knotc・dig・mod-stats を使った具体的な確認方法と、アラートを出す条件の目安を説明します。

コマンドや設定項目は Knot DNS 3.x 系を前提にしています（2026年10月現在）。出力の形式や項目名は版によって変わることがあるため、手元の knotc --help と公式マニュアルで確かめてから監視スクリプトに組み込んでください。ログの出力先や詳細度の設定そのものは、この記事では最小限にとどめます。

監視する項目を層で分ける

権威 DNS の障害は、症状が出るまでに時間差があるのが特徴です。たとえばセカンダリがゾーン転送に失敗し続けても、手元のコピーの期限（SOA の expire）が切れるまでは普段どおり答え続け、期限が来た瞬間に SERVFAIL を返し始めます。DNSSEC の署名も同じで、期限が切れた時点で検証するリゾルバーからは名前が引けなくなります。

そこで、監視を次の5つに分けて考えます。

プロセスと制御ソケット：knotd が動き、knotc で操作できるか
外部からの応答：インターネット側から UDP と TCP の両方で正しい答えが返るか
ゾーンの同期：全ネームサーバーのシリアルが揃い、セカンダリの期限に余裕があるか
DNSSEC：署名の有効期限と鍵のロールオーバーが予定どおりか
傾向とリソース：応答コードの比率、問い合わせ量、ジャーナルやディスクの空き

1. プロセスと制御ソケット

いちばん基本の確認は、サービスの状態と knotc の応答です。

systemctl is-active knot
knotc status

knotc status は制御ソケット経由で knotd に問い合わせるため、プロセスは存在するのに応答できない状態も見分けられます。knotc は制御ソケットに書き込める権限が要るので、監視エージェントから実行する場合は root か knot ユーザーの権限で動かすか、sudo で knotc だけを許可します。

ただし、この層だけを監視していると、ファイアウォールの設定ミスや、特定のゾーンだけが読み込めていない状態を見逃します。次の層と組み合わせることが前提です。

2. 外部から応答を確かめる

利用者から見て名前が引けるかどうかは、外部のネットワークから問い合わせないと分かりません。監視サーバーを別のネットワークに置き、各ネームサーバーへ個別に問い合わせます。

# 再帰を要求せず、権威サーバーとして答えるか（flags に aa が付くか）
dig +norec @ns1.example.com example.com SOA

# TCP でも答えるか（大きな応答やゾーン転送で使われる）
dig +norec +tcp @ns1.example.com example.com SOA

# Knot 付属の kdig でも同様に確認できる
kdig @ns1.example.com example.com SOA +tcp

見るべき点は、ステータスが NOERROR であること、flags に aa（権威を持つ応答）が付いていること、応答時間（Query time）が普段と比べて増えていないことです。UDP だけ確認していると、TCP の 53 番がファイアウォールで閉じられていることに気づけません。

Nagios 互換の監視ツールを使っているなら、monitoring-plugins に含まれる check_dig で同じことができます。

# www.example.com の A が 192.0.2.10 であること、0.5秒で警告・1秒で重大
check_dig -H ns1.example.com -l www.example.com -T A -a 192.0.2.10 -w 0.5 -c 1

監視対象の名前には、ゾーンの頂点（SOA・NS）に加えて、サイトやメールなど止まると困る名前を数件入れておくと、「一部のレコードだけ消えた」という事故にも気づけます。

3. シリアルの一致とセカンダリの期限

プライマリでゾーンを更新すると、セカンダリはゾーン転送で追いつき、SOA のシリアルが揃います。全ネームサーバーのシリアルを並べるスクリプトを定期実行し、一致しない状態が一定時間続いたら通知します。

#!/bin/sh
# 各 NS が返す SOA シリアルを表示する
ZONE=example.com
for ns in $(dig +short NS "$ZONE"); do
  serial=$(dig +short +norec @"$ns" "$ZONE" SOA | awk '{print $3}')
  echo "$ns ${serial:-応答なし}"
done

更新直後は数秒から数分ずれるのが普通なので、「SOA の refresh の値を超えても不一致」を通知の条件にすると、誤報を抑えられます。

セカンダリが Knot の場合は、knotc zone-status example.com でそのゾーンの役割、シリアル、refresh や expiration などの次回予定を確かめられます。expiration の残り時間が短くなっているのは、プライマリから転送を受けられていない合図です。転送が失敗する原因（ACL、TSIG 鍵、NOTIFY の不達など）は、ログで「refresh」や「transfer」を含む行を探すと手がかりが見つかります。

4. DNSSEC 署名の期限

Knot の自動署名を使っていると、署名の更新は knotd が自動で行います。それでも、署名の処理が止まったり、時刻がずれたりすれば期限は切れます。外部から署名の有効期限を読み取り、残り日数で通知するのが確実な手段の1つです。

#!/bin/sh
# SOA に付いた RRSIG の有効期限までの残り日数を表示する
NS=ns1.example.com
ZONE=example.com
exp=$(dig +dnssec +norec @"$NS" "$ZONE" SOA | awk '$4=="RRSIG" && $5=="SOA" {print $9; exit}')
exp_epoch=$(date -u -d "$(echo "$exp" | sed -E 's/(....)(..)(..)(..)(..)(..)/\1-\2-\3 \4:\5:\6/')" +%s)
now=$(date -u +%s)
echo "RRSIG 有効期限: $exp (残り $(( (exp_epoch - now) / 86400 )) 日)"

RRSIG の有効期間はポリシーで決まります（Knot では policy セクションの設定）。通知の閾値は、通常の再署名のタイミングより手前で鳴るように決めます。たとえば有効期間が2週間で、残り1週間前後で再署名される設定なら、残り3日を切ったら通知する、といった具合です。

鍵の状態は keymgr example.com. list で一覧できます。KSK のロールオーバーでは、親ゾーンへの DS 登録が必要になる場面があります。登録待ちのまま放置すると移行が進まないため、ロールオーバーの予定日の前後はログと親ゾーンの DS を確認します。外部からの総合的な確認には DNSViz のような可視化ツールも役立ちます。

5. 統計を取り込んで傾向を見る

mod-stats モジュールを有効にすると、プロトコル別の問い合わせ数や応答コード別の件数などを数えられます。

template:
  - id: default
    global-module: mod-stats

statistics:
    timer: 60      # 秒
    file: /run/knot/stats.yaml

statistics セクションで timer を指定すると、指定した間隔で YAML 形式のファイルに書き出されます。手動で見るときは knotc stats を使います。

knotc stats mod-stats
knotc zone-stats example.com.

Prometheus を使っている環境向けには、Knot のプロジェクトがエクスポーター（knot_exporter）を用意しています。導入方法や公開するポートは版によって異なるため、手元の版の説明を確認してください。

傾向を見るときに役立つのは、次のような変化です。

SERVFAIL の比率の上昇：ゾーンの期限切れや署名の問題の可能性
REFUSED の急増：自分が持たないゾーンへの問い合わせや、ACL の変更ミス
問い合わせ総数の急増：設定ミスのリゾルバーや攻撃。RRL の設定を見直すきっかけになります
TCP の比率の上昇：応答サイズが増えた、あるいは TC 付き応答が増えた可能性

mod-stats は knotd 自身が送る NOTIFY や受信するゾーン転送は数えない仕様なので、転送の失敗は統計ではなくログと手順3の確認で拾います。

6. リソースとログ

Knot のジャーナルは database セクションの journal-db-max-size が上限で、上限に達すると全ゾーンで変更が拒否されます。データディレクトリのディスク使用量とあわせて監視し、余裕が少なくなったら通知します。DoT や DoQ を提供している場合は、証明書の有効期限も監視対象に加えます。

ログは systemd 環境なら journalctl -u knot で確認できます。監視ツールでログを拾う場合は、警告（warning）以上のレベルを通知対象にし、info レベルは調査用に残しておく分け方が扱いやすいです。

アラート設計の目安

即時に通知：外部からの応答なし（UDP・TCP どちらか）、knotc status の失敗、署名の残りが閾値を下回った
一定時間続いたら通知：シリアルの不一致、応答時間の悪化、SERVFAIL 比率の上昇
日次の報告で十分：ディスクやジャーナルの使用量、問い合わせ量の推移

監視スクリプトを本番に入れる前に、ステージングでわざとセカンダリを止める、署名の閾値を一時的に大きくするなどして、実際に通知が届くかを確かめておきます。

まとめ

プロセスの生存確認だけでなく、外部からの UDP・TCP の応答、シリアルの一致、DNSSEC の署名期限まで監視します。
セカンダリの障害は SOA の expire まで表に出ないため、knotc zone-status とシリアル比較で早めに気づけるようにします。
署名の有効期限は外部から RRSIG を読んで残り日数で通知すると、署名処理の停止にも気づけます。
mod-stats と statistics セクションで応答コードやプロトコルの比率を記録し、急な変化を傾向として捉えます。
通知は「即時」「継続したら」「日次」に分け、実際に鳴るかをステージングで確かめてから運用に入れます。