CloudflareはなぜDNS変更が必要？CDNとDNSの関係を理解する
「CloudflareはCDNなのに、導入するにはDNS変更が必要と言われた」
「CDNとDNS、どういう関係があるの？」
「DNS変更って難しそうだし、間違ってサーバダウンしないか心配」
Cloudflareの導入を検討している方から、こんな声を聞きます。
確かに、CDNを使うのに、なぜDNSを変更する必要があるのか、分かりにくいですよね。
今回は、この「CDNとDNSの関係」を解説します。
CloudflareはCDNであり、DNSでもある
これまでの記事でお伝えしてきた通り、CloudflareはCDNです。
しかしCDNとして機能するにはCloudflareDNSを使います
ここで重要なポイントです：
CloudflareのCDN機能を使うには、通常、DNSをCloudflareに変更します
なぜでしょうか？
それは、インターネット上のすべてのアクセスは「DNS」から始まるからです。
もう少し詳しく説明しましょう。
あなたがWebサイトにアクセスする時、
普段は目に見えない流れですが実はこんな流れになっています：
- ブラウザに「example.com」と入力
↓ - 【まずDNSに聞く】「example.comはどこにあるの？」
↓ - DNSが答える「○○○のIPアドレスに行ってください」
↓ - ブラウザがそのIPアドレスにアクセス ```
この「DNS」がインターネットアクセスが最初にあるのです。
DNS変更後で何が変わるのか
DNS変更前（従来）
訪問者「example.comに行きたい」
↓
DNS「あなたのサーバー（192.0.XXX.XXX）に行ってください」
↓
訪問者はあなたのサーバーへ直接アクセス
↓
結果：CDN機能もWAFも働かない
DNS変更後（Cloudflare導入）
訪問者「example.comに行きたい」
↓
Cloudflare DNS「Cloudflareのサーバー（104.16.XXX.XXX）に行ってください」
↓
訪問者はまずCloudflareへアクセス
↓
Cloudflareが処理（キャッシュ配信、WAF検査、DDoS対策）
↓
必要な時だけ、あなたのサーバーへアクセス
↓
結果：すべてのトラフィックがCloudflare経由 → 全機能が働く！
つまり：DNS変更 = リクエストの入口をCloudflareに変える
DNS変更をすることで：
- すべての訪問者が必ずCloudflare経由になる
- Cloudflareが「門番」として機能できる
- だからCDN、WAF、DDoS対策などすべての機能が働く
逆に言えば、DNS変更をしないと、訪問者はウェブサーバーに直接アクセスしてしまうため、Cloudflareの機能が使えません。
これが、CDNなのにDNSを変更する理由です。
それでは、なぜCDNなのにDNS変更が必要なのか、詳しく見ていきましょう。
なぜCDNなのにDNS変更が必要なのか？
「入口（DNS）」と「中継地点（CDN）」の関係
いっぽう、CDNの基本的な仕組みはこのようになっています。
あなたのWebサイトを東京の本社、世界中のユーザーを世界中の顧客に例えてみましょう。
従来の仕組み（CDNなし）
ニューヨークの顧客 → 直接東京の本社へアクセス → 遠いから遅い
ロンドンの顧客 → 直接東京の本社へアクセス → 遠いから遅い
シドニーの顧客 → 直接東京の本社へアクセス → 遠いから遅い
CDNの仕組み（Cloudflare導入後）
ニューヨークの顧客 → 最寄りのCloudflare営業所（ニューヨーク） → 速い！
ロンドンの顧客 → 最寄りのCloudflare営業所（ロンドン） → 速い！
シドニーの顧客 → 最寄りのCloudflare営業所（シドニー） → 速い！
営業所（CDN）は：
- よくある質問はその場で回答（キャッシュ配信）
- 必要な時だけ本社に問い合わせ（オリジンサーバーへアクセス）
- 怪しい訪問者は入口でブロック（WAF、DDoS対策）
つまり、DNSはCloudflareのすべての機能を動かすための「入口」なのです。
2つの設定方法がある
ここまで、CloudflareがDNSである話をしましたが
Cloudflareの導入方法には、2つの選択肢があります：
- フルセットアップ（推奨）：DNSを完全にCloudflareに移管→全機能が使える
- パーシャルセットアップ：既存DNSを維持→一部機能のみCloudflareに委任
フルセットアップ（完全移管）：推奨される方法
フルセットアップとは
フルセットアップは、DNSレコードをすべてCloudflareに移管する方法です。
これが最も一般的で、Cloudflareが推奨する方法です。
CloudflareがDNSとCDNの両方を担う
フルセットアップでは、Cloudflareが2つの役割を同時に担います：
役割1：DNS
- ドメインの住所案内係
- example.com → CloudflareのIPアドレスを返答
役割2：CDN・セキュリティ
- トラフィックをキャッシュ、保護、配信
- WAF、DDoS対策、SSL/TLSなどすべての機能が使える
メリット
フルセットアップの大きなメリット：
- すべてのCloudflare機能が使える（CDN、WAF、DDoS対策、SSL/TLSなど）
- 設定がシンプルでわかりやすい
- Cloudflare管理画面で一元管理できる
- 無料プランでもDNSとCDNの両方が使える
- 自動でDNSレコードがインポートされるので移行が簡単
デメリット
フルセットアップのデメリットも理解しておきましょう：
ネームサーバー変更の権限が必要
- ドメインのレジストラにアクセスできる必要がある
- 会社のドメインの場合、IT部門の承認が必要な場合も
既存DNSから移行する手間
- とはいえ、自動インポートがあるので実際は簡単
一時的な不安感
- DNS変更には心理的なハードルがある
- でも、正しく設定すれば問題なく移行できます
パーシャルセットアップ（部分的導入）：制約がある場合の選択肢
パーシャルセットアップとは
パーシャルセットアップは、既存のDNSをそのまま使いながら、一部のレコードだけCloudflare経由にする方法です。
DNSとCDNの分離
パーシャルセットアップでは、DNSとCDNが分離されます：
DNS：既存のまま（Route53、お名前.comなど）
↓
一部のレコード（例：www.example.com）だけCloudflareを指定
↓
CDN・セキュリティ：Cloudflare
具体的には、CNAMEレコードを使ってCloudflareに接続します。
どんな場面で使う？
パーシャルセットアップが適している場面：
DNSを変更できない
- 会社の方針でDNSが固定されている
- 他のシステムとの兼ね合いでDNS変更が難しい
一部のサービスだけCloudflareで保護したい
- 例：`www.example.com`だけCDN経由にしたい
- 他のサブドメインは既存のまま使いたい
段階的に移行したい
- まずテストとして一部だけCloudflare経由にする
- 問題なければ徐々に拡大していく
メリット
パーシャルセットアップのメリット：
既存DNS設定を維持できる
- DNSを変更しなくてよい
- 既存システムへの影響を最小限に
リスクを抑えた段階的導入
- いきなり全体を変更するのが不安な場合
- 一部だけテスト導入できる
特定サービスだけCDN経由にできる
- 例：メインサイト（www）だけCloudflare経由
- 管理画面などは既存のまま
デメリット・制限事項
パーシャルセットアップには、いくつかの制約があります：
1. 使える機能が限られる
- 一部のWAF機能が制限される
- 高度なセキュリティ機能の一部が使えない
2. 設定がやや複雑
- CNAMEレコードの設定が必要
- SSL/TLS証明書の設定も追加で必要
3. ルートドメインでは使えない
- `www.example.com` → ○ 可能
- `example.com`（ルートドメイン） → × 不可
- これは技術的な制約（CNAMEの仕様）
4. 管理が煩雑になる
- DNSは既存プロバイダー、CDNはCloudflare
- 2つの管理画面を使い分ける必要がある
設定はフルセットアップよりやや複雑ですが、既存システムへの影響は最小限に抑えられます。
フルセットアップを推奨する理由
基本的には、フルセットアップを強くおすすめします。
理由：
- DNSとCDNの両方をCloudflareが担当するので、すべての機能が使える
- 設定がシンプルで、Cloudflareの管理画面だけで完結
- Cloudflareの強みを最大限活用できる
- 自動インポート機能で移行が簡単
パーシャルセットアップが適しているケース
以下のような場合は、パーシャルセットアップも選択肢になります：
1. 組織的な制約がある
- 会社のIT部門がDNSを固定している
- セキュリティポリシーでDNS変更が承認されない
2. テスト導入として
- まずは一部だけ試してみたい
- 社内で効果を実証してから全体に展開したい
3. 特定のサブドメインだけ保護したい
- メインサイト（www）だけCDN経由にしたい
- 他のサービスは既存のまま維持したい
注意事項
- DNS変更前には、既存のDNSレコードのバックアップを取ることを推奨します
- TTL（Time To Live）の値を事前に短くしておくと、変更時の影響を最小化できます