Knot DNS のログ設定方法｜log セクションの出力先・重要度、ファイル分割と dnstap でのクエリ記録

Knot DNS のログは、設定ファイル knot.conf の log セクションで「どこへ（target）」「何の種類を（server・control・zone など）」「どの重要度以上で」出すかを指定します。この記事を読むと、syslog や journal への出力、ファイルへの分割、ローテーションの組み方、障害調査のための一時的な debug 出力、そして通常のログでは取れない「問い合わせ1件ごとの記録」を dnstap で残す方法までを設定できるようになります。

Knot の死活や応答の監視（プロセス・シリアル・署名期限など）は別の記事で扱っているため、ここでは「ログを何に、どう出すか」に絞ります。

log セクションの基本

log セクションはリスト形式で、出力先ごとに1項目を書きます。各項目で使う主なキーは次のとおりです（Knot DNS 3.x 系の書式、2026年10月現在）。

• target：出力先。stdout、stderr、syslog、またはファイルのパスを指定します。systemd 環境で syslog を選ぶと、通常は journal に記録されます。
• server：起動・停止、設定の読み込み、待ち受けなどサーバー全体に関するメッセージ。
• control：knotc による操作（reload やゾーンの操作など）に関するメッセージ。
• zone：ゾーンの読み込み、ゾーン転送（AXFR・IXFR）、NOTIFY、DNSSEC 署名などゾーン単位のメッセージ。
• any：上の種類をまとめて指定するための項目。

重要度は高い順に critical、error、warning、notice、info、debug です。指定した重要度と、それより重要なメッセージが出力されます。たとえば zone: notice なら notice・warning・error・critical が出て、info と debug は出ません。

どの種類が使えるかはバージョンによって増えることがあるため（新しい版では QUIC 関連の種類が加わっているなど）、使っている版のドキュメントの log セクションを確認してください。

よく使う設定例

例1：すべてを journal に出す（標準的な構成）

log:
  - target: syslog
    any: info

もっとも単純で、パッケージで入れた Knot の多くはこれに近い状態で動きます。確認は journalctl で行います。

journalctl -u knot -f
journalctl -u knot -p warning --since "1 hour ago"

-p warning を付けると warning 以上だけに絞れるので、問題が起きていないかを手早く見たいときに便利です。unit 名はディストリビューションやインストール方法によって違うことがあるので、systemctl list-units | grep -i knot で確認してください。

例2：ゾーンの出来事だけファイルに分け、journal には警告以上を出す

ゾーン転送や署名の記録を後から追いたい一方、journal にはあまり細かい情報を流したくない、という構成です。

log:
  - target: syslog
    any: warning
  - target: /var/log/knot/zone.log
    zone: info

同じメッセージが複数の出力先の条件に当てはまれば、それぞれに書かれます。この例では、ゾーンに関する warning 以上は journal と zone.log の両方に、info と notice は zone.log だけに出ます。

ファイルに出す場合は、ディレクトリを作って Knot の実行ユーザー（パッケージでは多くの場合 knot）が書き込めるようにしておきます。

sudo install -d -o knot -g knot -m 0750 /var/log/knot

書き込めないときは起動時にエラーが出るか、そのファイルに何も書かれません。まず journal 側のメッセージで権限エラーが出ていないかを見ます。SELinux や AppArmor が有効な環境では、標準とは違う場所に書こうとしてポリシーに止められることもあります。

例3：障害調査のときだけ debug にする

ゾーン転送が失敗する、署名が進まないといった調査では、一時的に zone の重要度を下げます。

log:
  - target: syslog
    any: info
  - target: /var/log/knot/debug.log
    zone: debug

debug は出力量が多く、問い合わせの多いサーバーではディスクを圧迫します。調査が終わったら元に戻し、ファイルも整理してください。

設定を反映する手順

設定を変えるときは、変更前の knot.conf をコピーしておき、構文を確認してから反映します。

sudo cp -a /etc/knot/knot.conf /etc/knot/knot.conf.bak
sudo knotc conf-check
sudo knotc reload

knotc conf-check で書式の誤りを先に見つけられるので、reload 前に毎回実行する習慣をつけると安全です。YAML 形式なのでインデントのずれが原因のエラーが多く、エラーメッセージに表示される行番号を手がかりに直します。

reload で反映されない項目もあるため、反映後に新しい出力先へ実際に書かれているかを確認してください。書かれていなければ、メンテナンス時間を取って systemctl restart knot での再起動を検討します。セカンダリやほかの権威サーバーがあれば、1台ずつ作業すると応答が途切れません。

設定を knot.conf ではなく設定データベース（confdb）で管理している場合は、ファイルの編集ではなく knotc conf-begin、conf-set、conf-commit の流れで変更します。どちらの方式で動いているかは、起動オプションや unit ファイルで確認できます。

ファイル出力のローテーション

ファイルに出す場合はローテーションを用意します。Knot が出力ファイルを開き直すタイミングは版や設定によって違うため、Knot の挙動に頼らない copytruncate を使うのが無難です。

# /etc/logrotate.d/knot-local
/var/log/knot/*.log {
    weekly
    rotate 8
    compress
    delaycompress
    missingok
    notifempty
    copytruncate
}

sudo logrotate -d /etc/logrotate.d/knot-local

-d は実際には何もせず、どう処理されるかだけを表示するので、設定の確認に使えます。copytruncate はコピーと切り詰めの間に書かれた数行を失う可能性があることも覚えておいてください。journal に出している分は journald の保存設定（容量や期間）に従います。

問い合わせ1件ごとの記録は dnstap で取る

Knot の log セクションは、サーバーやゾーンの出来事を記録するためのもので、「どこから何を問い合わせたか」を1件ずつ書く機能はありません。クエリの記録が必要な場合は、dnstap 形式で出力するクエリモジュール mod-dnstap を使います。

mod-dnstap:
  - id: capture
    sink: /var/log/knot/capture.tap
    log-queries: on
    log-responses: on

template:
  - id: default
    global-module: mod-dnstap/capture

global-module はすべての問い合わせにモジュールを適用する設定です。特定のゾーンだけ記録したい場合は、そのゾーンの設定に module: mod-dnstap/capture を書きます。

注意点は次のとおりです。

• mod-dnstap は dnstap を有効にしてビルドされた Knot でだけ使えます。パッケージによっては別のパッケージに分かれていることがあるので、conf-check でモジュールが見つからないと出たら、使っている配布元の案内を確認してください。
• 出力はバイナリ形式です。kdig で dnstap ファイルを読み込んで表示する機能があるほか、dnstap 用の読み取りツールでも確認できます。
• 問い合わせの多いサーバーではファイルがすぐに大きくなります。必要な期間だけ有効にするか、sink をソケットにして収集側で間引く構成を検討してください。
• 問い合わせ元の IP アドレスは個人に結びつく情報になりうるので、保存期間と閲覧できる人を決めておきます。

ログで見ておきたいメッセージ

運用中は、次のようなメッセージに注目すると異常に早く気づけます。文言は版によって変わるため、自分の環境で一度ずつ発生させて確認しておくとよいです。

• ゾーンファイルの読み込み失敗や構文エラー（ゾーンが古いまま配信される原因になります）
• ゾーン転送や NOTIFY の失敗、TSIG 鍵の不一致
• DNSSEC の署名や鍵ロールオーバーに関する警告
• 設定の再読み込みに失敗したという通知

これらを warning 以上で拾えるようにしておけば、journal を -p warning で絞るだけで大半の問題を見つけられます。

まとめ

• Knot DNS のログは log セクションで、出力先（target）ごとに種類と重要度を指定します。
• 通常は syslog（journal）に info、必要に応じてゾーンの出来事をファイルに分けます。
• 変更前にバックアップを取り、knotc conf-check のあと reload し、実際に書かれているかを確認します。
• ファイル出力は copytruncate を使ったローテーションで管理します。
• 問い合わせ1件ごとの記録は log ではなく mod-dnstap で取り、容量と個人情報の扱いに気をつけます。

• syslog のカスタム設定方法
• logrotate によるログ管理