BIND9からPowerDNSへの権威DNSサーバ移行｜ゾーン転送検証と段階的トラフィック切り替え

BIND9からPowerDNSへ移行する背景と2026年の動向

BIND9は長年にわたってLinux環境における権威DNSサーバの事実上の標準でしたが、設定ファイルの複雑さやAPIによる動的管理の難しさから、近年はPowerDNSへの移行を選択する運用チームが増えています。特に2024年以降、クラウドネイティブ環境やInfrastructure as Codeの浸透に伴い、REST APIで完結するDNS管理を求める声が高まっており、PowerDNSのAuthoritativeサーバ（pdns）はその需要に正面から応える設計を持っています。

PowerDNSはBackend APIの抽象化によってMySQLやPostgreSQL、SQLiteなど複数のデータストアをプラグイン形式で利用できます。ゾーンデータをRDBに格納するため、Gitによるバージョン管理やAnsibleによる自動投入が自然な形で組み合わせられます。一方でBIND9のゾーンファイル形式（RFC 1035互換）はそのままインポートできる変換ツールも整備されており、移行の技術的障壁は以前より大きく下がっています。本記事では、既存のBIND9環境を止めずにPowerDNSへ段階的に切り替えるシナリオを中心に解説します。

移行前の準備：ゾーンデータの確認とエクスポート

移行作業の起点は、現行BIND9環境の正確な棚卸しです。まず設定ファイルの構文チェックと、すべてのゾーンファイルの整合性検証を行います。

# named.conf全体の構文チェック
named-checkconf /etc/named.conf

# 特定ゾーンの検証（example.comの場合）
named-checkzone example.com /var/named/example.com.zone

エラーがなければ、AXFRでゾーンデータをファイルとして取り出します。BIND9を稼働させたままloopbackアドレスに対してAXFRを発行し、標準出力をファイルに保存するのが最も確実な方法です。

dig AXFR example.com @127.0.0.1 > /tmp/example.com.axfr

複数のゾーンが存在する場合は、named-checkconf -pでゾーン一覧を確認してからスクリプトでループ処理するとミスが減ります。エクスポートしたファイルはバージョン管理リポジトリに退避しておき、移行作業のロールバック時に参照できる状態にしておきます。なお、TTLが長いゾーン（1時間超）は切り替え前日に短縮しておくことを強くおすすめします。目安は300〜600秒です。切り替え後に問題が発生した際の影響範囲を最小化できます。

PowerDNSのインストールとゾーンインポート

2026年時点では、PowerDNS Authoritative Server 4.9系がDebian 12（Bookworm）およびRocky Linux 9向けの安定版として主流になっています。公式リポジトリを追加してインストールします。

# Debian 12の場合
echo "deb [signed-by=/etc/apt/keyrings/powerdns.gpg] http://repo.powerdns.com/debian bookworm-auth-49 main" \
  | sudo tee /etc/apt/sources.list.d/pdns.list
sudo apt update && sudo apt install pdns-server pdns-backend-sqlite3

バックエンドにSQLiteを選ぶのは小〜中規模環境での移行初期に向いています。本番移行後にゾーン数やクエリ数が増えたタイミングでMySQLやPostgreSQLに移行するパターンが現場では多く見られます。スキーマの初期化は付属のSQLファイルで行います。

sqlite3 /var/lib/powerdns/pdns.sqlite3 \
  < /usr/share/doc/pdns-backend-sqlite3/schema.sqlite3.sql

ゾーンのインポートにはpdnsutilコマンドを使います。先ほどエクスポートしたAXFRファイルをそのまま読み込めます。

# ゾーンを作成してからゾーンファイルをロード
pdnsutil create-zone example.com
pdnsutil load-zone example.com /tmp/example.com.axfr

# インポート後の整合性チェック
pdnsutil check-zone example.com

check-zoneが警告なしで完了すれば、PowerDNS側のデータは正常な状態です。pdnsutil list-zone example.comでレコード一覧を確認し、SOAシリアルがBIND9と一致していることを目視で確認しておきます。

ゾーン転送による並行運用と検証

移行の安全性を高める有効な手段が、BIND9をプライマリ・PowerDNSをセカンダリとして一時的に並行運用する構成です。PowerDNSがBIND9からゾーン転送（AXFR/IXFR）を受け取りながら動作するため、本番トラフィックを向ける前にレコード差分を継続的に検証できます。

PowerDNS側の設定（/etc/powerdns/pdns.conf）にスレーブモードを有効にします。

slave=yes
superslave=yes

BIND9側ではPowerDNSのIPアドレスからのゾーン転送を許可します。named.confのゾーン定義にallow-transferとalso-notifyを追加し、SOA更新時にPowerDNSへNOTIFYが飛ぶようにします。並行運用開始後は、両サーバに同じクエリを投げて応答を比較します。

# BIND9とPowerDNSの応答を比較する例
diff \
  <(dig +noall +answer A www.example.com @bind9-ip) \
  <(dig +noall +answer A www.example.com @pdns-ip)

差分がなければ正常です。DNSSECを運用している場合はRRSIGレコードの有効期限も確認してください。PowerDNS側でDNSSECを再セットアップする必要がある場合、pdnsutil secure-zoneとpdnsutil rectify-zoneの実行順序を間違えると署名が壊れるため注意が必要です。

段階的トラフィック切り替えとロールバック手順

検証が完了したら、いよいよトラフィックをPowerDNSへ移します。一度に全切り替えするのではなく、ネームサーバを段階的に入れ替えるアプローチが推奨されます。

• ステップ1：レジストラのNSレコードにPowerDNSのIPを追記し、既存のBIND9 NSと共存させる。TTLが短縮済みであればキャッシュの影響が数分以内に収まる。
• ステップ2：約24時間以上経過して問題がないことを確認後、BIND9のNSレコードをレジストラから削除する。
• ステップ3：BIND9のSOAシリアルを更新せず、PowerDNSをプライマリに昇格させる（pdns.confでmaster=yes）。

ロールバックが必要になった場合の手順はシンプルです。レジストラでNSレコードをBIND9のIPに戻し、TTLが切れるまで待つだけです。BIND9は並行運用中も稼働し続けているため、データが失われる心配はありません。ただし、切り替え後にPowerDNS側でゾーンを編集してしまうと、BIND9との差分が生じてロールバック後に不整合が起きます。切り替え完了を宣言するまでの間は、ゾーン編集をBIND9側でのみ行い、AXFRでPowerDNSに反映するルールを徹底することが重要です。

監視の観点では、切り替え前後でdnsdistやdnsperfによるクエリ応答時間の計測を行い、PowerDNSのパフォーマンスがBIND9と同等以上であることを数値で確認しておくと、後工程の判断材料になります。

2026年現行環境での差分と注意点

2026年の標準的なLinux環境で移行を行う場合、いくつかの点でかつての情報と状況が異なっています。

systemdによるサービス管理：PowerDNS 4.8以降はsystemdのsocket activationに対応しており、pdns.serviceの起動順序の制御が以前より柔軟になっています。BIND9と同じホストで一時的に共存させる際は、53番ポートの競合を避けるため、PowerDNSを別ポート（例：5353）でリスンさせてからトラフィックをiptablesやnftablesでリダイレクトする手法が使われることがあります。

PowerDNS Recursor との混同：パッケージ名の類似から、権威サーバ（pdns-server）とキャッシュリゾルバ（pdns-recursor）を誤ってインストールするケースが依然として見受けられます。BIND9は権威とキャッシュを1プロセスで兼ねられましたが、PowerDNSは両者が完全に別プロセスです。移行対象が権威DNSであればpdns-serverのみをインストールし、pdns-recursorは別途必要な場合のみ導入します。

Rocky Linux 9 / AlmaLinux 9 での注意：EL9系では公式リポジトリのPowerDNSパッケージが4.7系に留まる場合があります。4.9系を使いたい場合は公式のPowerDNS RPMリポジトリを追加する必要があります。SELinuxのポリシーもデフォルトではpdnsのSQLiteパスへのアクセスを制限することがあるため、audit2allowでポリシーを生成するか、データディレクトリをrestoreconで正しくラベル付けしておく必要があります。

API活用の現実：PowerDNSのREST APIは移行完了後の運用フェーズで真価を発揮します。Terraform用のterraform-provider-powerdnsやAnsibleのコレクションが整備されており、ゾーン編集をCIパイプラインに組み込む運用が現場に浸透しています。BIND9のゾーンファイルをGitで管理していた環境は、このタイミングでAPI駆動の管理へ移行することで、ヒューマンエラーの発生率を大幅に下げられます。移行そのものよりも、この運用モデルの変化が組織に与える影響のほうが大きいことが多く、チームへの周知と手順書の整備を並行して進めることが、スムーズな定着への鍵となります。