CloudflareへのDNS切替手順｜NS更新・DNSSEC・SSL/TLS・切り戻しまで解説
Cloudflareを既存サイトへ導入するとき、最も影響が大きい作業が権威DNSの移行です。Webページが表示されても、MXやDKIM、外部SaaSの検証レコードが欠けていれば、メールや業務連携だけが止まることがあります。
安全な移行では、Cloudflareへドメインを追加して終わりにせず、現行ゾーンの棚卸し、NS切替、DNSSEC、プロキシ対象、SSL/TLS、監視、ロールバックを一つの変更計画として管理します。
CloudflareへのDNS移行は、現行レコードを完全に複製し、必要に応じて旧DNSSECを解除してからNSを変更し、Web・メール・APIを検証した後にCloudflare側でDNSSECを再設定する手順が基本です。
本記事のポイント
- 移行前にWebだけでなくメール・外部SaaS・検証用TXTを含む全DNSレコードを照合します。
- DNSSECは旧事業者のDSレコードを残したまま切り替えず、無効化・NS移行・再有効化の順序を設計します。
- NS切替後は名前解決だけでなく、HTTPS、メール、フォーム、Webhook、管理画面まで確認してから旧DNSを廃止します。
この記事で分かること
| 確認対象 | 見る内容 | 判断のポイント |
|---|---|---|
| 事前準備 | 現行ゾーン、TTL、DNSSEC、管理権限、重要URLを記録 | 移行漏れと切り戻し不能を防ぐ |
| Cloudflare登録 | 自動検出されたレコードを現行DNSと照合 | MX・TXT・特殊レコードの欠落を防ぐ |
| NS切替 | レジストラでCloudflare指定NSへ変更 | 権威DNSをCloudflareへ移す |
| 公開設定 | Proxy status、Full (strict)、キャッシュを段階適用 | 経路変更と機能追加を分離する |
| 確認・復旧 | 複数ネットワークからDNS・HTTPS・メールを確認 | 伝播差と個別障害を切り分ける |
移行前にDNSゾーンと管理権限を棚卸しする
最初に、A、AAAA、CNAME、MX、TXT、CAA、SRV、DKIM、DMARC、ドメイン所有確認など、現行の全レコードをエクスポートまたは記録します。サブドメインごとに、Web公開、メール、ファイル転送、VPN、外部SaaS、検証環境の用途も紐付けます。
レジストラ、現行DNS、オリジンサーバーの管理権限が同じ担当者にあるとは限りません。切替時刻、承認者、作業者、連絡先、旧設定の保管場所を明確にし、担当者不在で戻せない状態を避けます。ドメイン自体の更新管理は、企業ドメインの更新期限を見逃さない管理方法も参考になります。
DNSSECを有効にしている場合の順序を決める
DNSSECでは、レジストラ側に登録されたDSレコードと権威DNS側の署名が一致しないと検証に失敗します。旧DNS事業者の署名を前提とするDSレコードを残したままNSだけを変えると、利用者からはドメインが存在しないように見える場合があります。
一般には旧事業者側のDNSSECとレジストラのDS状態を確認し、必要な待機を入れてからNSを変更し、Cloudflare側でDNSSECを有効化して新しいDSレコードをレジストラへ登録します。レジストラやTLDの仕様で手順が異なるため、Cloudflare公式とレジストラ公式の両方を作業票に残します。
Cloudflareへレコードを登録しProxy statusを分ける
Cloudflareの自動スキャンは移行の出発点として便利ですが、完全性を保証するものではありません。現行DNSの記録と件数・値・優先度・TTLを比較し、特にメールと外部SaaSのTXTレコードを目視確認します。
Web公開用のA・AAAA・CNAMEは要件を確認してプロキシ済みにできます。一方、MX、メール送信用ホスト、所有確認、HTTP以外の独自プロトコルはDNSのみで扱うことが多く、雲アイコンを一括で有効化しません。
SSL/TLSはFull (strict)へ寄せる
Cloudflareとオリジンの間も暗号化・認証するため、オリジンサーバーへ有効な証明書を設定し、可能な限りFull (strict)を選びます。FlexibleはオリジンまでHTTPになるため、ログインやフォームを含む企業サイトの標準構成には向きません。
切替前に、証明書の対象ホスト名、有効期限、チェーン、443番ポート、HTTPからHTTPSへのリダイレクトを確認します。Cloudflare側とオリジン側の両方で強制リダイレクトするとループする場合があるため、責任箇所を一つに寄せます。
NS切替後の確認とロールバック条件
NS変更後は、複数のパブリックDNS、社内ネットワーク、モバイル回線から応答を確認します。トップページだけでなく、問い合わせ、ログイン、画像、ダウンロード、Webhook、メール送受信、管理画面もテストします。
ロールバックは『表示できないとき』だけでなく、重要メールの不達、証明書エラー、主要API停止など、事前に決めた条件で判断します。旧DNSゾーンをすぐ削除せず、安定確認期間を置くと戻しやすくなります。
本番導入で必要な変更管理と評価方法
Cloudflareの設定は通信経路の手前で効くため、小さな変更でも複数ページや外部連携へ影響します。開発・検証環境で再現できるものは先に試し、本番では対象ホスト、パス、利用者、時間帯を限定して段階反映します。変更票には目的、変更前後、実施者、承認者、確認URL、期待結果、切り戻し条件を残します。
確認は「画面が開くか」だけで終えません。HTTPステータス、レスポンスヘッダー、認証、フォームやAPIの完了、オリジンログ、Cloudflareイベントを同じ時刻で照合します。正常系だけでなく、権限なし、期限切れ、過剰アクセス、外部API停止、再送などの異常系も試し、利用者へ返すエラーと運用担当者が見る証拠を分けます。
導入効果は、表示速度やブロック件数など一つの数値だけで評価しません。可用性、正常完了率、オリジン負荷、エラー率、誤検知、サポート問い合わせ、変更作業時間、月額・従量費を導入前後で比較します。性能が上がっても問い合わせやログインの失敗が増えていれば、事業成果としては改善していません。
料金と上限は利用プランや使用量で変わります。無料枠や小規模検証の結果をそのまま本番へ外挿せず、ピーク時のリクエスト、保存・操作、ログ量、利用者数、サポート、監査要件を公式料金ページと契約条件で確認します。上限へ近づいたときの通知と、機能を縮退させる順序も決めます。
設定の所有者と定期レビュー日を決め、不要なルール、トークン、例外、接続先を残しません。Cloudflare画面だけでなく、設定のエクスポート、コード、変更履歴、復旧手順をチームで参照できる場所へ保管します。担当者の退職や委託先変更があっても、誰が承認し、どこまで戻せるか分かる状態を維持します。
公開後は一週間程度の観測期間を設け、導入前と同じ時間帯・同じURL・同じ業務操作で比較します。異常がなくても、例外が増え続けていないか、想定外の回避策が現場で使われていないかを確認します。問題が見つかった場合は、影響を受けた利用者とデータを特定し、暫定回避と恒久修正を分けて記録します。
また、Cloudflare以外の構成要素を含む依存関係図を残します。DNS、レジストラ、オリジン、IdP、メール、外部API、監視、CI/CDのどこで設定が重複し、どこが単一障害点になるかを明示します。障害時に別サービスの担当者へ連絡すべき条件も決めておくと、Cloudflare側だけを調べ続ける時間を減らせます。
本番の設定変更は、可能ならAPIやInfrastructure as Codeで再現可能にし、画面で行った緊急変更も後から正本へ戻します。秘密情報は設定ファイルへ直接書かず、環境ごとのSecret管理へ分離します。手作業とコードの状態がずれると、次回デプロイで緊急修正が消えるため、復旧後の同期までをインシデント対応に含めます。
公開・変更前チェックリスト
- 現行DNSの全レコードと用途を保存した
- レジストラ・DNS・オリジンの管理権限を確認した
- DNSSECの解除・再設定順序を確認した
- Web用とDNSのみのレコードを分けた
- Full (strict)でオリジン証明書を検証した
- Web・メール・API・フォームの確認項目を用意した
- 旧DNSを保持する期間とロールバック条件を決めた
よくある質問
Cloudflareへ移行するとDNSレコードのIPは変わりますか？
DNSのみのレコードは登録した値を返します。プロキシ済みのWeb用レコードはCloudflareのAnycast IPが応答し、実際のオリジンIPはCloudflareの背後に置かれます。
TTLは事前に下げるべきですか？
旧DNSの応答を早く切り替えたい場合は有効ですが、NS委任のキャッシュとゾーン内レコードのTTLは別です。変更対象と反映タイミングを分けて考えます。
メール用レコードもプロキシ済みにしますか？
通常、MXやメール送信ホストなどHTTP/HTTPS以外の通信はDNSのみで扱います。利用中サービスの公式要件を確認してください。
Cloudflareの自動スキャンだけで移行できますか？
不足するレコードがあり得るため、現行DNSとの完全照合が必要です。特にTXT、CAA、SRV、DKIM、外部SaaSの検証レコードを確認します。
関連ページと関連記事
仕様確認に使った公式情報
Cloudflareの機能、プラン、上限、画面構成は更新されます。実装時は利用する機能の最新公式ドキュメントも確認してください。
まとめ
CloudflareへのDNS移行を、事前棚卸し、ゾーン登録、NS切替、DNSSEC、SSL/TLS、検証、切り戻しの順で進める実務ガイドです。 設定を有効にしただけで完了とせず、正常系・異常系・切り戻しを同じ手順で確認することが、安全な運用につながります。
