2026年6月13日

PowerDNS のアップグレード方法｜Authoritative Server をアップグレードノートに沿って安全に上げる

DNS・名前解決

PowerDNS Authoritative Server のアップグレードは、「今のバージョンと構成を把握する → 間にあるすべてのバージョンのアップグレードノートを読む → 設定とデータベースのバックアップを取る → 検証環境で試す → パッケージとスキーマを上げる → 応答を確かめる」の順に進めると、設定項目の廃止やスキーマ変更による停止を避けやすくなります。この記事では、各段階で何を確認するか、どこでつまずきやすいか、問題が出たときにどう戻すかを説明します。

対象と前提

PowerDNS には、権威サーバーの Authoritative Server、キャッシュサーバーの Recursor、負荷分散の dnsdist があり、それぞれ別の製品としてバージョンが付いています。この記事は Authoritative Server（以下 pdns）を対象にします。Recursor や dnsdist も進め方は同じですが、アップグレードノートは製品ごとに別なので、取り違えないようにしてください。

PowerDNS はリリース系列ごとにサポート期間を公開しており、古い系列はセキュリティ修正の対象から外れます。どの系列が現在サポートされているかは、公式ドキュメントのサポート終了（End of Life）の案内で確認します（2026年10月現在）。系列をまたぐアップグレードほど変更点が多くなるため、サポート切れの直前ではなく余裕のあるうちに計画するほうが安全です。

手順1：現状を把握する

まず、今どのバージョンがどこから入っているか、どのバックエンドを使っているかを確かめます。

pdns_control version
# Debian / Ubuntu：どのリポジトリから入っているか
apt policy pdns-server
# RHEL 系
dnf info pdns
# 使っているバックエンドと主な設定
grep -rhv '^\s*#' /etc/powerdns/pdns.conf /etc/powerdns/pdns.d/ 2>/dev/null | grep -v '^\s*$'

launch= の行が使っているバックエンドです。gmysql・gpgsql・gsqlite3 のような SQL 系か、bind、lmdb かによって、バックアップとスキーマ更新の方法が変わります。あわせて、次の点をメモしておきます。

DNSSEC で署名しているゾーンがあるか（pdnsutil list-all-zones と各ゾーンの鍵の状態）
このサーバーがプライマリかセカンダリか、ほかのサーバーとゾーン転送をしているか
HTTP API（api=yes）を使う管理画面やスクリプトがあるか
データベースを複数の pdns で共有・レプリケーションしているか

最後の2点は見落とされがちですが、API の仕様変更や共有しているスキーマの変更は、pdns 以外の部分に影響します。

手順2：アップグレードノートを読む

PowerDNS の公式ドキュメントには、バージョンごとの変更点をまとめたアップグレードノートがあります。今のバージョンから目標のバージョンまで、間にある系列のノートをすべて読みます。4.6 から 4.9 に上げるなら、4.7・4.8・4.9 それぞれへの変更点を確認する、という意味です。

特に探すのは次の3種類です。

削除・改名された設定項目：古い名前のまま起動すると、pdns が起動を拒否することがあります。手順1で書き出した設定と、ノートに挙がっている項目を突き合わせます。
既定値の変更：設定を書いていない項目の振る舞いが変わる場合です。動作が変わって困る項目は、明示的に値を書いておくと安全です。
データベーススキーマの変更：例えば 4.7 系ではカタログゾーンの導入に伴って SQL 系バックエンドのスキーマに変更がありました。スキーマ変更がある場合は、手順6の作業が必要です。

スクリプトで pdnsutil や pdns_control を使っている場合は、使っているサブコマンドが新しいバージョンでも有効かもあわせて確認します。

手順3：バックアップを取る

設定とデータを、戻せる形で保存します。SQL 系バックエンドでは、DNSSEC の鍵もデータベースの中（cryptokeys テーブル）に入っているため、データベースのバックアップがそのまま鍵のバックアップになります。

# 設定
sudo tar czf /root/pdns-conf-$(date +%F).tar.gz /etc/powerdns
# MySQL / MariaDB
sudo mysqldump --single-transaction pdns > /root/pdns-$(date +%F).sql
# PostgreSQL
sudo -u postgres pg_dump -Fc pdns > /root/pdns-$(date +%F).dump
# SQLite
sudo sqlite3 /var/lib/powerdns/pdns.sqlite3 ".backup '/root/pdns-$(date +%F).sqlite3'"

データベース名やファイルの場所は環境に合わせて読み替えてください。bind バックエンドで DNSSEC を使っている場合は、鍵を保存している SQLite のファイル（bind-dnssec-db に指定したもの）も忘れずに保存します。lmdb バックエンドは、pdns を止めてからファイルをコピーするのが安全です。

取ったバックアップは、検証環境に戻して読み込めるかを試すまで「使えるバックアップ」とはみなさないでください。手順4がその確認を兼ねます。

手順4：検証環境で試す

本番と同じ OS・同じバージョンの pdns を検証用のサーバーに用意し、手順3のバックアップを戻します。そこで手順5と6を先に実行し、次の点を確かめます。

pdns が新しいバージョンで起動し、ログに設定のエラーが出ないこと
pdnsutil check-all-zones でゾーンのエラーが出ないこと
本番と検証環境に同じ問い合わせをして、答えが一致すること

答えの比較は、主要な名前と種類を一覧にして dig で両方に問い合わせると効率よく進められます。DNSSEC のゾーンは dig +dnssec example.com DNSKEY で鍵と署名が返るかも見ます。ここで出た問題は本番でも起きるので、手順書に対処を書き足してから本番に進みます。

手順5：パッケージを上げる

PowerDNS が提供するリポジトリ（repo.powerdns.com）は、系列ごとに分かれています。Debian や Ubuntu では、リポジトリの行に bookworm-auth-49 のような「OS のコード名と系列」を含む名前が入るため、系列を上げるときはこの行を書き換えます。正確な行と署名鍵の入れ方は、repo.powerdns.com の案内に従ってください。

OS 標準のパッケージと PowerDNS のパッケージが混ざらないように、優先度を固定しておきます。

# /etc/apt/preferences.d/pdns
Package: pdns-*
Pin: origin repo.powerdns.com
Pin-Priority: 600

sudo apt update
apt list --upgradable 2>/dev/null | grep pdns
sudo systemctl stop pdns
sudo apt install --only-upgrade pdns-server pdns-backend-mysql

バックエンドのパッケージ名は使っているものに合わせます。pdns-server とバックエンドのパッケージは同じバージョンにそろえる必要があります。意図しないときに系列が上がらないよう、普段は apt-mark hold pdns-server pdns-backend-mysql で固定しておき、作業のときだけ外す運用もあります。RHEL 系では、リポジトリの定義ファイルを差し替えてから dnf upgrade pdns pdns-backend-mysql を実行します。

手順6：スキーマを更新する

アップグレードノートにスキーマ変更があった場合は、パッケージに含まれる更新用の SQL を適用します。ファイルの場所はパッケージによって違うため、一覧から探します。

# Debian / Ubuntu
dpkg -L pdns-backend-mysql | grep -i schema
# RHEL 系
rpm -ql pdns-backend-mysql | grep -i schema

4.3.0_to_4.7.0_schema.mysql.sql のように、どのバージョンからどのバージョンへの更新かがファイル名で分かるものが含まれています。今のスキーマのバージョンから順に、必要なものだけを適用します。

sudo mysql pdns < /path/to/4.3.0_to_4.7.0_schema.mysql.sql

複数の pdns が同じデータベースやレプリカを使っている場合、スキーマの変更はすべてのサーバーに及びます。古いバージョンの pdns が新しいスキーマで動くかどうかはノートで確かめ、分からない場合は全台を止める時間を取るか、検証環境で古いバージョンを新しいスキーマに接続して試します。

手順7：起動して確かめる

sudo systemctl start pdns
journalctl -u pdns -n 50 --no-pager
pdns_control version
sudo pdnsutil check-all-zones
dig @127.0.0.1 example.com SOA +norec

ログに設定項目の警告やエラーがないこと、バージョンが目標のものになっていること、SOA の答えの flags に aa が付くことを確かめます。セカンダリがある場合は、テスト用のレコードを1件変えて、セカンダリのシリアルが追いつくことも見ておくと、ゾーン転送と NOTIFY が動いていると判断できます。API を使う管理画面があれば、ゾーンの表示と更新を1回試します。

複数台の順番と切り戻し

権威サーバーが複数ある場合は、1台ずつ上げて、確認が済んでから次に進みます。プライマリとセカンダリの構成なら、影響の小さいセカンダリの1台から始めると、問題が出ても残りのサーバーで応答を続けられます。

切り戻しは、パッケージを元のバージョンに戻し、スキーマを変更していた場合はバックアップからデータベースを戻します。アップグレード後に追加・変更したレコードはバックアップに含まれないので、戻す前に書き出しておくか、作業中はレコードの変更を止めておきます。

まとめ

対象の製品（Authoritative・Recursor・dnsdist）を取り違えず、今のバージョンとバックエンド、DNSSEC、API、DB の共有を把握します。
目標までの間にあるすべての系列のアップグレードノートで、設定項目の廃止、既定値の変更、スキーマ変更を確認します。
設定と DB をバックアップし、検証環境に戻して試してから本番を上げます。
パッケージは系列ごとのリポジトリと Pin で管理し、スキーマ変更はパッケージ付属の SQL を順に適用します。
起動後はログ、pdnsutil check-all-zones、dig、セカンダリへの反映を確かめ、複数台は1台ずつ進めます。