Cloudflare DNS でセカンダリ設定する手順｜ゾーン転送の向き・TSIG・同期確認まで

Cloudflare DNS で「セカンダリ」を組むときは、まず向きを決めます。自前のプライマリ（BIND など）から Cloudflare にゾーンを転送させて Cloudflare をセカンダリにする構成と、Cloudflare をプライマリにして別の DNS 事業者をセカンダリにする構成の2つがあり、設定する場所も確認方法も違います。この記事では、両方の構成の考え方、BIND 側の TSIG 付きゾーン転送の設定、Cloudflare 側で用意するもの、同期できているかの確かめ方とつまずきやすい点を説明します。

なお、Cloudflare のゾーン転送機能（受信・送信とも）は、一般向けの無料・個人向けプランでは使えず、主に Enterprise 契約向けの機能として案内されています（2026年10月現在）。提供条件や画面の項目名は変わることがあるため、着手前に Cloudflare の公式ドキュメント（Secondary DNS の項目）で対象プランを確認してください。

Cloudflare の「セカンダリ」には2つの向きがある

受信ゾーン転送の構成では、レコードの編集はプライマリ側で行い、Cloudflare は AXFR／IXFR で複製を受け取って応答するだけです。プライマリをインターネットに公開せず、転送専用にする「隠しプライマリ（hidden primary）」の形にすることもできます。

送信ゾーン転送の構成では、Cloudflare 上のレコードが原本になり、他社のネームサーバーが Cloudflare から転送を受けます。レジストラに登録する NS に両方の事業者のネームサーバーを並べることで、片方の事業者に障害が起きても名前解決を続けやすくなります。

どちらの構成でも、仕組みの土台は同じです。プライマリはゾーンが変わると SOA のシリアル番号を上げ、NOTIFY でセカンダリに知らせます。セカンダリは SOA のシリアルを比べて、新しければ転送を受けます。NOTIFY が届かなくても、SOA の refresh 間隔ごとにセカンダリが確認しにいきます。転送の認証には TSIG（共有鍵による署名）を使い、相手の IP アドレス制限と組み合わせるのが一般的です。

構成1：自前の BIND をプライマリにして Cloudflare をセカンダリにする

BIND 側で TSIG 鍵を作る

転送専用の鍵を作ります。アルゴリズムは HMAC-SHA256 にしておくと、多くの事業者で扱えます。

sudo tsig-keygen -a hmac-sha256 cf-xfr | sudo tee /etc/bind/cf-xfr.key
sudo chown root:bind /etc/bind/cf-xfr.key
sudo chmod 640 /etc/bind/cf-xfr.key

出力される secret の値は、あとで Cloudflare 側に登録します。鍵はパスワードと同じ扱いで、チャットやチケットに貼らず、ゾーンファイルと一緒に公開リポジトリへ入れないようにします。

ゾーンの転送と NOTIFY を許可する

named.conf に鍵を読み込み、対象ゾーンで転送を鍵付きの要求だけに限定します。設定ファイルを書き換える前にバックアップを取っておきます。

include "/etc/bind/cf-xfr.key";

zone "example.com" {
    type primary;
    file "/etc/bind/zones/db.example.com";
    allow-transfer { key "cf-xfr"; };
    notify explicit;
    also-notify { 192.0.2.10; 192.0.2.11; };  // Cloudflare の公式ドキュメントに載っている NOTIFY 送信先に置き換える
};

notify explicit; は、also-notify に書いた相手にだけ NOTIFY を送る指定です。Cloudflare が転送の取得に使う送信元 IP アドレスと、NOTIFY を受け付けるアドレスは公式ドキュメントに一覧があるので、例の 192.0.2.x をそれに置き換え、ファイアウォールでも TCP／UDP の 53 番をその範囲から許可します。ゾーン転送は TCP を使うため、UDP だけ開けていると転送が失敗します。

設定の文法を確かめてから反映します。

sudo named-checkconf
sudo named-checkzone example.com /etc/bind/zones/db.example.com
sudo rndc reload example.com

Cloudflare 側で用意するもの

Cloudflare 側では、ゾーンを「セカンダリ」として追加し、プライマリの情報を登録します。画面の名称は変わることがありますが、登録する内容は次の3つです。

• プライマリ（ピア）の情報：プライマリサーバーの IP アドレスとポート（通常 53）
• TSIG 鍵：BIND で作った鍵の名前（例では cf-xfr）、アルゴリズム（hmac-sha256）、secret の値
• ゾーンとの紐付け：どのゾーンをどのピアから受け取るか

登録すると、Cloudflare は最初の転送を行い、そのゾーンに割り当てたネームサーバーで応答を始めます。ここではまだレジストラの NS は変えません。次の確認手順で、Cloudflare のネームサーバーが正しいレコードを返すことを見てから切り替えます。

ゾーンファイル側の NS と SOA を整える

切り替え後は、レジストラに登録した NS と、ゾーンファイル頂点の NS レコードが一致している状態にします。一致していないと、権威サーバーとして返す NS と親ゾーンの委任がずれ、リゾルバーによって挙動が変わる原因になります。隠しプライマリにする場合、プライマリ自身のホスト名はゾーンの NS に書きません。

SOA の refresh・retry・expire は、プライマリと連絡が取れないときの振る舞いを決めます。とくに expire は、プライマリが長く止まったときにセカンダリが応答をやめるまでの期間なので、短すぎる値にしないようにします。

構成2：Cloudflare をプライマリにして他社をセカンダリにする

送信ゾーン転送では、向きが逆になるだけで考え方は同じです。

1. Cloudflare 側で、そのゾーンの送信ゾーン転送を有効にする
2. 転送を許可する相手（セカンダリ事業者の転送元 IP アドレス）と TSIG 鍵を登録する
3. セカンダリ事業者の管理画面で、プライマリとして Cloudflare の転送用アドレスと同じ TSIG 鍵を設定する
4. セカンダリ事業者のネームサーバーが正しく応答することを確かめてから、レジストラの NS に追加する

この構成で注意したいのが、Cloudflare 固有の機能です。プロキシ（オレンジの雲）を有効にしたレコードや CNAME フラットニングは、Cloudflare のネームサーバーでは Cloudflare のエッジのアドレスなどに置き換えて応答します。ゾーン転送でセカンダリに渡る値が Cloudflare 自身の応答と同じになるかどうかは設定や機能の組み合わせで変わるため、公式ドキュメントで扱いを確かめ、両方の事業者に同じ問い合わせをして結果を比べてください。

DNSSEC を使う場合も、事業者をまたぐと設計が変わります。各事業者がそれぞれ署名する「マルチサイナー」構成にするのか、署名済みのゾーンを転送するのかで、DS レコードの登録内容が違います。DNSSEC は既存の構成に後から足すより、セカンダリの同期が安定してから段階的に有効にするほうが切り分けやすくなります。

同期できているかを確かめる

最初に見るのは SOA のシリアル番号です。プライマリと Cloudflare（または他社）のネームサーバーに直接問い合わせ、同じ番号が返るかを比べます。

# プライマリ
dig @127.0.0.1 example.com SOA +short

# セカンダリ側（Cloudflare が割り当てたネームサーバー名に置き換える）
dig @xxxx.ns.cloudflare.com example.com SOA +short

# 個別のレコードも比べる
dig @xxxx.ns.cloudflare.com www.example.com A +short

レコードを1件変更してシリアルを上げ、rndc reload のあと数分以内にセカンダリ側の番号が追いつけば、NOTIFY と転送が動いています。追いつかない場合は、BIND のログ（journalctl -u named など）で NOTIFY の送信と転送要求の記録を探します。

転送の許可範囲が正しいかは、鍵なしで要求したときに拒否されるかで確認できます。

# 鍵なし: 拒否されるのが正常
dig @203.0.113.53 example.com AXFR

# 鍵あり: 許可された場所からだけ成功する
dig @203.0.113.53 example.com AXFR -k /etc/bind/cf-xfr.key

鍵なしでゾーンの中身が表示された場合は、allow-transfer が別の場所（options の既定値など）で広く許可されていないかを見直します。

つまずきやすい点

• シリアルを上げ忘れる：手でゾーンファイルを編集してシリアルを変えないと、セカンダリは変更を取りにいきません。日付＋連番（2026101801 など）の形に揃えておくと間違いに気づきやすくなります。
• TCP 53 番が閉じている：問い合わせは UDP で通るのに転送だけ失敗する場合、まず TCP を疑います。
• TSIG の不一致：鍵の名前、アルゴリズム、secret のどれか1つでも違うと認証に失敗します。サーバーの時刻が大きくずれていても TSIG は失敗するため、NTP で時刻を合わせておきます。
• NS の食い違い：レジストラの NS、ゾーン頂点の NS、実際に応答するサーバーの3つを揃えます。切り替え前に TTL を短くしておくと、戻すときの影響も小さくできます。
• 管理する場所が2つになる：受信ゾーン転送の構成では、Cloudflare の画面でレコードを編集する運用にはしません。原本はプライマリだけ、と決めて手順書に書いておきます。

まとめ

• Cloudflare のセカンダリ設定は「Cloudflare が受け取る」か「Cloudflare が送る」かで手順が分かれる。先に向きを決める
• ゾーン転送の機能は主に Enterprise 向け（2026年10月現在）。対象プランと画面の項目は公式ドキュメントで確認する
• 転送は TSIG と IP アドレス制限で守り、TCP 53 番を開ける。鍵は秘密情報として扱う
• SOA シリアルを両方のネームサーバーで比べ、変更が数分で反映されることを確かめてからレジストラの NS を切り替える
• プロキシや CNAME フラットニング、DNSSEC は事業者をまたぐと扱いが変わるため、同期が安定してから個別に確認する

• DNSのSOAレコードの設定方法｜7つのフィールドの意味とBINDゾーンファイルの書き方
• DNSSEC を有効化する手順と注意点｜DSレコードの登録順序と無効化・移転時の落とし穴