BIND から CoreDNS へ移行する手順｜named.conf の設定を Corefile に置き換えて切り替える

BIND から CoreDNS への移行は、BIND のゾーンファイルをほぼそのまま CoreDNS の file プラグインで読み込み、named.conf の各設定を Corefile のプラグインに置き換えてから、応答を突き合わせて切り替える流れで進めます。この記事では、移行できない機能の洗い出し、ゾーンファイルの取り出し方、named.conf の主な設定と Corefile の対応、検証用ポートでの並行テスト、切り替えと切り戻しまでを説明します。

CoreDNS は Kubernetes のクラスタ内 DNS として広く使われ、権威DNSとしても使えます。ただし BIND の機能をすべて持っているわけではありません。プラグインの有無や書式は版によって変わるため、手元のバイナリで coredns -version と coredns -plugins を確認しながら読み進めてください。以下は執筆時点の情報です（2026年10月現在）。作業は検証環境から始め、named.conf とゾーンファイル一式のバックアップを取ってから行います。

手順1：移行できない機能がないかを先に確認する

最初に named.conf を読み、CoreDNS に置き換えにくい機能を使っていないかを確認します。ここで止まる要素があれば、移行の範囲を変えるか、BIND を残す判断をします。

• **動的更新（allow-update・update-policy）**：nsupdate でレコードを書き換えている場合、CoreDNS の file プラグインは DNS UPDATE を受け付けません。Let's Encrypt の DNS-01 認証を nsupdate で自動化している、DHCP サーバーが逆引きを登録している、といった用途があると、そのままでは移行できません。
• **フルの再帰解決（recursion yes）**：CoreDNS の標準プラグインは、上流のリゾルバーへの転送（forward）とキャッシュ（cache）が中心で、ルートサーバーから自力で辿る再帰解決は標準では持っていません。BIND がキャッシュサーバーも兼ねているなら、その役割は Unbound などに分けるのが素直です。
• **DNSSEC の署名（dnssec-policy・inline-signing）**：署名の仕組みが変わると鍵と親ゾーンの DS レコードの扱いが変わります。後述のとおり、慎重な手順が必要です。
• RPZ（応答ポリシーゾーン）や細かなログ設定：同じ形で再現できるとは限りません。

手順2：ゾーンファイルを取り出す

BIND のプライマリゾーンは、通常はテキスト形式のゾーンファイルなので、そのまま使えます。ただし次の2点に注意します。

動的更新の内容がジャーナルに残っている場合：動的更新を受けるゾーンでは、変更が .jnl ファイルにたまり、ゾーンファイル本体に反映されていないことがあります。rndc sync -clean example.com でジャーナルの内容をゾーンファイルに書き戻してから取り出します。

セカンダリゾーンのファイル：BIND のセカンダリが保存するゾーンファイルは、既定でバイナリの raw 形式であることが多く、CoreDNS では読めません。named-compilezone でテキスト形式に変換します。

# raw 形式をテキスト形式に変換する例
named-compilezone -f raw -F text -o db.example.com.txt example.com /var/cache/bind/db.example.com

# 取り出したゾーンファイルの文法を確認
named-checkzone example.com db.example.com.txt

$INCLUDE で別ファイルを読み込んでいるゾーンは、CoreDNS 側での扱いが版によって異なるため、移行前に1つのファイルに展開しておくと安全です。

手順3：named.conf の設定を Corefile に置き換える

権威ゾーン（type primary / master）

BIND の zone 文は、Corefile のサーバーブロックと file プラグインに置き換えます。

# named.conf
zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { 198.51.100.2; };
    also-notify { 198.51.100.2; };
};

# Corefile
example.com {
    file /etc/coredns/zones/db.example.com {
        reload 1m
    }
    transfer {
        to 198.51.100.2
    }
    errors
    log
}

file プラグインは、一定間隔でゾーンファイルの SOA シリアルを見て、上がっていれば読み直します。BIND では rndc reload で読み込ませていた運用が、「シリアルを上げてファイルを保存する」だけに変わります。シリアルを上げ忘れると変更が反映されない点は、BIND と同じです。transfer の to に書いた相手にはゾーン転送を許可し、変更の通知（NOTIFY）も送られます。

ゾーンが多い場合は、ディレクトリ内のファイル名からゾーン名を決める auto プラグインを使うと、ゾーンごとにブロックを書かずに済みます。

セカンダリゾーン（type secondary / slave）

example.org {
    secondary {
        transfer from 192.0.2.1
    }
    errors
}

CoreDNS の secondary プラグインは、取得したゾーンをメモリ上に持ちます。BIND のようにファイルへ保存する前提ではないため、CoreDNS を再起動するとプライマリから取り直すまで答えられない時間が生じることがあります。プライマリが停止している間に再起動しないよう運用で注意します。

問い合わせ元の制限（allow-query・allow-recursion）

acl プラグインで、送信元のネットワークや問い合わせの種類ごとに許可・拒否を書きます。

. {
    acl {
        allow net 10.0.0.0/8 192.168.0.0/16
        block
    }
    forward . 192.0.2.53
    cache 300
}

転送やキャッシュを提供するブロックを誰にでも開けると、オープンリゾルバーとして増幅攻撃に悪用されます。権威ゾーンのブロックとは分け、転送側は利用者のネットワークからの問い合わせだけを受け付けるようにします。

view

BIND の view で社内と社外に別の答えを返していた場合は、CoreDNS の view プラグインで、送信元の条件ごとにサーバーブロックを選び分けます。比較的新しく追加されたプラグインなので、手元の版に含まれているかを coredns -plugins で確認します。

DNSSEC

BIND で署名しているゾーンを移すときは、次のどちらかを選びます。

• BIND の dnssec-signzone などで署名済みのゾーンファイルを作り、CoreDNS の file で配信する。鍵と署名の作業は従来どおり BIND のツールで行います。
• CoreDNS の dnssec や sign プラグインで署名し直す。この場合は鍵が変わるため、親ゾーンの DS レコードの差し替えを、鍵の切り替えの手順（新しい鍵を先に公開し、TTL が切れてから古い鍵を外す）に沿って行います。

DS と鍵の組み合わせが合わない時間ができると、検証を行うリゾルバーから名前が引けなくなります。自信がなければ、まず前者の方法で移し、署名方式の変更は別の作業として後から行うほうが安全です。

手順4：検証用ポートで並行テストする

同じサーバーで BIND と並べて試す場合は、CoreDNS を別のポートで起動します。

example.com:1053 {
    file /etc/coredns/zones/db.example.com
    errors
}

coredns -conf /etc/coredns/Corefile
dig @127.0.0.1 -p 1053 example.com SOA +norec

そのうえで、ゾーン内の名前と型の一覧を用意し、BIND（53番）と CoreDNS（1053番）の両方に問い合わせて差分を取ります。差が出やすいのは、ワイルドカード、委任先の NS とグルー、存在しない名前に対する応答（NXDOMAIN と NODATA の区別）、TXT の長い文字列の分割です。SOA のシリアルは同じファイルなら一致するはずなので、違えば読み込んでいるファイルが違うと分かります。

手順5：切り替えと切り戻し

1. TTL を下げる：NS を変える場合は、数日前に NS と主要なレコードの TTL を短くし、元の TTL が切れるのを待ちます。
2. 同じ IP で入れ替える：もっとも単純なのは、同じサーバーで named を止めて CoreDNS を 53 番で起動する方法です。親ゾーンの登録を変えずに済み、問題があれば CoreDNS を止めて named を起動し直すだけで戻せます。CoreDNS は root 以外のユーザーで動かし、53 番で待ち受けるための権限（CAP_NET_BIND_SERVICE など）を systemd のユニットで与える構成が一般的です。
3. セカンダリの確認：外部のセカンダリがある場合は、CoreDNS からのゾーン転送と NOTIFY が届いているか、セカンダリ側の SOA シリアルで確認します。
4. BIND を残しておく：切り替え後しばらくは、BIND の設定とゾーンを消さずに残し、すぐに戻せる状態を保ちます。

まとめ

• 動的更新・フルの再帰解決・DNSSEC の署名は、CoreDNS にそのまま移せないことがあるため、最初に洗い出します。
• ゾーンファイルは rndc sync -clean でジャーナルを反映し、raw 形式なら named-compilezone でテキストに変換してから使います。
• zone 文は file（多数なら auto）、転送の許可と通知は transfer、セカンダリは secondary、問い合わせ元の制限は acl、view は view に置き換えます。
• 別ポートで並行稼働させて応答を突き合わせ、同じ IP での入れ替えなら切り戻しも簡単です。

• CoreDNSの設定と活用方法（Corefileの書き方とKubernetesでのカスタマイズ）
• CoreDNS でACL設定する手順（acl プラグインでの制限）