Cloudflareで独自ドメインを安全に運用するDNS・SSL/TLS・セキュリティ初期設定チェックリスト
Cloudflare Registrar や Cloudflare DNS で独自ドメインを運用し始めた際、初期設定のままサイトを公開してしまうと、「リダイレクトループが発生する」「意図せず暗号化強度が低い通信を許容してしまう」「メールのなりすまし対策が抜けている」といった問題に直面することがあります。
本記事では、独自ドメイン（当サイト egpl.net を含む）を Cloudflare で運用する際に、公開初日に必ず確認・設定しておくべき DNS・SSL/TLS・セキュリティ項目 を実践的なチェックリスト形式で詳しく解説します。
1. SSL/TLS 暗号化モードの落とし穴：「フレキシブル」を避け「フル（厳密）」を選ぶ
Cloudflare ダッシュボードの 「SSL/TLS」＞「概要」 には、4つの暗号化モード（オフ、フレキシブル、フル、フル（厳密））が存在します。新規にゾーンを追加した際の設定確認で最も重要なのがこの項目です。
| 暗号化モード | ブラウザ ⇔ Cloudflare 間 | Cloudflare ⇔ オリジンサーバー間 | 推奨度と注意点 |
|---|---|---|---|
| オフ（安全ではない） | HTTP（平文） | HTTP（平文） | 非推奨：暗号化が一切行われない |
| フレキシブル (Flexible) | HTTPS | HTTP（平文） | 非推奨：オリジン側でHTTPSリダイレクトがあると無限ループが発生 |
| フル (Full) | HTTPS | HTTPS（自己署名証明書を許容） | 検証用途のみ：証明書の有効性検証を行わないため中間者攻撃に弱い |
| フル（厳密）(Full Strict) | HTTPS | HTTPS（有効な証明書またはCloudflareオリジン証明書を検証） | 推奨（標準）：エンドツーエンドで安全な暗号化通信を保証 |
なぜ「フレキシブル」で無限リダイレクトが起きるのか？
オリジンサーバー（Cloudflare Pages、Vercel、または Let’s Encrypt 導入済みの Nginx 等）が「HTTP で来たリクエストを HTTPS にリダイレクトする」設定になっている場合、以下のようなループに陥ります。
- ユーザーが
https://example.comにアクセスする。 - Cloudflare が「フレキシブル」モードのため、オリジンサーバーへ
http://example.com（平文）でリクエストを転送する。 - オリジンサーバーが「HTTP アクセスが来たので
https://example.comへ 301 リダイレクトせよ」と応答する。 - ブラウザが再度
https://example.comへアクセスし、1〜3が無限に繰り返される（ERR_TOO_MANY_REDIRECTS）。
Cloudflare Pages をはじめとするモダンなホスティング環境を使う場合は、最初から必ず 「フル（厳密） / Full (strict)」 を選択してください。
2. エッジ証明書のセキュリティ強化設定
続いて、「SSL/TLS」＞「エッジ証明書」 タブにある重要な4つの設定項目を確認します。
2.1 常に HTTPS を使用（Always Use HTTPS）
- 推奨設定：ON（有効）
- すべての
http://リクエストをエッジ層で即座にhttps://（ステータスコード 301）へリダイレクトします。オリジンサーバー側までリクエストを到達させずにエッジで処理できるため、応答速度の面でも有利です。
2.2 最小 TLS バージョン（Minimum TLS Version）
- 推奨設定：
TLS 1.2（またはTLS 1.3） - 古い暗号スイートを使用する TLS 1.0 / 1.1 はすでに主要ブラウザで廃止されており、脆弱性の温床となります。最小バージョンを
TLS 1.2に引き上げるとともに、すぐ下の項目にある 「TLS 1.3」 トグルを ON にしておくことで、最新ブラウザとの通信においてハンドシェイクの往復回数（RTT）を削減し高速化できます。
2.3 自動 HTTPS リライト（Automatic HTTPS Rewrites）
- 推奨設定：ON（有効）
- ページ内のソースコードに万が一
http://始まりの画像や外部リソースリンクが残っていた場合、混在コンテンツ（Mixed Content）警告を防ぐために可能な範囲で自動的にhttps://へ書き換える機能です。
2.4 HSTS（HTTP Strict Transport Security）の設定と注意点
HSTS を有効にすると、一度サイトを訪れたブラウザに対して「今後は最初から必ず HTTPS で通信すること」を記憶させ、SSL Strip 攻撃（初回HTTP通信へのダウングレード攻撃）を防ぐことができます。
ただし、将来的に HTTP のみのサブドメインを運用する可能性がある場合に includeSubDomains（サブドメインを含める）を有効にすると、そのサブドメインにアクセスできなくなるため、初期段階では以下の設定値から始めるのが安全です。
・Enable HSTS: ON
・Max Age Header (max-age): 6 months (15768000秒) 〜 12 months
・Apply HSTS policy to subdomains (includeSubDomains): サブドメイン構成が確定している場合のみ ON
・No-Sniff Header: ON（X-Content-Type-Options: nosniff を自動付与）3. DNS レコードの信頼性を高める3つの設定（DNSSEC / CAA / メール保護）
Webサイトの表示だけでなく、ドメイン自体のなりすましや不正なSSL証明書発行を防ぐため、「DNS」 メニューで以下の設定を行います。
3.1 DNSSEC の有効化
DNSキャッシュポイズニング（偽のIPアドレス応答を注入する攻撃）を防ぐため、「DNS」＞「設定」 から DNSSEC を有効化します。
- Cloudflare Registrar で取得したドメインの場合：ボタンを1回クリックするだけで、上位レジストリへの DS レコード登録まで全自動で完了します。
- 外部レジストラ（お名前.com、ValueDomain等）で取得したドメインの場合：Cloudflare 画面に表示される DS レコード情報（Key Tag、Algorithm、Digest Type、Digest）をコピーし、ドメイン取得元レジストラの管理画面に貼り付けます。
設定後、dig コマンドで AD（Authenticated Data）フラグが返るかを確認できます。
dig egpl.net +dnssec +short3.2 CAA（Certification Authority Authorization）レコードの登録
CAA レコードは、「このドメインの SSL/TLS 証明書を発行できる認証局（CA）はどこか」を DNS で宣言する仕組みです。Cloudflare ユニバーサル SSL が内部で利用する認証局（Let’s Encrypt、Google Trust Services、SSL.com など）は Cloudflare が自動で CAA レコード相当の管理を行いますが、意図しない認証局からの誤発行を防ぐうえで仕組みを理解しておくことが重要です。
3.3 メールを送信しないドメインでも必須の「Null MX / SPF / DMARC」設定
技術ブログ専用のドメインなど、「そのドメインからメールを一切送信しない」 場合であっても、悪意のある第三者に @egpl.net を騙ったフィッシングメールを送信されないよう、DNS の TXT レコードで「このドメインはメールを送らない」と明示しておくのがベストプラクティスです。
| レコード種別 | 名前 (Name) | 内容 (Content) | 目的 |
|---|---|---|---|
| TXT | @ | "v=spf1 -all" | このドメインからは一切メールを送信しないことを宣言（SPF） |
| TXT | _dmarc | "v=DMARC1; p=reject; sp=reject; adkim=s; aspf=s;" | SPF/DKIM認証に失敗したなりすましメールを受信側で即時拒否（DMARC） |
| TXT | *._domainkey | "v=DKIM1; p=" | すべてのDKIM公開鍵を無効化 |
※将来、Cloudflare Email Routing や Google Workspace 等でメール送受信を行う場合は、それぞれのサービスが指定する SPF・DKIM レコードに書き換えてください。
4. www あり・なしの正規化（Redirect Rules の設定）
SEO において、https://egpl.net（Apex ドメイン / ルートドメイン）と https://www.egpl.net の両方で同じコンテンツが表示される状態は避ける必要があります。当サイトのように www なし（https://egpl.net）を正規URLとする場合は、Cloudflare の 「ルール」＞「Redirect Rules（リダイレクト ルール）」 で一括転送を設定します。
- DNS レコードの確認：
wwwのCNAMEレコード（またはダミーのAAAAレコード100::）を プロキシ有効（オレンジ色の雲マーク） で作成します。 - Redirect Rule の作成：
- 条件（カスタムフィルタ式）：
(http.host eq "www.egpl.net") - リダイレクト種別：Dynamic（動的）
- 式（Expression）：
concat("https://egpl.net", http.request.uri.path) - ステータスコード：
301（恒久的リダイレクト） - クエリ文字列の保持：チェックを入れる
- 条件（カスタムフィルタ式）：
これにより、https://www.egpl.net/blog/sample/ にアクセスされた際も、パスとクエリパラメータを維持したまま https://egpl.net/blog/sample/ へエッジ層で高速に 301 リダイレクトされます。
まとめ：初期設定チェックリスト
最後に、本記事で解説した Cloudflare ドメイン初期設定の要点をまとめます。
- SSL/TLS 暗号化モードを 「フル（厳密）」 に設定したか
- 「常に HTTPS を使用」 と 「TLS 1.3」 を有効にし、最小 TLS バージョンを 1.2 にしたか
- DNSSEC を有効化し、名前解決の改ざん防止を有効にしたか
- メール未使用ドメインの場合、なりすまし防止用の SPF (
v=spf1 -all) / DMARC レコードを設定したか -
wwwあり・なしの 301 リダイレクト正規化 を行い、正規URLを統一したか
これらを公開初日に整えておくことで、セキュリティ診断サイト（SSL Labs や Security Headers 等）でも高評価を得られ、検索エンジンや広告審査クローラーにとっても信頼性の高いサイト基盤となります。