DNS CNAMEレコードについて

CNAMEレコードとは、あるホスト名を別のホスト名の別名として扱わせるためのDNSレコードです。

CNAMEは「Canonical Name」の略で、日本語では「正規名」と訳されることがあります。

DNSでは、ドメイン名をIPアドレスに結びつけるだけでなく、あるドメイン名を別のドメイン名の別名として扱うこともできます。その役割を持つのがCNAMEレコードです。

たとえば、以下のような設定があります。

www.example.com.   CNAME   example.com.

これは、www.example.com は example.com の別名である、という意味です。

この場合、www.example.com にアクセスされたとき、DNSはまず www.example.com のCNAMEを確認し、次に example.com のAレコードやAAAAレコードを参照して、最終的なIPアドレスを取得します。

つまりCNAMEレコードは、IPアドレスを直接指定するのではなく、別のホスト名を参照させるためのレコードです。

CNAMEレコードの基本的な仕組み

CNAMEはIPアドレスではなくホスト名を指定する

CNAMEレコードでは、参照先にIPアドレスを指定するのではなく、ホスト名を指定します。

正しい例は以下です。

blog.example.com.   CNAME   example.hatenablog.com.

一方、以下のようにIPアドレスを指定するのは誤りです。

blog.example.com.   CNAME   203.0.113.10

IPアドレスを直接指定したい場合は、CNAMEではなくAレコードやAAAAレコードを使います。

example.com.   A      203.0.113.10
example.com.   AAAA   2001:db8::1

CNAMEはあくまで「この名前は別の名前の別名です」と示すレコードです。

名前解決は最終的にAレコードやAAAAレコードへ進む

CNAMEレコードだけでは、Webサーバーへ接続するためのIPアドレスは得られません。

たとえば、以下のような設定があるとします。

blog.example.com.      CNAME   service.example.net.
service.example.net.   A       203.0.113.10

この場合、名前解決の流れは次のようになります。

1. blog.example.com のDNS情報を問い合わせる
2. blog.example.com は service.example.net の別名だと分かる
3. service.example.net のAレコードを問い合わせる
4. 203.0.113.10 というIPアドレスが返る
5. そのIPアドレスへ接続する

このように、CNAMEは最終的な接続先IPを直接返すのではなく、参照先のホスト名を返します。

その後、参照先のAレコードやAAAAレコードを解決して、実際の接続先が決まります。

CNAMEレコードとAレコードの違い

Aレコードはドメイン名をIPv4アドレスに向ける

Aレコードは、ドメイン名をIPv4アドレスに直接結びつけるレコードです。

example.com.   A   203.0.113.10

これは、example.com の接続先が 203.0.113.10 であることを示します。

WebサーバーのIPアドレスが固定されている場合や、自社でサーバーを管理している場合などに使われます。

AAAAレコードはドメイン名をIPv6アドレスに向ける

AAAAレコードは、ドメイン名をIPv6アドレスに結びつけるレコードです。

example.com.   AAAA   2001:db8::1

AレコードがIPv4用であるのに対し、AAAAレコードはIPv6用です。

CNAMEレコードはドメイン名を別のドメイン名に向ける

CNAMEレコードは、IPアドレスではなく別のホスト名を指定します。

www.example.com.   CNAME   example.com.

これは、www.example.com は example.com の別名である、という意味です。

Aレコード・AAAAレコード・CNAMEレコードの違い

レコード	指定先	主な用途
Aレコード	IPv4アドレス	ドメインをIPv4アドレスに向ける
AAAAレコード	IPv6アドレス	ドメインをIPv6アドレスに向ける
CNAMEレコード	ホスト名	ドメインを別のドメイン名の別名として扱う

CNAMEの大きな特徴は、参照先サービスのIPアドレスが変わっても、CNAME先のホスト名が変わらなければ利用者側のDNS設定を変更しなくてよい点です。

そのため、外部サービスやSaaSに独自ドメインを接続するときによく使われます。

CNAMEレコードの主な用途

wwwありのドメインを設定する

CNAMEレコードは、www 付きのサブドメインを設定するときによく使われます。

www.example.com.   CNAME   example.com.

この設定により、www.example.com は example.com の別名として扱われます。

ただし、CNAMEを設定しただけで、ブラウザのURLが自動的に https://example.com/ に変わるわけではありません。

たとえば、ユーザーが以下のURLにアクセスしたとします。

https://www.example.com/

CNAMEによって www.example.com が example.com と同じ接続先を参照したとしても、ブラウザのアドレスバーは https://www.example.com/ のままになることがあります。

URLを wwwあり または wwwなし のどちらかに統一したい場合は、DNS設定だけでなく、Webサーバー側で301リダイレクトなどを設定する必要があります。

サブドメインを外部サービスに向ける

CNAMEレコードは、サブドメインを外部サービスに接続するときにもよく使われます。

たとえば、以下のようなケースです。

blog.example.com.   CNAME   example.hatenablog.com.

shop.example.com.   CNAME   shops.myshopify.com.

lp.example.com.   CNAME   custom.example-service.com.

このように、blog、shop、lp などのサブドメインを外部サービスが指定するホスト名に向けます。

Webサイト運用やマーケティング施策では、次のようなサービスでCNAME設定が登場します。

用途	例
ブログ	はてなブログ、note、WordPress.comなど
ECサイト	Shopify、BASE、カラーミーショップなど
LP作成ツール	STUDIO、ペライチ、Instapageなど
MA・CRM	HubSpot、Salesforce系ツールなど
CDN	Cloudflare、Fastly、Amazon CloudFrontなど
メール配信	SendGrid、Mailchimp、Amazon SESなど

特に外部サービスへ独自ドメインを接続する場合、サービス側から「このCNAMEをDNSに追加してください」と指定されることが多くあります。

CDNや画像配信で使う

CNAMEレコードは、CDNや静的ファイル配信用のサブドメインにも使われます。

cdn.example.com.   CNAME   example.cdn-provider.net.

また、以下のようなサブドメインをCDNに向けることもあります。

assets.example.com
img.example.com
static.example.com

CDNを使うことで、画像、CSS、JavaScriptなどの静的ファイルを高速に配信しやすくなります。

Webサイトの表示速度改善やサーバー負荷軽減を目的として、CNAMEでCDNのホスト名に向けるケースがあります。

メール認証で使う

CNAMEレコードは、メール配信サービスの認証で使われることもあります。

特にDKIM認証では、サービスによってCNAMEを指定される場合があります。

selector1._domainkey.example.com.   CNAME   selector1-example-com._domainkey.mailservice.com.

ただし、DKIMは必ずCNAMEで設定するわけではありません。

サービスによっては、TXTレコードでDKIM公開鍵を設定する場合もあります。

つまり、DKIMの設定方法には大きく分けて次のようなパターンがあります。

設定方法	内容
TXTレコード方式	自社ドメインのDNSにDKIM公開鍵を直接設定する
CNAME方式	メール配信サービス側のDKIMレコードを参照する

メール配信サービス、MAツール、CRMなどを使う場合は、サービス側の指示に従って設定することが重要です。

CNAMEレコードでできること

サブドメインを別サービスに向けられる

CNAMEを使うと、サブドメインを外部サービスに向けることができます。

たとえば、以下のような使い方です。

blog.example.com → ブログサービス
shop.example.com → ECサービス
lp.example.com → LP作成ツール
cdn.example.com → CDN

このように、メインサイトとは別のサービスをサブドメインで運用したい場合に便利です。

参照先サービスのIP変更に追従しやすい

外部サービスのIPアドレスは、サービス側の都合で変わることがあります。

もしAレコードでIPアドレスを直接指定していると、IPアドレスが変わったときに自分でDNS設定を変更しなければなりません。

一方、CNAMEで外部サービスのホスト名を指定しておけば、参照先のホスト名が維持される限り、サービス側のIP変更に追従しやすくなります。

たとえば、以下のような設定です。

lp.example.com.   CNAME   custom.service-provider.com.

この場合、custom.service-provider.com のIPアドレスが変わっても、lp.example.com のCNAME設定自体は変更しなくて済むことがあります。

DNS管理をシンプルにできる

複数のサブドメインを同じ参照先に向けたい場合、CNAMEを使うことで管理しやすくなることがあります。

www.example.com.        CNAME   example.com.
campaign.example.com.   CNAME   service.example.net.
lp.example.com.         CNAME   service.example.net.

外部サービス側の接続先がホスト名で指定されている場合、CNAMEを使うことでDNS設定を分かりやすく保てます。

CNAMEレコードでできないこと

URLをリダイレクトすることはできない

CNAMEはDNSの名前解決に使うレコードであり、HTTPリダイレクトではありません。

そのため、以下のようにURLを変えることはCNAMEだけではできません。

https://www.example.com/
↓
https://example.com/

このようなURL転送を行うには、Webサーバー、CDN、ホスティングサービス、リダイレクト設定などを使います。

代表的には301リダイレクトを設定します。

パス付きURLには向けられない

CNAMEでは、以下のようなパス付きURLを指定できません。

blog.example.com.   CNAME   example.com/blog/

これは誤りです。

CNAMEの値に指定できるのは、ホスト名です。

正しくは以下のような形式です。

blog.example.com.   CNAME   service.example.net.

/blog/ や /lp/ のようなパス単位の振り分けは、DNSではなくWebサーバーやアプリケーション側で設定します。

https:// や http:// は指定できない

CNAMEの値にURLを入れるのも誤りです。

誤った例です。

lp.example.com.   CNAME   https://service.example.net/

正しくは、プロトコルやスラッシュを除いたホスト名を指定します。

lp.example.com.   CNAME   service.example.net.

DNSはHTTPやHTTPSのURLを扱う仕組みではありません。

DNSが扱うのは、あくまでドメイン名・ホスト名です。

IPアドレスを直接指定することはできない

CNAMEの参照先にIPアドレスを指定することはできません。

誤った例です。

www.example.com.   CNAME   203.0.113.10

IPアドレスを直接指定したい場合は、Aレコードを使います。

www.example.com.   A   203.0.113.10

IPv6アドレスを指定する場合は、AAAAレコードを使います。

CNAMEレコードの重要な制約

CNAMEを設定した名前には他のレコードを置けない

CNAMEレコードには重要な制約があります。

CNAMEを設定したホスト名には、原則として他のレコードを同時に設定できません。

たとえば、以下のような設定は基本的にNGです。

www.example.com.   CNAME   example.com.
www.example.com.   A       203.0.113.10

同じ www.example.com にCNAMEとAレコードが同時に存在しています。

これはDNS仕様上、問題のある設定です。

同様に、以下のような組み合わせも避ける必要があります。

www.example.com.   CNAME   example.com.
www.example.com.   TXT     "verification-code"

CNAMEを設定した名前は、別名として扱われます。

その名前にA、AAAA、MX、TXTなどの他のレコードを同時に置くことはできないと考えるのが基本です。

ルートドメインには通常CNAMEを設定できない

example.com のようなルートドメインには、通常のCNAMEレコードを設定できません。

ここでいうルートドメインとは、次のようなドメインです。

example.com

一方、以下はサブドメインです。

www.example.com
blog.example.com
shop.example.com

ルートドメインには、DNSの仕組み上、SOAレコードやNSレコードなどが必要です。

しかし、CNAMEを設定した名前には他のレコードを置けません。

そのため、SOAやNSが必須となるルートドメインに通常のCNAMEを設定すると、DNS仕様上の制約にぶつかります。

たとえば、以下のような設定は通常避けるべきです。

example.com.   CNAME   service.example.net.

ルートドメインを外部サービスに向けたい場合は、次のような方法を検討します。

Aレコード
AAAAレコード
ALIASレコード
ANAMEレコード
CNAME Flattening

ただし、ALIAS、ANAME、CNAME Flatteningは標準的なCNAMEそのものではなく、DNS事業者が提供する独自機能・拡張機能であることが多いです。

MXレコードやNSレコードの参照先にCNAMEを使うべきではない

CNAMEでは、もう一つ注意すべき点があります。

MXレコードやNSレコードの参照先に、CNAMEで定義された別名を使うべきではありません。

たとえば、以下のような設定は避けるべきです。

example.com.       MX      10 mail.example.com.
mail.example.com.  CNAME   mail-service.example.net.

この例では、MXレコードの参照先である mail.example.com がCNAMEになっています。

DNSの設計上、MXレコードやNSレコードの参照先には、AレコードやAAAAレコードを持つ実体のあるホスト名を指定するのが原則です。

メールサーバーやネームサーバーまわりの設定では、CNAMEを安易に使わないよう注意が必要です。

CNAMEチェーンは短くする

CNAMEが別のCNAMEを指すことはあります。

たとえば、以下のような設定です。

a.example.com.   CNAME   b.example.com.
b.example.com.   CNAME   c.example.com.
c.example.com.   A       203.0.113.10

このように、CNAMEが連続している状態をCNAMEチェーンと呼びます。

CNAMEチェーン自体が必ず禁止されるわけではありません。

しかし、名前解決の回数が増えるため、表示速度や安定性の面で不利になることがあります。

また、トラブルが起きたときに、どこで問題が発生しているのか追いにくくなります。

できるだけ以下のように、参照先を短くするのが望ましいです。

a.example.com.   CNAME   c.example.com.

CNAMEとリダイレクトの違い

CNAMEはDNS上の別名設定

CNAMEは、DNS上でホスト名を別名として扱わせる設定です。

www.example.com.   CNAME   example.com.

この設定により、www.example.com は example.com を参照します。

ただし、CNAMEはブラウザのアドレスバーを変更する機能ではありません。

ユーザーが https://www.example.com/ にアクセスした場合、URLが自動的に https://example.com/ に変わるとは限りません。

リダイレクトはHTTP上のURL転送

リダイレクトは、Webサーバーやアプリケーションが行うHTTP上の転送です。

たとえば、以下のような動きです。

https://www.example.com/
↓
https://example.com/

この場合、ブラウザのアドレスバーも https://example.com/ に変わります。

URLを1つに統一したい場合は、CNAMEではなく301リダイレクトなどを使います。

CNAMEとリダイレクトの違い

項目	CNAME	リダイレクト
役割	DNS上の別名設定	HTTP上のURL転送
URL表示	変わらないことが多い	変わる
パス指定	不可	可能
URL統一	直接はできない	301リダイレクトなどで可能
設定場所	DNS	Webサーバー、CDN、CMS、ホスティングサービスなど

CNAMEとリダイレクトは混同されやすいですが、まったく別の仕組みです。

CNAMEとURL統一の関係

CNAMEだけでは正規URLの統一はできない

サイト運用では、wwwあり と wwwなし のURLを統一したい場合があります。

たとえば、以下の2つのURLで同じページが表示されるケースです。

https://example.com/
https://www.example.com/

この状態を放置すると、アクセス解析やサイト管理上、URLが分散して扱われる可能性があります。

しかし、CNAMEを設定しただけでは、正規URLの統一はできません。

www.example.com.   CNAME   example.com.

この設定をしても、https://www.example.com/ が自動で https://example.com/ にリダイレクトされるわけではありません。

URLを統一する場合は、Webサーバー側で301リダイレクトなどを設定します。

https://www.example.com/
↓ 301リダイレクト
https://example.com/

canonicalタグやサイトマップも確認する

URLを統一する場合は、301リダイレクトに加えてcanonicalタグの確認も重要です。

たとえば、https://example.com/ を正規URLにしたい場合、ページ内のcanonicalタグも以下のように統一されているか確認します。

<link rel="canonical" href="https://example.com/">

また、サイトマップに記載するURLや、管理ツールに登録しているURLも、正規URLに合わせておくと管理しやすくなります。

CNAMEはあくまでDNS設定であり、URLの正規化を直接行う仕組みではありません。

URLを統一するには、リダイレクト、canonicalタグ、内部リンク、サイトマップなどを総合的に確認する必要があります。

CNAME設定時の入力項目

DNS管理画面で入力する主な項目

DNS管理画面でCNAMEを追加する場合、一般的には以下のような項目を入力します。

項目	入力例	意味
種別	CNAME	レコードの種類
ホスト名	www	設定したいサブドメイン
値 / 参照先	example.com	向け先のホスト名
TTL	3600	DNS情報をキャッシュする時間

たとえば、以下のように入力します。

種別：CNAME
ホスト名：www
値：example.com
TTL：3600

この場合、意味としては以下のようになります。

www.example.com.   CNAME   example.com.

ホスト名の入力形式に注意する

DNS管理画面によって、ホスト名欄に入力する形式が異なります。

たとえば、www.example.com を設定したい場合、管理画面によっては以下のように入力します。

www

別の管理画面では、以下のように完全なホスト名を入力する場合もあります。

www.example.com

この違いを理解しないまま入力すると、意図しないレコードが作られる可能性があります。

たとえば、www.example.com と入力したつもりが、管理画面側でドメイン名が自動補完され、以下のようになることがあります。

www.example.com.example.com

DNS管理画面の仕様を確認してから入力することが大切です。

末尾のドットに注意する

DNSの完全修飾ドメイン名では、末尾にドットを付けることがあります。

example.com.

ただし、多くのDNS管理画面では、末尾のドットを入力しなくても自動的に処理されます。

example.com

どちらを入力すべきかは、DNS管理サービスによって異なります。

古い管理画面やゾーンファイルを直接編集する場合、末尾のドットを付けないと、意図せず自分のドメイン名が後ろに補完されることがあります。

たとえば、service.example.net と入力したつもりが、以下のように解釈されるケースです。

service.example.net.example.com

最近のDNS管理画面では分かりやすく処理されることが多いですが、CNAMEの値を入力するときは注意が必要です。

TTLとは

TTLはDNS情報のキャッシュ時間

TTLは「Time To Live」の略で、DNS情報をキャッシュする時間を表します。

たとえば、以下のようなCNAMEレコードがあるとします。

www.example.com.   3600   IN   CNAME   example.com.

この場合、TTLは3600秒です。

つまり、DNS情報が一定期間キャッシュされることを意味します。

DNSは毎回権威DNSサーバーへ問い合わせているわけではありません。

多くの場合、利用者の端末、ブラウザ、OS、ISPのDNSリゾルバ、パブリックDNSなどに情報が一時的に保存されます。

そのため、DNS設定を変更しても、すぐにすべての環境で新しい情報が見えるとは限りません。

TTLの目安

TTLの値は、サービス側の指定がある場合はそれに従うのが基本です。

一般的な目安としては、以下のように考えられます。

状況	TTLの目安
通常運用	3600秒〜86400秒程度
DNS変更前	300秒〜600秒程度
サーバー移行直後	300秒〜3600秒程度
安定運用後	3600秒以上

サーバー移行や外部サービス切り替えを予定している場合は、事前にTTLを短くしておくと、変更後の反映を確認しやすくなります。

ただし、TTLを短くしすぎるとDNS問い合わせが増えます。

通常運用では、必要以上に短くし続ける必要はありません。

CNAME設定後に確認すべきこと

DNSが正しく反映されているか確認する

CNAMEを設定したら、まずDNSが正しく返っているか確認します。

MacやLinuxでは、dig コマンドがよく使われます。

dig www.example.com CNAME

正しく設定されていれば、以下のような結果が返ります。

www.example.com.   3600   IN   CNAME   example.com.

Windowsでは、nslookup を使うこともできます。

nslookup -type=CNAME www.example.com

オンラインのDNSチェックツールを使って確認する方法もあります。

Aレコードまで解決できるか確認する

CNAMEが返っているだけでなく、最終的にAレコードやAAAAレコードまで解決できるかも確認します。

dig www.example.com

CNAME先のAレコードが正しく返らない場合、ブラウザでWebサイトを表示できない可能性があります。

CNAMEはあくまで別名設定なので、最終的に参照先のホスト名がIPアドレスに解決できる必要があります。

外部サービス側で独自ドメインが登録されているか確認する

CNAMEを正しく設定しても、外部サービス側で独自ドメインが登録されていなければ、正しいページが表示されないことがあります。

たとえば、以下のようにDNSを設定したとします。

lp.example.com.   CNAME   service.example.net.

しかし、外部サービス側で lp.example.com が登録されていない場合、エラー画面が表示されることがあります。

外部サービスに独自ドメインを接続する場合は、一般的に次の両方が必要です。

1. DNS側でCNAMEを設定する
2. 外部サービス側で独自ドメインを登録・認証する

DNSだけを設定しても完了ではない点に注意しましょう。

SSL証明書が有効か確認する

CNAMEを設定して独自ドメインを外部サービスに向けても、それだけでHTTPSが使えるとは限りません。

たとえば、以下のように設定したとします。

lp.example.com.   CNAME   service.example.net.

この状態で、以下のURLにアクセスします。

https://lp.example.com/

外部サービス側で lp.example.com 用のSSL証明書が発行されていなければ、証明書エラーが発生することがあります。

最近のSaaSやホスティングサービスでは、独自ドメインを登録するとSSL証明書を自動発行してくれることが多いです。

ただし、DNS反映後に「SSLを有効化する」「ドメインを認証する」といった操作が必要な場合もあります。

よくあるCNAME設定ミス

CNAMEの値にURLを入れてしまう

よくあるミスが、CNAMEの値にURLを入れてしまうケースです。

誤った例です。

blog.example.com.   CNAME   https://example.hatenablog.com/

正しくは、ホスト名だけを入力します。

blog.example.com.   CNAME   example.hatenablog.com.

https:// や末尾の / は不要です。

CNAMEの値にパスを入れてしまう

以下のように、パス付きURLをCNAMEに入れることはできません。

lp.example.com.   CNAME   example.com/lp/

正しくは、ホスト名だけを指定します。

lp.example.com.   CNAME   service.example.net.

/lp/ のようなパス単位の制御は、DNSではなくWebサーバーやアプリケーション側で行います。

同じホスト名にAレコードとCNAMEを設定してしまう

以下のように、同じホスト名にAレコードとCNAMEを同時に設定するのは基本的にNGです。

www.example.com.   A       203.0.113.10
www.example.com.   CNAME   example.com.

www.example.com をIPアドレスに直接向けたいならAレコードを使います。

別のホスト名の別名として扱いたいならCNAMEを使います。

同じ名前に両方を設定しないようにしましょう。

ルートドメインにCNAMEを設定しようとする

以下のように、ルートドメインにCNAMEを設定しようとするケースもあります。

example.com.   CNAME   service.example.net.

しかし、通常のDNS仕様では、ルートドメインにCNAMEを置くことはできません。

ルートドメインを外部サービスに向けたい場合は、サービス側が指定する方法に従います。

よく使われる方法は以下です。

Aレコード
AAAAレコード
ALIAS
ANAME
CNAME Flattening

DNS事業者や外部サービスによって対応方法が異なるため、公式の設定手順を確認することが重要です。

外部サービス側の設定を忘れる

DNSでCNAMEを設定しても、外部サービス側の独自ドメイン設定が完了していなければ、正しく表示されないことがあります。

たとえば、DNS側で以下のように設定したとします。

shop.example.com.   CNAME   shops.myshopify.com.

しかし、Shopify側で shop.example.com を独自ドメインとして登録していなければ、正常に接続できない可能性があります。

CNAME設定と外部サービス側のドメイン登録は、セットで考える必要があります。

CNAME設定の実務手順

外部サービス側で独自ドメインを追加する

まず、利用する外部サービスの管理画面で独自ドメインを追加します。

例としては、以下のようなサブドメインです。

blog.example.com
shop.example.com
lp.example.com
campaign.example.com

外部サービス側にドメインを登録すると、DNSに追加すべきCNAME情報が表示されることがあります。

指定されたCNAME先を確認する

外部サービスから、以下のようなCNAME先を指定されます。

custom.service-provider.com

または、サービスごとに固有のホスト名が発行されることもあります。

abc123.service-provider.net

この値を正確にDNS管理画面へ入力します。

DNS管理画面でCNAMEを追加する

DNS管理画面で、CNAMEレコードを追加します。

例です。

種別：CNAME
ホスト名：lp
値：custom.service-provider.com
TTL：3600

この設定により、以下のようなレコードが作成されます。

lp.example.com.   CNAME   custom.service-provider.com.

入力時は、ホスト名欄に lp と入力するのか、lp.example.com と入力するのかを確認しましょう。

DNS反映を確認する

設定後、DNSが正しく返っているか確認します。

dig lp.example.com CNAME

または、オンラインのDNSチェックツールで確認します。

DNSはキャッシュの影響を受けるため、反映までに時間差が出ることがあります。

特にネームサーバー変更を伴う場合は、環境によって数時間から1〜3日程度、旧情報が見えることもあります。

外部サービス側で認証する

DNSが反映されたら、外部サービス側でドメイン認証を行います。

管理画面に以下のようなボタンがある場合があります。

Verify
確認
認証
接続を確認

CNAMEが正しく設定されていれば、外部サービス側でドメイン所有や接続状態を確認できます。

SSLを有効化する

独自ドメインでHTTPSを使う場合、SSL証明書の発行が必要です。

多くのサービスでは自動発行されますが、次のような操作が必要な場合もあります。

SSLを有効化
HTTPSを有効化
証明書を発行
ドメイン認証後に自動発行

CNAME設定後にDNSは正しく向いているのにHTTPSでエラーになる場合、SSL証明書の状態を確認しましょう。

CNAMEとALIAS・ANAME・CNAME Flatteningの違い

ALIAS・ANAME・CNAME FlatteningはCNAMEの代替として使われる

ルートドメインを外部サービスに向けたい場合、通常のCNAMEは使えません。

そのため、DNS事業者によっては以下のような機能を提供しています。

ALIAS
ANAME
CNAME Flattening

これらは、CNAMEのようにホスト名を参照しつつ、外部からの問い合わせにはAレコードやAAAAレコードのようにIPアドレスを返す仕組みとして使われることがあります。

標準的なCNAMEそのものではない

注意したいのは、ALIAS、ANAME、CNAME Flatteningは、標準的なCNAMEレコードそのものではないという点です。

DNS事業者が内部的に参照先ホスト名を解決し、最終的なIPアドレスを返す独自機能であることが多いです。

そのため、対応状況や挙動はDNS事業者によって異なります。

たとえば、以下のような点に違いが出ることがあります。

項目	注意点
対応可否	DNS事業者によって使える機能が異なる
DNSSEC	事業者や設定によって影響が出る場合がある
外部サービス認証	CNAME確認が必要なサービスでは注意が必要
返答形式	CNAMEではなくA/AAAAとして返ることがある

ルートドメインを外部サービスに接続する場合は、DNS事業者と外部サービス双方の手順を確認しましょう。

CNAMEのトラブルシューティング

設定したのにWebサイトが表示されない

CNAMEを設定したのにWebサイトが表示されない場合、原因はいくつか考えられます。

原因	確認ポイント
DNSがまだ反映されていない	TTLやキャッシュの影響を確認する
ホスト名の入力ミス	www と www.example.com の違いを確認する
CNAME先の入力ミス	https:// や / が入っていないか確認する
外部サービス側未設定	独自ドメインがサービス側に登録されているか確認する
SSL未発行	HTTPS証明書が有効か確認する
他レコードと競合	同じホスト名にA/TXT/MXなどがないか確認する
ネームサーバー違い	実際に使われているDNS管理先を確認する

CNAMEの設定自体が正しくても、外部サービス側の設定やSSLの状態によって表示できないことがあります。

wwwありは表示されるがwwwなしは表示されない

www.example.com と example.com は別の名前です。

そのため、以下のように www だけを設定しても、ルートドメインには自動的に反映されません。

www.example.com.   CNAME   service.example.net.

この場合、example.com には別途設定が必要です。

候補としては、以下があります。

Aレコード
AAAAレコード
ALIAS
ANAME
CNAME Flattening
リダイレクト設定

wwwあり と wwwなし のどちらを基本のURLにするかを決めたうえで、DNSとリダイレクトを整える必要があります。

HTTPSで証明書エラーになる

DNSが正しく設定されていても、SSL証明書が未発行または未設定の場合、HTTPSでエラーになります。

確認すべき点は以下です。

確認項目	内容
外部サービス側のSSL設定	独自ドメイン用の証明書が発行済みか
DNS反映状態	CNAMEが正しく返っているか
ドメイン認証	サービス側で認証が完了しているか
Cloudflareなどのプロキシ	SSLモードが適切か
証明書の対象ドメイン	www と wwwなし の両方に対応しているか

特に外部サービスでは、DNS設定後にSSL証明書の発行まで少し時間がかかる場合があります。

CNAME設定時のチェックリスト

DNS設定前に確認すること

CNAMEを追加する前に、以下を確認しましょう。

□ 設定したいのはルートドメインではなくサブドメインか
□ 外部サービス側で独自ドメインを登録したか
□ サービスから指定されたCNAME先を正確に確認したか
□ ホスト名欄に何を入力すべきか確認したか
□ TTLの指定があるか確認したか

DNS設定時に確認すること

DNS管理画面で入力するときは、以下を確認します。

□ 種別はCNAMEになっているか
□ CNAMEの値に https:// を入れていないか
□ CNAMEの値に /path/ を入れていないか
□ CNAMEの値がIPアドレスになっていないか
□ 同じホスト名にA/AAAA/TXT/MXなどが存在しないか
□ 末尾のドットの扱いを確認したか

DNS設定後に確認すること

設定後は、以下を確認します。

□ digやnslookupでCNAMEが返るか
□ 最終的にA/AAAAまで解決できるか
□ 外部サービス側で認証が完了しているか
□ HTTPSで証明書エラーが出ないか
□ wwwあり・wwwなしの表示方針が整理されているか
□ 必要に応じて301リダイレクトを設定したか
□ サイトマップや内部リンクのURLが基本URLに合っているか

まとめ

CNAMEレコードは、あるホスト名を別のホスト名の別名として扱わせるためのDNSレコードです。

代表的には、以下のような用途で使われます。

www.example.com → example.com
blog.example.com → ブログサービス
shop.example.com → ECサービス
lp.example.com → LP作成ツール
cdn.example.com → CDN
selector._domainkey.example.com → メール配信サービス

CNAMEを使うことで、外部サービスのホスト名を参照でき、サービス側のIPアドレス変更にも追従しやすくなります。

一方で、CNAMEには重要な制約があります。

・CNAMEの値にはIPアドレスではなくホスト名を指定する
・https:// や /path/ は指定できない
・CNAMEを設定した名前には他のレコードを置けない
・ルートドメインには通常のCNAMEを設定できない
・MXやNSの参照先にCNAME aliasを使うべきではない
・CNAMEはHTTPリダイレクトではない
・URLの統一には301リダイレクトなどが必要

実務では、CNAMEは「独自ドメインを外部サービスに接続するための設定」としてよく登場します。

ただし、DNS設定だけで完了するとは限りません。

外部サービス側の独自ドメイン登録、ドメイン認証、SSL証明書、リダイレクト設定、URLの統一まで含めて確認することが大切です。

以上、DNS CNAMEレコードについてでした。

最後までお読みいただき、ありがとうございました。