CoreDNS で複数ゾーンを管理する設定｜サーバーブロックの分け方、file・auto プラグイン、設定の分割まで

CoreDNS で複数のゾーンを扱うには、Corefile にゾーンごとのサーバーブロックを書き、それぞれに file プラグインでゾーンファイルを割り当てるのが基本です。ゾーンが増えてきたら、ディレクトリ内のゾーンファイルを自動で読み込む auto プラグインや、import による設定の分割に切り替えると管理が楽になります。この記事では、Corefile の書き方、ゾーンを増やすときの手順、問い合わせがどのブロックに振り分けられるかの仕組み、確認方法とつまずきやすい点を説明します。

サーバーブロックとゾーンの関係

Corefile は「どのゾーンの問い合わせを、どのプラグインで処理するか」をブロック単位で書くファイルです。ブロックの先頭に書いたゾーン名（とポート）が、そのブロックの担当範囲になります。

CoreDNS は問い合わせを受けると、問い合わせ名に一致するゾーンのうち、最も長く一致するもの（最も具体的なもの）を持つブロックで処理します。たとえば example.com と .（ルート）のブロックがあれば、www.example.com は example.com のブロック、www.example.org は . のブロックで処理されます。この仕組みのおかげで、権威として答えるゾーンと、それ以外を外部に転送する設定を1つの Corefile に同居させられます。

もう1つ知っておきたいのは、ブロックの中でプラグインを書く順番は処理の順番にならないことです。プラグインの実行順は、CoreDNS をビルドしたときの plugin.cfg で決まっています。log を最後に書いても file より先に動くので、書く順番で挙動を変えようとしないでください。

基本形：ゾーンごとにブロックを分ける

ゾーンが2〜3個なら、ゾーンごとにブロックを書くのが最も読みやすい形です。

# /etc/coredns/Corefile
example.com {
    file /etc/coredns/zones/db.example.com
    log
    errors
}

example.net {
    file /etc/coredns/zones/db.example.net
    log
    errors
}

# 逆引きゾーン（192.0.2.0/24）
2.0.192.in-addr.arpa {
    file /etc/coredns/zones/db.192.0.2
    log
    errors
}

ポートを省略すると53番で待ち受けます。ゾーンファイルは BIND と同じ RFC 1035 形式で書きます。

; /etc/coredns/zones/db.example.com
$ORIGIN example.com.
$TTL 3600
@       IN SOA ns1.example.com. hostmaster.example.com. (
            2026101801 ; serial
            3600       ; refresh
            900        ; retry
            1209600    ; expire
            300 )      ; minimum
        IN NS  ns1.example.com.
        IN NS  ns2.example.com.
ns1     IN A   192.0.2.53
ns2     IN A   198.51.100.53
www     IN A   192.0.2.80
@       IN MX  10 mail.example.com.
mail    IN A   192.0.2.25

file プラグインはゾーンファイルを定期的に確認し、SOA のシリアルが変わっていれば読み直します（既定の間隔は1分です）。シリアルを上げずにレコードだけを書き換えても反映されないため、「直したのに変わらない」ときはまずシリアルを確認します。間隔は file のブロック内の reload で変えられます。

権威ゾーン以外の問い合わせをどうするか

CoreDNS を権威DNS専用にするなら、上の3ブロックだけで十分です。担当外の名前には REFUSED を返します。社内で「自社ゾーンは自分で答え、それ以外は外部へ転送する」使い方なら、ルートのブロックに forward を加えます。

. {
    forward . 192.0.2.1 198.51.100.1
    cache 300
    errors
}

インターネットに公開する権威DNSでは、この転送用ブロックを置かないか、置くなら acl プラグインなどで問い合わせ元を社内に限定します。誰からの再帰問い合わせにも答える状態は、DNS を使った攻撃の踏み台になるおそれがあります。

ゾーンが増えたら：auto プラグインで一括管理する

ゾーンが10個、20個と増えると、ブロックを1つずつ書くのは手間がかかり、書き漏れも起きます。auto プラグインを使うと、ディレクトリ内のゾーンファイルをファイル名からゾーン名を判断して読み込めます。

. {
    auto {
        directory /etc/coredns/zones
        reload 60s
    }
    log
    errors
}

既定では db.ゾーン名 という名前のファイルを、そのゾーンとして読み込みます。db.example.com は example.com、db.example.net は example.net です。ファイル名の規則を変えたい場合は、directory の後に正規表現とゾーン名のテンプレートを指定できます。

auto {
    # example.com.zone のような名前を読み込む
    directory /etc/coredns/zones (.*)\.zone {1}
}

この形にすると、新しいゾーンの追加は「ゾーンファイルを置く」だけで済み、Corefile を編集する必要がなくなります。削除もファイルを取り除けば次の確認時に反映されます。ただし auto が読む範囲はブロックのゾーン（上の例では .）の配下すべてになるので、ディレクトリに置き間違えたファイルもそのまま公開されます。ゾーンファイルの置き場は権威DNS専用にし、書き込める人を限定します。

file と auto は併用できます。DNSSEC の署名など特別な設定が要るゾーンだけ file で個別のブロックにし、それ以外を auto にまとめる構成も取れます。

Corefile を分割して管理する

ゾーンごとに設定が違う（転送先、ACL、ゾーン転送の相手が違う）場合は、import でファイルを分けると見通しがよくなります。共通の設定はスニペットにして使い回します。

# /etc/coredns/Corefile
(common) {
    log
    errors
}

import /etc/coredns/zones.d/*.conf

# /etc/coredns/zones.d/example.com.conf
example.com {
    file /etc/coredns/zones/db.example.com
    transfer {
        to 198.51.100.53
    }
    import common
}

transfer プラグインは、指定したセカンダリへのゾーン転送（AXFR・IXFR）を許可する設定です。セカンダリを持つゾーンでは、ブロックごとに転送先を書き分けられます。

import で読み込むファイルを追加・変更したときは、Corefile 自体の読み直しが要ります。reload プラグインを Corefile に書いておくと、変更を検知して自動で読み直します。手動で行うなら CoreDNS のプロセスに SIGUSR1 を送ります。読み直した設定に誤りがあると、CoreDNS は古い設定のまま動き続け、エラーをログに出します。

動作を確認する

本番の設定を変える前に、別のポートで新しい Corefile を起動して試すと安全です。

# 検証用に 1053 番で起動する（別の端末から問い合わせる）
coredns -conf /etc/coredns/Corefile -dns.port 1053

# ゾーンごとに SOA と代表的なレコードを確認する
dig @127.0.0.1 -p 1053 example.com SOA +norec
dig @127.0.0.1 -p 1053 www.example.net A +norec
dig @127.0.0.1 -p 1053 -x 192.0.2.80 +norec

応答の flags に aa があれば、そのゾーンの権威として答えています。aa がなく答えが返る場合は、権威ゾーンのブロックではなく転送用のブロックで処理されています。ゾーン名の綴りや、ゾーンファイルの $ORIGIN を確認します。

本番に反映した後は、ログ（systemd で動かしているなら journalctl -u coredns）に、ゾーンの読み込みに関するエラーが出ていないかを確認します。

つまずきやすい点

• ゾーンファイルの誤りでゾーンだけが消える：ゾーンファイルの文法に誤りがあると、そのゾーンは読み込まれず、問い合わせには SERVFAIL などが返ります。ほかのゾーンは動き続けるため気づきにくいので、変更後にゾーンごとの SOA を dig で確かめます。
• 同じゾーンを2つのブロックに書く：同じゾーン名とポートのブロックが重複すると起動時にエラーになります。import で分割していると重複に気づきにくいので、ゾーン1つにつき設定ファイル1つの規則にしておきます。
• ポート53の権限：一般ユーザーで動かすと53番で待ち受けられません。パッケージや systemd ユニットの設定（CAP_NET_BIND_SERVICE の付与など）を確認します。
• Kubernetes の CoreDNS：クラスタ内の CoreDNS は ConfigMap で Corefile を管理しています。社内ゾーンを追加する場合は、ゾーンファイルもマウントする必要があります。クラスタの名前解決全体に影響するので、検証用クラスタで試してから反映します。

プラグインのオプションや既定値は版によって変わることがあるため、作業前に公式ドキュメントの各プラグインのページと、手元の coredns -version を照らし合わせてください（2026年10月現在）。設定ファイルとゾーンファイルは変更前に控えを取り、バージョン管理しておくと切り戻しが簡単です。

まとめ

• CoreDNS は問い合わせ名に最も長く一致するゾーンのブロックで処理するため、ゾーンごとのブロックと転送用のルートブロックを同居させられます。
• 少数のゾーンは file でブロックごとに、ゾーンが多いときは auto でディレクトリから一括で読み込むと管理が楽になります。
• file と auto は SOA シリアルの変化で読み直すため、レコードを変えたらシリアルを上げます。
• 設定が複雑になったら import とスニペットで分割し、Corefile の変更は reload プラグインか SIGUSR1 で反映します。
• 本番の前に別ポートで起動し、ゾーンごとに dig で aa 付きの応答を確認します。

• CoreDNS のセカンダリ構成方法
• DNS の SOA レコードの設定方法