PowerDNS の権威サーバー（PowerDNS Authoritative Server）の応答を速くしたいときは、まず統計値で「パケットキャッシュにどれだけ当たっているか」「バックエンドの DB を待つ問い合わせが溜まっていないか」を確認し、キャッシュの TTL、スレッド数、DB 側の順に調整します。多くの場合、遅さの原因はスレッド数ではなく DB バックエンドへの問い合わせなので、闇雲に設定値を上げるより、計測してから1項目ずつ変えるほうが早く改善します。この記事では、権威サーバーとしての PowerDNS に絞って、計測の方法と主な設定項目を説明します。
フルリゾルバ（キャッシュDNS）である PowerDNS Recursor は別のソフトで、設定項目も考え方も異なります。この記事は権威サーバー側の話です。設定名や既定値は版によって変わることがあるため、手元の版の公式ドキュメント（doc.powerdns.com の Authoritative Server の Settings）と照らし合わせてください。以下は執筆時点の情報です（2026年10月現在）。設定を変える前には pdns.conf と DB をバックアップし、検証環境で負荷をかけて確認してから本番に入れます。
まず現状を計測する
統計値を見る
PowerDNS には動作中の統計を取り出す pdns_control があります。
# 主な統計値をまとめて表示
pdns_control show '*'
# 個別に見る例
pdns_control show packetcache-hit
pdns_control show packetcache-miss
pdns_control show latency
pdns_control show qsize-q見るべきポイントは次のとおりです。
- packetcache-hit と packetcache-miss の比率：パケットキャッシュは、同じ問い合わせへの応答パケットをそのまま返す仕組みです。ヒット率が低いと、多くの問い合わせが DB まで届いています。
- latency：平均応答時間（マイクロ秒）です。キャッシュにヒットした応答も含めた平均なので、DB が遅いと値が跳ね上がります。
- qsize-q：DB の処理を待っている問い合わせの数です。常に0付近なら DB は追いついています。継続して増えるなら、DB かスレッド数がボトルネックです。
組み込みの Web サーバーと API を有効にしている場合は、同じ統計を HTTP 経由で取得でき、Prometheus 形式で出力できる版もあります。監視の仕組みに取り込み、時間帯ごとの変化を見られるようにしておくと、調整の効果を比べやすくなります。
負荷をかけて比べる
設定の効果は、同じ条件で負荷をかけて比べないと分かりません。DNS-OARC が公開している dnsperf は、問い合わせのリストを指定した速度で送り、処理できた件数や応答時間を出してくれます。
# queries.txt の例（1行に「名前 種別」）
# www.example.com A
# example.com MX
dnsperf -s 192.0.2.53 -d queries.txt -l 30本番サーバーに負荷試験をかけるとサービスに影響するため、検証用のサーバーで行います。問い合わせのリストは、実際のログから作ると現実に近い結果になります。
キャッシュを調整する
権威サーバーの PowerDNS には主に2種類のキャッシュがあります。
- パケットキャッシュ：応答パケット全体を保存します。設定は
cache-ttl（保存する秒数）とmax-packet-cache-entries（件数の上限）です。 - クエリキャッシュ：バックエンドへの問い合わせ結果を保存します。設定は
query-cache-ttl（あるレコードの結果）、negquery-cache-ttl（存在しない結果）、max-cache-entries（件数の上限）です。
# /etc/powerdns/pdns.conf（抜粋・値は例）
cache-ttl=60
query-cache-ttl=60
negquery-cache-ttl=60
max-packet-cache-entries=1000000
max-cache-entries=1000000キャッシュの秒数を延ばすとヒット率は上がりますが、そのぶんレコードを変更してから応答に反映されるまでが遅くなります。既定値は数十秒程度と短めに設定されているので、変更の頻度と相談して決めます。変更直後にすぐ反映させたいときは、キャッシュを消すことができます。
# example.com 以下のキャッシュを消す
pdns_control purge 'example.com$'API でレコードを更新する運用なら、更新処理のあとにこの purge を組み込んでおくと、キャッシュを長めにしても反映の遅れが問題になりにくくなります。
件数の上限を上げるとメモリを使うため、ゾーンのレコード数と問い合わせの種類から、実際に必要な量を見積もってから上げます。pdns_control ccounts でキャッシュの現在の件数を確認できます。
スレッドと受信の調整
PowerDNS は、パケットを受け取るスレッド（receiver）と、バックエンドに問い合わせるスレッド（distributor）を分けて動かします。
receiver-threads=2
distributor-threads=3
reuseport=yesreceiver-threads：受信スレッドの数です。CPU コアに余裕があり、受信側で CPU を使い切っている場合に増やします。複数のスレッドで同じポートを分け合うにはreuseportを有効にします（OS が対応している必要があります）。distributor-threads：受信スレッドごとの、DB に問い合わせるスレッドの数です。DB 接続の数は概ね「受信スレッド数 × distributor スレッド数」になるため、増やしすぎると DB 側の接続上限に当たります。
スレッドを増やして改善するのは、CPU に余裕があるのに処理が追いつかない場合だけです。qsize-q が増えていて DB の CPU も高いなら、スレッドを増やすとかえって DB を圧迫します。その場合は次の DB 側の対策を先に行います。
DB バックエンド側を見直す
MySQL / MariaDB や PostgreSQL をバックエンドにしている場合、キャッシュに当たらなかった問い合わせはすべて SQL になります。
- スキーマとインデックス：公式ドキュメントに載っているスキーマ（版ごとに用意されています）をそのまま使っているかを確認します。独自にテーブルを作ったり、インデックスを削ったりしていると、検索が遅くなります。アップグレードのたびにスキーマ変更の有無も確認します。
- DB サーバーのメモリ：MySQL / MariaDB なら InnoDB のバッファプールに、レコード数に対して十分なメモリを割り当て、データがメモリに乗るようにします。
- 遅い SQL の特定：DB のスロークエリログを有効にし、PowerDNS からの問い合わせで時間がかかっているものがないかを見ます。
ゾーンの変更がほとんどないなら、DB を使わずに bind バックエンド（ゾーンファイルを読み込む方式）や LMDB バックエンドに切り替える選択肢もあります。どのバックエンドが合うかはゾーン数や更新方法によるため、移行する場合は検証環境で同じ負荷をかけて比べてから決めます。
過負荷のときの振る舞いを決めておく
DB が一時的に遅くなったときの動きを、次の設定で決められます。
overload-queue-length：DB 待ちの問い合わせがこの数を超えたら、新しい問い合わせにはパケットキャッシュにあるものだけで答えます。既定では無効です。queue-limit：DB 待ちがこの数を超えたら、処理が回復しないとみなしてサーバープロセスを再起動します。
overload-queue-length を queue-limit より小さい値で設定しておくと、DB が詰まったときに、再起動まで行く前にキャッシュで答え続ける段階を挟めます。値は、平常時の qsize-q の推移を見てから決めます。
さらに負荷が高い場合
1台の調整で足りない場合は、台数を増やす方向を考えます。権威サーバーは複数台に同じゾーンを持たせ、NS レコードで分散させるのが基本です。PowerDNS が開発している dnsdist を前段に置くと、複数の PowerDNS への振り分けや、問い合わせ元ごとの流量制限をまとめて行えます。
まとめ
pdns_control showでパケットキャッシュのヒット率、latency、qsize-qを確認し、ボトルネックがキャッシュ・スレッド・DB のどこかを見極めます。- キャッシュは
cache-ttlなどの秒数と件数で調整し、反映の遅れはpdns_control purgeで補います。 - スレッドは CPU に余裕があるときだけ増やし、DB 接続数の増加に注意します。DB はスキーマ・メモリ・スロークエリを見直します。
- 変更は1項目ずつ、検証環境で
dnsperfなどを使って比べてから本番に入れます。