Skip to content

非公式本サイトは非公式の日本語ドキュメントであり、Cloudflare 公式サイトではありません。最新情報はdevelopers.cloudflare.comをご確認ください。

フェーズ 1: 計画とインベントリ

最終更新 Markdown で表示Agent セットアップ

詳細な計画は、DNS 移行を成功させる土台です。

1. 現在の BIND 構成を把握する

  1. BIND サーバーでホストしているすべての DNS ゾーンを特定します。

  2. 各ゾーン内のすべての DNS レコードを確認します。古いレコードや不要なレコードを削除し、既存レコードの正確性を検証します。

  3. BIND views（スプリット DNS）: 内部リゾルバーと外部リゾルバーに異なる DNS 応答を返す BIND views を使っている場合、Cloudflare の権威 DNS はクライアントごとのビューをそのまま再現しません。

    • 内部専用の名前は内部 DNS リゾルバー（BIND、Active Directory、その他の内部リゾルバーなど）を使い続け、公開ゾーンには Cloudflare 権威 DNS を使います。
    • ポリシーベースの内部 DNS には、DNS ポリシーや Internal DNS などの Cloudflare Zero Trust 機能を検討してください。詳細は Cloudflare DNS と Internal DNS を参照してください。

  4. BIND ACL（アクセス制御リスト）: 権威 DNS への問い合わせやゾーン転送を行えるクライアントを ACL で制限している場合、これらの制御がどう変わるかを計画します。

    • 権威 DNS の問い合わせ: Cloudflare 権威 DNS のネームサーバーはパブリックインターネットから到達でき、標準の DNS 問い合わせに対するリゾルバー単位の ACL はサポートしません。

    • HTTP とアプリケーションアクセス: アプリケーションへの HTTP(S) トラフィックを制限またはフィルタリングするには、Web Application Firewall (WAF) などの Cloudflare セキュリティ機能や、その他の Application Security 製品を使います。これらは DNS 問い合わせ層ではなく、HTTP 層で動作します。

    • ゾーン転送（AXFR/IXFR）: いま BIND で AXFR/IXFR を使っている場合、Cloudflare のゾーン転送構成を確認してください。

      これらの構成では、ゾーン転送を実行できる IP アドレスの制限方法が説明されています。

  5. 依存関係: BIND 構成の特定の DNS 動作に強く依存しているアプリケーションやサービスを特定します。

2. 範囲と目標を定義する

移行するすべてのドメイン名を明確に列挙し、移行の成功基準を定義します。

3. Cloudflare アカウントの作成と操作の習熟

  1. まだの場合は Cloudflare アカウントを作成 します。
  2. Cloudflare DNS ダッシュボードと機能に慣れます。
  3. Cloudflare で管理できる DNS レコードタイプ と、BIND からの対応関係を確認します。

4. DNSSEC 戦略（重要）

各ゾーンで、BIND 上とドメインレジストラ上の DNSSEC が有効かどうかを確認します。

DNSSEC が有効な場合、Cloudflare は主に次の 2 つの移行方法をサポートします。

  • オプション 1（ほとんどの移行に推奨）: ネームサーバーを変更する前に、レジストラで DNSSEC を無効化 します。Cloudflare への移行が完了し安定したら、Cloudflare ダッシュボードから DNSSEC を再有効化します。
  • オプション 2（上級）: multi-signer DNSSEC を使ったアクティブ移行を行います。移行中は両方のプロバイダーがゾーンに署名します。キー管理に注意が必要ですが、DNSSEC を無効にせず移行できます。詳細は DNSSEC が有効な既存ゾーンを移行する を参照してください。

無効化して再有効化する方法（多くのチームにとってより安全）:

  1. レジストラにログインし、各ドメインについて、オンプレミス BIND の DNSSEC キーに関連する DS レコードを削除します。
  2. リゾルバーが古い DNSSEC チェーンを期待しなくなってから、ネームサーバーを切り替えます。

*DS レコードの TTL: DNSSEC が有効な場合、親ゾーン（レジストラが管理）の DS レコードの Time To Live（TTL）を確認します。この値によって、DS レコード削除後の待ち時間が決まります。目安として、ネームサーバーを変更する前に、少なくとも DS TTL の 1 倍、できれば 1.5 倍待ちます。

Cloudflare 上の DNSSEC の詳細は DNSSEC を参照してください。

5. 移行ウィンドウを選ぶ

影響を抑えるため、トラフィックと業務が少ない時間帯を選び、関係者に予定ウィンドウを伝えます。

6. コミュニケーションとロールバック計画を作る

  • コミュニケーション: 移行の前、最中、後に関係者とどう連絡するかを計画します。
  • ロールバック計画: 重大な問題が起きたときに BIND サーバーへ戻す手順を文書化します。主に、レジストラでネームサーバーを戻し、DNSSEC を使っていた場合は古い DS レコードを再追加します。

役に立ちましたか？