Cloudflare DNS でセカンダリ設定する手順｜ゾーン転送を使わずに他社DNSと2系統で運用する方法

Cloudflare のゾーン転送（セカンダリ DNS の機能）を使えない契約でも、Cloudflare と別の DNS 事業者の両方に同じレコードを API で配れば、セカンダリを置いたのと近い冗長構成を作れます。この記事では、ゾーン転送が使えるかの確認から、octoDNS を使った2社への同期、プロキシ（オレンジの雲）やゾーン頂点の CNAME の扱い、レジストラへの NS の登録、同じ答えが返っているかの確かめ方までを説明します。

ゾーン転送で Cloudflare を受け側・送り側にする構成（TSIG を使う一般的なセカンダリ設定）は、同じシリーズの別の記事で扱っています。この記事は「ゾーン転送が使えない場合にどうするか」に絞っています。

まず確認すること：ゾーン転送が使える契約か

Cloudflare の受信・送信のゾーン転送は、主に Enterprise 契約向けの機能として案内されています（2026年10月現在）。無料プランや個人・小規模向けのプランでは、自前の BIND から転送を受けたり、他社のセカンダリへ AXFR で配ったりする設定は基本的にできません。提供範囲は変わることがあるので、着手前に Cloudflare の公式ドキュメントで対象プランを確認してください。

もう一つ確認したいのが、ゾーンの頂点に Cloudflare 以外のネームサーバーを並べてよいかです。Cloudflare の通常の構成（フルセットアップ）は、レジストラに Cloudflare が割り当てたネームサーバーだけを登録する前提で作られています。他社のネームサーバーを併記する使い方は、DNS の設定画面にある「マルチプロバイダー DNS」に当たる設定で扱われます。名称や対象プランは変わることがあるため、画面と公式ドキュメントで確かめてから進めます。

「2社に同じレコードを配る」構成の考え方

ゾーン転送のセカンダリは、プライマリの複製を自動で受け取ります。今回の構成は、Cloudflare と他社（Route 53、NS1、DNSimple など、API でレコードを操作できる事業者）の両方をそれぞれ原本として扱い、手元の設定ファイルから同じ内容を両方に書き込みます。

• 原本は Git で管理する YAML ファイル：レコードの変更はファイルを直して同期ツールを実行する、という流れに一本化します。
• SOA のシリアルはそろわない：2社がそれぞれ自分のシリアルを持つため、ゾーン転送のときのように SOA を比べて同期を判断することはできません。確認はレコード単位で答えを比べます。
• 2社に共通する機能だけを使う：片方にしかない独自のレコードや機能を使うと、問い合わせ先によって答えが変わります。

同期のツールにはいくつか選択肢がありますが、ここでは複数の DNS 事業者に同じゾーンを配る用途で作られた octoDNS を例にします。Terraform で2つのプロバイダーに同じレコードを定義する方法でも、考え方は同じです。

構成する前に決めておくこと

プロキシを使うレコードをどうするか

いちばん影響が大きいのがここです。Cloudflare でプロキシを有効にしたレコードは、Cloudflare のネームサーバーからは Cloudflare のエッジの IP アドレスが返ります。一方、他社のネームサーバーには元のサーバーの IP アドレスを登録することになるため、どちらに問い合わせたかで接続先が変わります。

他社側の答えを使った利用者は、Cloudflare の CDN と WAF を通らずに元のサーバーへ直接つながります。元のサーバーの IP アドレスが公開されることにもなります。そのため、2系統にするレコードはプロキシを使わない「DNS のみ」にそろえるのが基本です。WordPress サイトで Cloudflare のプロキシを使い続けたい場合は、2系統にする対象をメール関連や API 用のサブドメインなどに限る、という分け方も検討します。

ゾーン頂点の CNAME

Cloudflare では、example.com の頂点に CNAME を置くと自動でフラットニング（A レコードへの置き換え）されます。他社側には同じ仕組みがないか、ALIAS や ANAME といった別の名前の独自機能になります。答えのそろえ方が事業者ごとに違うため、頂点は A・AAAA レコードで直接 IP アドレスを書くほうが、2系統の運用では扱いやすくなります。

DNSSEC

2社で DNSSEC を使うには、各社がそれぞれ署名し、相手の鍵も公開し合う「マルチサイナー」の構成が必要になります。対応状況と手順は事業者ごとに異なるため、2系統の運用が安定してから別の作業として検討します。DNSSEC が有効なドメインで NS を追加する場合は、追加先が署名していないと検証に失敗するおそれがあるので、先に DNSSEC の状態を確認してください。

手順1：今のレコードを書き出す

作業の前に、Cloudflare の画面からゾーンファイルを書き出してバックアップを取っておきます。そのうえで、octoDNS と Cloudflare・他社用のプロバイダー（例では Route 53）を入れます。

python3 -m venv ~/octodns && . ~/octodns/bin/activate
pip install octodns octodns-cloudflare octodns-route53

API の認証情報は設定ファイルに書かず、環境変数から渡します。Cloudflare の API トークンは、対象のゾーンの DNS 編集だけを許可した専用のものを作ります。

export CLOUDFLARE_TOKEN='your-api-token'
export AWS_ACCESS_KEY_ID='your-access-key-id'
export AWS_SECRET_ACCESS_KEY='your-secret-access-key'

既存のレコードを YAML に書き出します。

octodns-dump --config-file=config.yaml --output-dir=dump example.com. cloudflare

書き出した YAML は、プロキシの有無が記録されているか、TXT の長い値（DKIM など）が欠けていないかを目で確かめます。プロキシの指定が抜けたまま同期すると、Cloudflare 側でプロキシが外れてしまうおそれがあります。

手順2：octoDNS の設定を書く

# config.yaml
providers:
  config:
    class: octodns.provider.yaml.YamlProvider
    directory: ./zones
  cloudflare:
    class: octodns_cloudflare.CloudflareProvider
    token: env/CLOUDFLARE_TOKEN
  route53:
    class: octodns_route53.Route53Provider
    access_key_id: env/AWS_ACCESS_KEY_ID
    secret_access_key: env/AWS_SECRET_ACCESS_KEY

zones:
  example.com.:
    sources:
      - config
    targets:
      - cloudflare
      - route53

zones/example.com.yaml に、手順1で書き出したレコードを整理して置きます。Route 53 側にはあらかじめ公開ホストゾーンを作っておき、割り当てられた4つのネームサーバー名を控えます。

手順3：差分を確かめてから反映する

octoDNS は、オプションを付けずに実行すると変更内容を表示するだけで、書き込みはしません。

# 何が変わるかを表示する（書き込みはしない）
octodns-sync --config-file=config.yaml

# 内容を確かめてから反映する
octodns-sync --config-file=config.yaml --doit

初回は Route 53 側にレコードがほぼ無いため、追加の行が並ぶのが正常です。Cloudflare 側に「削除」や「更新」が出ていたら、YAML の書き方と実際の設定のずれなので、反映する前に原因を確かめます。一度に多くのレコードを変更・削除しようとすると止まる安全装置もあるので、止まったときは理由を読み、意図した変更か確かめてから進めます。

手順4：両方のネームサーバーで答えを比べる

レジストラに登録する前に、Cloudflare と他社のネームサーバーへ直接問い合わせて、同じ答えが返るかを比べます。

CF=xxxx.ns.cloudflare.com        # Cloudflare が割り当てたネームサーバー
R53=ns-0000.awsdns-00.org        # Route 53 が割り当てたネームサーバー

while read -r name type; do
  a=$(dig @"$CF" "$name" "$type" +norec +short | sort)
  b=$(dig @"$R53" "$name" "$type" +norec +short | sort)
  [ "$a" = "$b" ] && echo "OK   $name $type" || printf 'DIFF %s %s\n  cf : %s\n  r53: %s\n' "$name" "$type" "$a" "$b"
done < names.txt

names.txt には「名前 種類」を1行ずつ書きます（例: example.com MX、_dmarc.example.com TXT）。プロキシを残したレコードは差が出て当然なので、意図どおりかを個別に判断します。

手順5：レジストラに NS を追加する

答えがそろったら、Cloudflare 側でマルチプロバイダー DNS に当たる設定を有効にし、レジストラの NS に他社のネームサーバーを追加します。いきなり全部を並べず、まず他社のネームサーバーを1つだけ足して様子を見る方法もあります。

あわせて、両社のゾーンの頂点にある NS レコードにも、両方の事業者のネームサーバーを並べます。親ゾーン（レジストラに登録した NS）と子ゾーン（各社が返す NS）が食い違うと、リゾルバーによって挙動が変わる原因になります。頂点の NS を編集できるかどうかは事業者ごとに異なるため、各社のドキュメントで確認してください。

追加したあとは、委任が正しく見えているかを確かめます。

dig example.com NS +trace
dig @ns-0000.awsdns-00.org example.com NS +norec

運用で気をつけること

• 画面で直接編集しない：Cloudflare や他社の管理画面で手で変えると、次の同期で上書きされるか、2社の答えがずれます。変更は YAML から行う、と手順書に書いておきます。
• 同期を定期的に実行して差分を見る：書き込みなしの実行を定期的に動かし、差分が出ていないかを監視すると、手作業による変更に早く気づけます。
• 片方を止める訓練をする：本番で試す必要はありません。手順4の比較を応用し、片方のネームサーバーだけに問い合わせてサイトとメールが動くかを確かめておくと、障害時に慌てずに済みます。
• 認証情報を分ける：同期用の API トークンとアクセスキーは、DNS の編集に必要な権限だけに絞り、リポジトリには入れません。

まとめ

• Cloudflare のゾーン転送は主に Enterprise 向け（2026年10月現在）。使えない場合は、2社に同じレコードを API で配る構成でセカンダリに近い冗長性を作れます。
• 原本は Git の YAML に置き、octoDNS などで差分を確かめてから両社に反映します。SOA ではなくレコード単位で答えを比べます。
• プロキシを使うレコードは、問い合わせ先によって接続先が変わります。2系統にするレコードは「DNS のみ」にそろえるのが基本です。
• ゾーン頂点の CNAME と DNSSEC は事業者ごとの差が大きいため、A レコードで書く、DNSSEC は別作業にする、と切り分けます。
• レジストラと両社の頂点 NS をそろえ、運用中は画面で直接編集しないルールを守ります。

• DNSフェイルオーバーでWebサイトを冗長化する構成と設定手順
• DNSSEC を有効化する手順と注意点｜DSレコードの登録順序と無効化・移転時の落とし穴