CDNを導入すると「cdn-provider.example.net にCNAMEを向けてください」と案内されますが、example.com のようなルートドメイン（ゾーンの頂点、apex）にはCNAMEを置けません。この問題の解決策が、DNSサービス側で行うCNAMEフラット化（CNAME flattening）や ALIAS / ANAME レコードです。この記事では、なぜルートにCNAMEを置けないのか、解決策の選び方、設定後の確認方法、WordPress側で合わせて見直す点を説明します。
なぜルートドメインにCNAMEを置けないのか
CNAMEは「この名前は別の名前の別名です」と宣言するレコードで、DNSの仕様上、同じ名前にほかのレコードと共存できません。ところがルートドメインには、ゾーンを成立させるためのSOAレコードとNSレコードが常に存在し、多くの場合はMX（メール）やTXT（SPF、ドメイン所有確認）も置かれています。そのため example.com にCNAMEを書くことは規格上許されません。
一部の管理画面では入力できてしまうことがありますが、そうした設定はリゾルバーによって解釈が分かれ、メールが届かない、TXTによる所有確認が通らないといった問題の原因になります。
一方、www.example.com や cdn.example.com のようなサブドメインには通常ほかのレコードがないため、CNAMEをそのまま設定できます。
解決策は4つ
ルートドメインでCDNを使いたいときの選択肢は、おおむね次の4つです。
| 方法 | 仕組み | 向いている場面 |
|---|---|---|
| CNAMEフラット化 | DNSサービスがCNAMEの先を解決し、結果のIPアドレスをAレコードとして返す | Cloudflare をDNSに使っている |
| ALIAS / ANAME | フラット化と同じ考え方を独自のレコード型として提供 | DNSimple、DNS Made Easy、NS1 など対応サービスを使っている |
| Route 53 のエイリアスレコード | AWSのリソース（CloudFront、ロードバランサー等）を指す特殊なレコード | AWSのCDNやロードバランサーを使っている |
| wwwを正規URLにする | ルートは www へ301リダイレクトし、www にCNAMEを設定 | DNSサービスを変えたくない、どのCDNでも使える方法にしたい |
前の3つは、利用者のリゾルバーにはAレコード（とAAAAレコード）として見えるため、ルートに置いてもMXやTXTと共存できます。対応状況、レコード型の名称、料金体系はサービスごとに異なり、変わることもあるため、利用中のDNSサービスの公式ドキュメントで確認してください（2026年10月現在）。
CNAMEフラット化の注意点
フラット化やALIASは便利ですが、通常のCNAMEとは動きが違う点があります。
CDNの拠点選択が粗くなることがあるDNSで利用者の地域を判断して近い拠点のIPを返すタイプのCDNでは、フラット化するとCNAMEの先を解決するのは利用者のリゾルバーではなくDNSサービス側になります。その結果、利用者から遠い拠点のIPが返る可能性があります。エニーキャスト方式で同じIPを全世界に広告しているCDNではこの影響は小さくなります。CDN側のドキュメントで、ルートドメインでの利用時の推奨構成を確認してください。
TTLと更新のタイミングCDN側がIPアドレスを変えても、DNSサービスがフラット化した結果をキャッシュしている間は古いIPが返ります。サービスによってはTTLを自分で選べないこともあります。
Cloudflareのプロキシ有効時は別の話Cloudflare でプロキシ（オレンジの雲）を有効にしたレコードは、CloudflareのIPが返り、Cloudflare自体がCDNとして動きます。フラット化が意味を持つのは、Cloudflare をDNSとしてだけ使い、ルートを外部のCDN（CloudFront など）に向ける場合です。外部CDNの前段でCloudflareのプロキシを重ねると、キャッシュや証明書の管理が二重になり、問題の切り分けが難しくなります。
手順1：CDN側で独自ドメインと証明書を設定する
DNSを向ける前に、CDN側で example.com（と www.example.com）を独自ドメインとして登録し、そのドメインのSSL証明書を用意します。多くのCDNでは、証明書の発行時にドメインの所有確認のためのCNAMEやTXTを追加するよう求められます。このレコードを先に追加して証明書の発行を済ませてから、トラフィックを向けるのが安全な順番です。証明書が用意できていない状態でDNSだけ切り替えると、訪問者に証明書エラーが表示されます。
あわせて、CDNがコンテンツを取りに行く先（オリジン）を決めます。ルートドメインをCDNに向けたあとで、オリジンにも example.com を指定すると、CDNが自分自身に問い合わせてしまいます。origin.example.com のようなオリジン専用のホスト名を作り、サーバーのIPを指すAレコード（CDNを経由しない設定）にしておくのが一般的です。オリジン側のWebサーバーは、CDNから届く Host ヘッダー（通常は example.com）で応答できるようにします。
手順2：DNSレコードを設定する
設定前に、現在のDNSレコードをエクスポートするか画面を記録してバックアップし、ルートのAレコードのTTLを前日までに短くしておきます。
Cloudflare をDNSとして使い、ルートを外部CDNに向ける場合の例は次のとおりです。
タイプ 名前 内容 プロキシ
CNAME example.com dxxxxxxxx.cloudfront.net DNSのみ
CNAME www dxxxxxxxx.cloudfront.net DNSのみ
A origin 203.0.113.10 DNSのみ
MX example.com mail.example.com（優先度10）Cloudflare ではルートにCNAMEを入力すると、自動でフラット化した応答になります。Route 53 と CloudFront の組み合わせなら、ルートにAレコードのエイリアスを作り、エイリアス先に CloudFront のディストリビューションを選びます（IPv6を有効にしている場合はAAAAのエイリアスも作ります）。
wwwを正規URLにする方法を選ぶ場合は、www にCNAMEを設定し、ルートはWebサーバーやレジストラの転送機能で https://www.example.com/ へ301リダイレクトします。ルートへのHTTPSアクセスもリダイレクトするには、ルート側にも証明書が要ります。
手順3：応答とCDN経由の配信を確認する
# ルートドメインはAレコードとして返るか（CNAMEがそのまま見えないか）
dig example.com A +noall +answer
dig example.com CNAME +short
# MXやTXTが消えていないか
dig example.com MX +short
dig example.com TXT +short
# CDNを経由しているか（CDN固有のヘッダーが付くか）
curl -sI https://example.com/ | grep -i -E "x-cache|via|server|cf-cache-status"フラット化が効いていれば、dig example.com A にはIPアドレスが返り、CNAMEの問い合わせには何も返りません。CDNを経由しているかは、レスポンスヘッダーで判断します。CloudFront なら x-cache、Cloudflare なら cf-cache-status といったヘッダーが付くのが目安です。ヘッダーの種類はCDNごとに異なるので、利用中のサービスの資料で確認してください。
WordPress側で見直すこと
DNSとCDNの設定に合わせて、WordPress側も確認します。
- サイトURL：ルートと www のどちらを正規URLにするかを決め、「設定」→「一般」のWordPressアドレスとサイトアドレス（または wp-config.php の
WP_HOMEとWP_SITEURL）をそれに合わせます。変えると管理画面に入れなくなることがあるため、事前にデータベースのバックアップを取ってください。 - 記事内のURL：正規URLを変えた場合、本文中の古いURLは自動では変わりません。WP-CLI の
wp search-replaceを--dry-run付きで実行して影響を確認してから置き換えます。 - キャッシュから外すページ：管理画面（
/wp-admin/）、ログインページ、ログイン中のユーザーのページ、カートや会員ページはCDNでキャッシュしない設定にします。ログイン中かどうかはwordpress_logged_in_で始まるクッキーで判断できます。 - 混在コンテンツ：CDN経由でHTTPS配信にしたあと、画像やCSSが http:// のままだとブラウザが警告を出したり読み込みを止めたりします。
まとめ
- ルートドメインにはSOA・NS・MXなどがあるため、規格上CNAMEを置けません。
- 解決策は、CNAMEフラット化、ALIAS / ANAME、Route 53 のエイリアス、www を正規URLにしてルートはリダイレクト、の4つです。
- フラット化はCDNの拠点選択やTTLの扱いが通常のCNAMEと異なるため、CDN側の推奨構成を確認します。
- CDN側で証明書を先に用意し、オリジン専用のホスト名を作ってから、DNSを切り替えます。
- 切り替え後は
digでAレコードとMX・TXTを、curl -IでCDN経由の配信を確認し、WordPressのURL設定とキャッシュ除外も見直します。