Unbound のログ設定方法｜出力先・verbosity・問い合わせログ・ローテーションの設定と、ログが出ないときの確認

Unbound のログは、unbound.conf の server: 節で「出力先（syslog かファイルか）」「詳しさ（verbosity）」「問い合わせや応答を記録するか」の3つを決めて設定します。普段は verbosity を低く保ち、調査のときだけ unbound-control で一時的に上げるのが扱いやすい運用です。この記事では、それぞれの設定項目の意味、ファイルに出すときの注意点、ローテーション、ログが出ないときの確認の順番を説明します。

Unbound が出せるログの種類

Unbound のログは、大きく分けて次の種類があります。

• 動作ログ：起動・停止、設定の読み込み、エラーなど。詳しさは verbosity で決まります。
• 問い合わせ・応答のログ：どの端末がどの名前を問い合わせ、どんな結果を返したか。log-queries と log-replies で有効にします。
• 調査向けのログ：SERVFAIL になった理由（log-servfail）、DNSSEC の検証に失敗した理由（val-log-level）、local-zone の設定で応答した記録（log-local-actions）。
• 統計情報：問い合わせ数やキャッシュのヒット数など。ログではなく unbound-control stats_noreset で取り出すのが一般的です。

目的に合わせて必要なものだけを有効にするのが基本です。問い合わせのログは量が多く、端末のアドレスと閲覧先のドメインが結び付いた個人に関わる情報にもなるため、常時有効にするかは慎重に判断します。

手順1：出力先を決める

既定では、Unbound は syslog にログを送ります（use-syslog: yes）。systemd で動かしている環境なら、journald 経由で次のように確認できます。

journalctl -u unbound -f

専用のファイルに出したい場合は、use-syslog を無効にして logfile を指定します。Debian や Ubuntu では、/etc/unbound/unbound.conf.d/ に置いた .conf ファイルを読み込む構成が一般的なので、そこに追記用のファイルを作ると管理しやすくなります。

# /etc/unbound/unbound.conf.d/logging.conf
server:
    use-syslog: no
    logfile: "/var/log/unbound/unbound.log"
    log-time-ascii: yes
    verbosity: 1

ここでつまずきやすい点が3つあります。

1. **use-syslog: yes のままだと logfile は使われません。** syslog の設定が優先されるため、ファイルに出すときは明示的に no にします。
2. chroot を使っている場合、パスは chroot の内側で解釈されます。 chroot: が設定されていると、/var/log/unbound/ のような外側のパスには書けません。chroot の中にディレクトリを作るか、chroot を使わない設定にします。chroot の既定値はディストリビューションのパッケージによって異なります。
3. 書き込み権限が必要です。 Unbound は起動後に unbound などの専用ユーザーに切り替わって動くため、そのユーザーが書けるディレクトリを用意します。Ubuntu の AppArmor や RHEL 系の SELinux が、想定外の場所への書き込みを拒否することもあります。

sudo mkdir -p /var/log/unbound
sudo chown unbound:unbound /var/log/unbound

log-time-ascii: yes は、ファイルに出すときの時刻を UNIX 時間の数字ではなく読める形式にする設定です。syslog に出す場合は syslog 側が時刻を付けるので影響しません。

手順2：verbosity の段階を選ぶ

verbosity は 0 から 5 までの段階で、数字が大きいほど詳しくなります。

• 0：エラーのみ
• 1：運用に必要な情報（通常はこれで十分です）
• 2：問い合わせごとの短い情報を含む詳しい運用情報
• 3：問い合わせ単位の詳しい情報
• 4：名前解決の処理の流れ（アルゴリズムの段階）
• 5：キャッシュに無かった問い合わせについて、問い合わせ元の識別情報まで

3 以上は、問い合わせの多いサーバーでは短時間で大量のログが出ます。CPU やディスクへの負荷も増えるため、本番で常に高い値にしておくことは避け、手順5の方法で一時的に上げます。

手順3：問い合わせと応答を記録する

誰がどの名前を引いたかを残したい場合は、verbosity を上げるのではなく、専用の項目を使います。

server:
    log-queries: yes
    log-replies: yes
    log-tag-queryreply: yes

• log-queries：届いた問い合わせを1件1行で記録します。
• log-replies：返した応答を、応答コードや処理時間とともに記録します。
• log-tag-queryreply：各行に query: や reply: の印を付け、問い合わせと応答の行を見分けやすくします。

出力される行の細かな形式はバージョンによって多少異なります（2026年10月現在）。集計スクリプトを書く場合は、手元のログの実物を見て形式を合わせてください。

問い合わせのログは、社内の利用者の閲覧先を記録することになります。保存期間を決め、閲覧できる人を限定し、必要に応じて社内規程やプライバシーポリシーとの整合を確認します。問題の調査が目的なら、期間を区切って有効にするのが現実的です。

手順4：調査向けのログを有効にする

名前解決の失敗を調べるときに役立つのが次の項目です。

server:
    log-servfail: yes
    val-log-level: 2
    log-local-actions: yes

• log-servfail：SERVFAIL を返したときに、その理由（上流の応答がない、検証に失敗した、など）を記録します。「ときどき名前が引けない」という相談の調査で、最初に有効にしたい項目です。
• val-log-level：DNSSEC の検証に失敗したときのログです。1 は失敗の事実を、2 は失敗の理由や問い合わせ元を含めて記録します。特定のドメインだけ引けない場合に、署名の期限切れなど相手側の問題かを判断できます。
• log-local-actions：local-zone や local-data の設定によって応答した記録です。社内名を定義している場合や、特定のドメインを拒否している場合に、その設定が効いているかを確かめられます。

手順5：設定を確認して反映する

設定を変えたら、反映の前に構文を確認します。

sudo unbound-checkconf
sudo systemctl restart unbound

調査のたびに設定ファイルを書き換えて再起動すると、キャッシュが消えて利用者の名前解決が一時的に遅くなります。unbound-control を有効にしておくと、再起動せずに verbosity を変えられます。

remote-control:
    control-enable: yes
    control-interface: /run/unbound.ctl

# 調査中だけ詳しくする
sudo unbound-control verbosity 3
# 調査が終わったら戻す
sudo unbound-control verbosity 1

control-interface にソケットファイルのパスを指定すると、ローカルからだけ操作できます。IP アドレスで待ち受ける場合は unbound-control-setup で証明書を作り、外部から操作できないアドレスに限定してください。unbound-control で変えた値は再起動すると設定ファイルの値に戻ります。

手順6：ログファイルをローテーションする

ファイルに出す場合は、logrotate で古いログを圧縮・削除します。ローテーションの後に unbound-control log_reopen を実行すると、Unbound が新しいファイルに書き始めます。

# /etc/logrotate.d/unbound
/var/log/unbound/unbound.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /usr/sbin/unbound-control log_reopen > /dev/null 2>&1 || true
    endscript
}

unbound-control の場所は環境によって異なるため、command -v unbound-control で確かめて書き換えます。設定後は sudo logrotate -d /etc/logrotate.d/unbound で、実際には回さずに動作を確認できます。

ログが出ないときの確認の順番

設定したのにログが出ない場合は、次の順に確認します。

1. 設定が読み込まれていない：追記したファイルが include の対象になっているか、unbound-checkconf が通るか、再起動したかを確認します。
2. **use-syslog が有効のまま**：logfile を指定していても syslog に出ています。journalctl -u unbound を見ます。
3. chroot のパスの問題：chroot の内側にファイルができていないかを探します。
4. 権限や AppArmor・SELinux による拒否：journalctl -u unbound や dmesg、監査ログに拒否の記録がないかを確認します。
5. verbosity が 0：エラー以外は出ません。

大量の問い合わせを記録したい場合

問い合わせ全件を長期間残して分析したい場合は、テキストのログより dnstap という仕組みが向いています。Unbound が dnstap に対応した形でビルドされていれば、dnstap: 節の設定で問い合わせと応答を専用の受信プログラムへ送れます。対応の有無は unbound -V の出力で確認できますが、パッケージによって含まれないこともあります。

まとめ

• 出力先は既定の syslog か、use-syslog: no と logfile によるファイルかを選びます。ファイルの場合は chroot・権限・AppArmor などに注意します。
• verbosity は普段 1 にし、調査のときだけ unbound-control verbosity で一時的に上げます。
• 問い合わせの記録は log-queries と log-replies で行い、個人に関わる情報として保存期間と閲覧者を決めます。
• 失敗の調査には log-servfail・val-log-level・log-local-actions が役立ちます。
• ファイルに出す場合は logrotate と unbound-control log_reopen でローテーションします。

• rsyslogのカスタム設定
• Unboundキャッシュと Public Resolver のキャッシュ整合性を取る方法