2026年6月13日

2026年6月13日

PowerDNS でログ設定する手順|Authoritative Server の loglevel・クエリログ・journald と rsyslog への出力

PowerDNS Authoritative Server のログは、pdns.conf の loglevel で「どこまで細かく出すか」を決め、出力先は起動方法(systemd か syslog か)で決まります。問い合わせ1件ずつの記録は log-dns-queries、バックエンドDBに発行した SQL の記録は query-logging で、どちらも調査のときだけ一時的に有効にするのが基本です。この記事では、ログの量と出力先の決め方、ファイルへの書き出しとローテーション、クエリログを使うときの注意、ログが出ないときの確認を順に説明します。

対象は PowerDNS Authoritative Server(pdns_server)の 4.x 系以降です。設定名は版によって追加・変更されることがあるため、使っている版の公式ドキュメントで設定項目を確認してください(2026年10月現在)。キャッシュDNSの PowerDNS Recursor と、ロードバランサの dnsdist はログの設定体系が別なので、最後に簡単に触れます。

まず現状を確認する

設定を変える前に、版と設定ファイルの場所、実際に効いている起動オプションを確認します。ここを飛ばすと「設定を書いたのに変わらない」原因になります。

# 動いているサーバーの版
sudo pdns_control version

# 設定ファイル(Debian・Ubuntu 系は /etc/powerdns/、RHEL 系は /etc/pdns/ が一般的)
ls /etc/powerdns/ /etc/pdns/ 2>/dev/null
grep -vE '^\s*(#|$)' /etc/powerdns/pdns.conf

# 追加の設定ディレクトリを読み込んでいるか
grep -n 'include-dir' /etc/powerdns/pdns.conf

# systemd のユニットに付いている起動オプション
systemctl cat pdns

systemctl cat pdns の ExecStart= は特に大事です。配布パッケージのユニットでは、--disable-syslog や --log-timestamp=no などが付いていることがあります。コマンドラインの指定は pdns.conf より優先されるので、ここに --disable-syslog があると、設定ファイル側で syslog の設定を書いても syslog には送られません。その場合のログは標準エラー出力から journald に入ります。

loglevel でログの量を決める

loglevel は 0 から 7 までの数字で、syslog の重要度に対応しています。数字が大きいほど細かいログまで出て、指定した値以下のものがすべて記録されます。

  • 3:エラー(error)まで
  • 4:警告(warning)まで。既定値
  • 5:通知(notice)まで。クエリログを見るときに要る
  • 6:情報(info)まで
  • 7:デバッグ(debug)まで

普段の運用は既定の 4 のままで十分です。3 より小さくすると起動失敗の理由まで消えてしまうので、公式にも推奨されていません。調査のときに 6 や 7 に上げる場合は、ログが急に増えてディスクや journald の容量を圧迫しないか見ながら、終わったら元に戻します。

# /etc/powerdns/pdns.conf(include-dir を使っているなら pdns.d/ 配下に別ファイルで書いてもよい)
loglevel=4

変更後は設定の読み直しのために再起動します。

sudo systemctl restart pdns
sudo journalctl -u pdns -n 50 --no-pager

再起動直後のログに、待ち受けアドレスやバックエンドの起動に関する行が出ていれば、設定ファイルは読み込まれています。権威DNSを再起動すると数秒の応答停止が起きるので、セカンダリがない構成では時間帯を選びます。

出力先を決める

journald で見る(systemd 環境の既定)

systemd で動かしている場合、まずは journald でログを見るのが手軽です。

# 追いかけて表示
sudo journalctl -u pdns -f

# 時間を区切って表示
sudo journalctl -u pdns --since "2026-10-18 09:00" --until "2026-10-18 10:00"

# 特定の語を含む行だけ
sudo journalctl -u pdns --since today | grep -i -E 'error|warn|fail'

journald の保存先が揮発領域(/run/log/journal)だと、OS の再起動でログが消えます。障害の後で原因を追えるように、/var/log/journal を作って永続化しておくと安心です。保存量の上限は /etc/systemd/journald.conf の SystemMaxUse= などで決めます。

標準エラー出力経由で入ったログは、行ごとの重要度が journald に正しく伝わらないことがあります。重要度で絞り込むより、語句で絞り込むほうが取りこぼしが少なくなります。

rsyslog でファイルに書き出す

ログをファイルにまとめて、ログ収集の仕組みに渡したい場合は rsyslog を使います。journald に入ったログは、多くのディストリビューションで rsyslog にも転送されています。まず、PowerDNS のログがどの名前(プログラム名)で記録されているかを確認します。

sudo journalctl -u pdns -n 5 -o verbose | grep SYSLOG_IDENTIFIER

表示された名前(多くは pdns_server)で振り分ける設定を置きます。

# /etc/rsyslog.d/30-pdns.conf
if $programname == 'pdns_server' then {
    action(type="omfile" file="/var/log/pdns/pdns.log")
    stop
}
sudo mkdir -p /var/log/pdns
sudo rsyslogd -N1          # 構文チェック
sudo systemctl restart rsyslog

stop を書くと、同じ行が /var/log/syslog などに二重に記録されなくなります。ディレクトリの所有者や権限が rsyslog の実行ユーザーと合わないと書き込めないので、ファイルが作られないときは rsyslog 自身のログを確認します。

ユニットから --disable-syslog を外して syslog に直接送り、logging-facility=0(LOCAL0 に出す設定)を使って facility で振り分ける方法もあります。ユニットを書き換えるときは、パッケージのファイルを直接編集せず systemctl edit pdns で上書き設定を作ります。パッケージの更新で変更が消えるのを防げます。

ローテーション

ファイルに書き出したら、logrotate の設定も用意します。

# /etc/logrotate.d/pdns
/var/log/pdns/pdns.log {
    daily
    rotate 14
    compress
    delaycompress
    missingok
    notifempty
    postrotate
        /usr/lib/rsyslog/rsyslog-rotate 2>/dev/null || systemctl kill -s HUP rsyslog.service
    endscript
}

postrotate で rsyslog にファイルを開き直させます。rsyslog-rotate は Debian 系のパッケージにある補助スクリプトで、ない環境では HUP を送る後半のコマンドが使われます。sudo logrotate -d /etc/logrotate.d/pdns で、実際には回さずに動作を確認できます。

問い合わせを記録する(クエリログ)

log-dns-queries:受けた問い合わせを1件ずつ記録

「特定のクライアントから問い合わせが来ているか」「どの名前が引かれているか」を確かめたいときは、log-dns-queries を使います。

log-dns-queries=yes
loglevel=5

loglevel を 5 以上にしないとクエリの行は出力されません。問い合わせ1件ごとにログを書くため、問い合わせの多いサーバーでは処理性能が落ち、ログの量も急に増えます。調べたい事象が再現したら、すぐに no に戻して再起動します。

log-dns-details を yes にすると、問い合わせ処理に関する補足的な情報も記録されます。こちらも量が増えるため、既定の no のまま運用し、調査のときだけ使います。

query-logging:バックエンドDBへの SQL を記録

MySQL・PostgreSQL などの汎用SQLバックエンド(gmysql・gpgsql など)を使っている場合、query-logging=yes にすると、バックエンドが発行した SQL を記録できます。「レコードを登録したのに返らない」ときに、どんな条件で検索しているかを見るのに役立ちます。

この設定は動作中のサーバーでも切り替えられます。

sudo pdns_control set query-logging yes
# 確認が済んだら戻す
sudo pdns_control set query-logging no

pdns_control set で変更できる項目は限られており、版によっても違います。エラーになる場合は pdns.conf に書いて再起動します。SQL の行が出ないときは、loglevel を一時的に上げて確認します。

記録する前に考えておくこと

クエリログには問い合わせ元の IP アドレスが残ります。社内のクライアントや利用者を特定できる情報になりうるため、保存期間とアクセスできる人を決めておきます。長期的に問い合わせの傾向を集計したい場合は、権威サーバー本体で全件を記録するより、前段の dnsdist で記録する、統計情報を Web サーバー機能や API から取得するといった方法のほうが負荷を抑えられます。

ログが出ない・変わらないときの確認

よくある原因から順に確認します。

  1. ユニットの起動オプションが優先されている:systemctl cat pdns で ExecStart= を確認します。--disable-syslog があれば syslog には出ず、journald にだけ入ります。
  2. 別の設定ファイルを編集している:include-dir の配下に同じ設定が書かれていると、後から読まれたほうが効きます。grep -rn 'loglevel\|log-dns' /etc/powerdns/ で重複を探します。
  3. loglevel が足りない:クエリログは 5 以上でないと出ません。
  4. 再起動していない:pdns.conf の変更は再起動するまで反映されません。pdns_control set で変えたものは、再起動すると pdns.conf の値に戻ります。
  5. journald が流量を制限している:大量のログを短時間に出すと、journald の流量制限で一部が捨てられることがあります。journalctl -u systemd-journald に抑制のメッセージが出ていないか確認します。

確認のための問い合わせは、サーバー上から送ると切り分けが楽です。

dig @127.0.0.1 example.com SOA +norec
sudo journalctl -u pdns -n 20 --no-pager

Recursor と dnsdist のログは別の設定

PowerDNS Recursor(キャッシュDNS)は、Authoritative Server とは設定ファイルも設定名も別です。問い合わせのログは quiet という設定で切り替える仕組みで、5.x 系では設定ファイルの形式が YAML に移行しつつあります。dnsdist は Lua の設定ファイルで、ログや dnstap の出力を設定します。どちらも版ごとの差が大きいので、使っている製品と版のドキュメントを確認してから設定してください。

まとめ

  • ログの細かさは loglevel(0〜7、既定 4)で決めます。普段は 4 のまま、調査のときだけ上げて、終わったら戻します。
  • systemd 環境では、まずユニットの起動オプションを確認します。--disable-syslog が付いていればログは journald に入ります。
  • ファイルに残すなら、rsyslog でプログラム名ごとに振り分け、logrotate でローテーションします。
  • log-dns-queries は問い合わせの記録、query-logging はバックエンドの SQL の記録です。どちらも負荷とログ量が増えるので一時的に使い、記録した IP アドレスの扱いを決めておきます。
  • 設定が効かないときは、起動オプション・重複した設定ファイル・loglevel・再起動の有無の順に確認します。

お気軽にご相談ください

お見積りへ お問い合わせへ
▲