Cloudflareのネームサーバー変更・DNS移行手順と停止リスクを抑えるポイント

Cloudflareのネームサーバー変更では、Webサイトだけでなく、メールや外部サービスに必要な設定も引き継ぎます。停止リスクを抑えるには、現在のDNS情報を把握し、切り替え前後に確認する項目を決めておくことが大切です。

ここでは、現在のDNSからCloudflareへ管理先を移す一般的なフルセットアップを前提に、事前準備から動作確認までの手順を解説します。

Business／Enterpriseでは、現在のDNS事業者を維持してCloudflareを利用するCNAME setup（Partial）も選べます。ここで紹介するのはDNSの管理先を移す方法なので、ネームサーバーを変更できない場合は、別の方式を使えるか確認します。

Cloudflareのネームサーバー変更で何が変わるのか

DNSの管理先が変わり、サイトやメールの接続先を引き継ぐ

ネームサーバーは、ドメインに対応するWebサイトやメールの接続先を案内するDNS情報を管理します。Cloudflareへの切り替えでは、この情報の管理先を変更します。ドメインの取得先やWebサーバー、メールサービスまで移転する手続きではありません。

ただし、新しい管理先に必要なDNSレコードがなければ、接続先を正しく案内できなくなります。Webサイトが表示できても、メールや一部のサブドメインだけ使えないことがあるため、利用中のサービス全体を確認する必要があります。

DNS移行とWeb通信のプロキシ化を分けて考える

Cloudflareの「DNSのみ」は接続先の情報を返す設定で、「プロキシ済み」はWeb通信をCloudflare経由にする設定です。DNSの管理先を移しただけでは、DNSのみのホストにCloudflareのWAFやCDNキャッシュは適用されません。

現在の接続先へ直接アクセスできる構成では、まずDNSのみで移行し、証明書やサーバー側の準備を整えてからWeb用レコードをプロキシ済みにする進め方があります。DNS移行と通信経路の変更を段階的に行うと、問題が起きた箇所を確認しやすくなります。

CloudflareへDNSを移行する手順

1. 現在のDNSレコードと管理権限を確認する

ドメイン管理会社とDNS事業者、サーバーやメールの管理者を確認し、各管理画面へアクセスできる状態を整えます。DNSレコードは管理画面の一覧やエクスポート機能から控え、名前、種類、値、優先度、TTLなどを記録します。

TTLはDNS情報を一時保存する期間です。切り替え後も古い情報が参照される可能性を考慮し、旧DNSの提供期間と設定を維持できるか確かめます。作業日時、承認者、連絡先、問題発生時に元の構成へ戻す条件も事前に決めておきましょう。

2. Cloudflareへドメインを追加し、DNSレコードを照合する

Cloudflareのアカウントへ対象ドメインを追加し、プランを選択します。DNSレコードの自動検出結果を既存の一覧と照合し、不足や誤りを修正します。自動検出ですべてのレコードが取り込まれるとは限りません。

Web用のA・AAAA・CNAMEに加え、メール配送先のMX、送信元認証に使うSPF・DKIM・DMARC、外部サービスの認証レコードも確認します。SMTPなどのメール通信に使うホストはDNSのみとし、準備中に旧DNSへ追加した設定も反映してください。

3. DNSSECの状態を確認し、ネームサーバーを変更する

DNSSECは、DNS情報の改ざんを検知する仕組みです。利用中の場合、ここで紹介する一般的な移行手順では、ドメイン管理会社側でDNSSECを無効化します。旧DNSの署名を検証するためのDSレコードが残らないよう、削除の反映も確認します。

その後、ドメイン管理会社のネームサーバー設定を、対象ドメインに割り当てられたCloudflareの指定値へ置き換えます。変更先はDNSレコード一覧ではなく、ネームサーバーを指定する画面です。旧・新の値を混在させず、入力内容を照合して保存します。

4. 切り替え状況とサイト・メールの動作を確認する

Cloudflareのドメイン状態が「Active」になったことに加え、DNS確認ツールなどでネームサーバーと主要レコードの応答を調べます。トップページの表示、外部アドレスとのメール送受信、サブドメイン、連携サービスの動作も確認します。

有効化されても、すべての利用環境で同時に切り替わるとは限りません。旧DNSをすぐに削除・解約せず、参照状況を確認します。DNSSECを無効化した場合は、移行後にCloudflareで有効化し、新しいDS情報をドメイン管理会社へ登録して検証します。

5. 証明書と接続設定を確認してプロキシを有効にする

Web通信をCloudflare経由にする前に、対象ホストをカバーするCloudflare側の証明書が有効か確認します。配信元サーバーの証明書とSSL/TLS暗号化モードの整合性、CloudflareのIPアドレスからの接続を許可できているかも点検します。

Full（strict）を使う場合、配信元でHTTPS接続を受け、期限内で対象ホスト名に一致する証明書を提示する必要があります。接続エラーを解消するためだけに暗号化や証明書検証を弱めず、証明書と接続許可を調べて修正します。

準備が整ったら、対象のWeb用レコードをプロキシ済みに変更します。HTTPS表示、ログイン、フォーム送信、決済、APIなどを再度テストし、WAFやキャッシュの影響も確かめます。メール用ホストやサービス認証用レコードは、用途に応じてDNSのみを維持します。

DNS切り替え前後のチェックリスト

作業担当者と確認担当者で、次の項目を共有しておくと、設定の引き継ぎや動作確認の抜け漏れを減らせます。

切り戻しとは、問題が起きた際に元の構成へ戻す対応です。元のネームサーバーに戻しても、即座に復旧するとは限りません。DNSのキャッシュやDNSSECの状態も影響するため、戻す設定と確認手順を作業前に整理しておく必要があります。

ドメインが有効にならない場合は、ドメイン登録先に保存したネームサーバーの値や、Cloudflare側の表示状態を確認します。反映待ちなのか、設定が誤っているのかを分けて調べることが大切です。

ネームサーバー変更を導入支援会社へ依頼する際の確認点

社内でDNS情報を把握できない場合や、サイトとメールの管理会社が分かれている場合は、導入支援会社への相談も選択肢になります。ネームサーバー変更だけを依頼できるかに加え、事前調査から切り替え後の検証・障害対応まで、どの作業が支援範囲に含まれるかを確かめることが重要です。

DNSSECやメール設定への対応、夜間・休日の作業可否、切り戻し時の追加費用も比較材料になります。自社と支援会社、既存の管理会社が担当する作業を決め、完了後はDNSレコード一覧と変更履歴、管理権限を自社で把握できる状態にしておくと、日々の運用へ引き継ぎやすくなります。

DNS移行の経験や関係会社との連携体制も、委託先を選ぶ際の判断材料になります。導入支援の見積もりには、切り替え操作だけでなく、事前調査・メールの検証・問題発生時の対応まで含めてもらいましょう。