フェーズ 2: 準備

丁寧に準備すると、切り替え時のダウンタイムとトラブルを減らせます。

計画した移行時間の少なくとも 24〜48 時間前（できれば、現在の最長 TTL と同じかそれ以上前）に、BIND ゾーンファイル内の重要なレコードすべての TTL を下げます。移行時によく使う短い TTL は 300 秒（5 分）です。

こうすると、世界中の DNS リゾルバーが古いレコードをキャッシュする時間が短くなり、Cloudflare へ切り替えたあとの変更がより早く伝播します。

• SOA レコード: SOA レコードの MINIMUM フィールドも下げることを検討してください。この値は、否定応答に使う TTL を決めます（RFC 2308 ↗）。

BIND サーバーから、標準の BIND 形式でゾーンファイルの最新かつきれいなエクスポートを取得し、内容が完全で正確であることを確認します。

1. Cloudflare ダッシュボードにログインします。

   Account home を開く ↗

2. 移行する各ドメインを追加します。Cloudflare は既存の DNS レコードのスキャンを試みます。

Cloudflare の Import and Export 機能（DNS > Records）を使い、BIND ゾーンファイルをアップロードします。

• 検証（重要）:
  • インポート後、Cloudflare 上のレコードを BIND ゾーンファイル、または現在のゾーンの dig 出力と丁寧に突き合わせます。
  • MX レコード、SRV レコード、TXT レコード（特に SPF、DKIM、DMARC）、複雑な CNAME 設定に注意します。
  • FQDN（完全修飾ドメイン名）の形式が正しいことを確認します（インポート時、末尾のドットは Cloudflare が通常正しく処理しますが、必ず確認してください）。
• プロキシステータス（オレンジクラウドとグレイクラウド）:
  • HTTP または HTTPS サービス（ウェブサイトや API など）を Cloudflare 経由でプロキシしたい A、AAAA、CNAME レコードでは、オレンジクラウドを有効にすると Cloudflare CDN とセキュリティ機能を使えます。
  • プロキシの背後では一部のサービスとポートはサポートされません。一部のレコード種別（たとえば MX のターゲットや、多くの非 HTTP サービス）は DNS only のままにする必要があります。詳細は プロキシステータスと制限 を参照してください。
  • 初回移行時の推奨: DNS 移行とプロキシ関連の問題を切り分けるため、最初はすべてのレコードを DNS only（グレイクラウド）にすることを検討してください。DNS 解決が正しく動くことを確認したあと、特定の HTTP(S) レコードでプロキシ（オレンジクラウド）を有効にし、再度テストします。

レジストラでネームサーバーを変更する前に、この手順を完了します。

• レジストラでの作業: ドメインレジストラにログインし、各ドメインのオンプレミス BIND DNSSEC キーに関連する既存の DS レコードを削除します。
• DS TTL を待つ: 親ゾーンに公開されている DS レコードの TTL の全期間、できればその 1.5 倍まで待ってから、ネームサーバーを変更します。こうすると、検証するリゾルバーは古い DNSSEC チェーンを期待しなくなります。DS レコードの TTL は、通常 +24 時間（86,400 秒）です。
• タイミングを誤った場合の影響: リゾルバーがまだ古い DS レコードを期待している状態でネームサーバーを変更すると、DNSSEC 検証が失敗し、検証するリゾルバーからドメインに到達できなくなることがあります。