CNAMEとは

CNAMEを読むときの前提

CNAME（Canonical Name）は、あるFQDNを別のFQDNの別名として扱うDNSレコードです。CDN、SaaS、外部メールサービス、ロードバランサー、検証用ドメインなどで、利用者に見せる名前と実際の提供先を分けたいときに使います。

実務では、CNAMEの値だけでなく、CNAME先がさらにどのA/AAAAへ解決されるか、TTL、証明書SAN、CDN側のホスト名登録、旧環境の受け口を確認します。別名の先を追わずに疎通だけ見ると、原因を見誤ります。

証跡には、元FQDN、CNAME先、最終A/AAAA、TTL、権威DNSの回答、利用者側DNSの回答、確認時刻を残します。

CNAMEチェーンを最後まで追う

CNAMEは別名を示すだけで、最終的にはA/AAAAなどの接続先へたどり着きます。障害時は、元の名前、CNAME先、その先のCNAME、最終IPまで順番に記録します。

CDNやSaaSでは、CNAME先がサービス側で有効化されていない、ホスト名検証が未完了、証明書が発行されていない、旧CNAMEが残っている、といった状態で失敗します。

• 元FQDNから最終A/AAAAまで回答を追う。
• CNAME先のサービス側設定も確認する。
• 証明書SANとHostヘッダーの扱いを見る。

使えない場所とループを避ける

一般にzone apexではCNAMEを置けない環境が多く、MXやNSの対象名そのものをCNAMEにする設計も避けます。DNSサービスによってはALIASやANAMEのような独自機能で代替しますが、標準的なCNAMEとは挙動が違います。

CNAME同士が循環すると名前解決が失敗します。長すぎるチェーンは遅延やトラブル時の調査負荷にもなります。レビューでは、どこまで別名が続くかを図示すると関係者に伝わりやすくなります。

• zone apexでCNAMEを使っていないか確認する。
• MX/NSの参照先がCNAMEになっていないか見る。
• CNAMEループや長すぎるチェーンを避ける。

切替と戻しを設計する

CNAME切替は、SaaS移行やCDN切替で便利ですが、戻し時に旧環境が同じFQDNを受けられるかを先に確認します。DNSだけ戻しても、証明書、LB、CDN、アプリ側のHost許可が古いままだと復旧しません。

TTLは元FQDNとCNAME先の両方で効きます。CNAME先のTTLが長い場合、元レコードを短くしても利用者側の見え方がすぐ変わらないことがあります。

• 旧CNAME、新CNAME、最終IPを変更前後で残す。
• 元FQDNとCNAME先のTTLを確認する。
• 戻し時の証明書と受け口を確認する。

変更証跡と引き継ぎ

CNAME変更では、所有者、用途、変更理由、サービス側設定、DNS回答、疎通結果、戻し条件を残します。外部サービスへ向ける場合は、契約終了時にDNSを消す条件も記録します。

引き継ぎでは、CNAMEの先を誰が管理しているか、障害時にどの管理画面を見るか、関連語としてDNS、FQDN、Aレコード、TTL、CDNを残すと追いやすくなります。

• CNAME先の所有者と管理画面を記録する。
• サービス解約時の削除条件を残す。
• チェーン全体の回答を時刻付きで保存する。

関連語

同じ主要カテゴリの用語

DNS・名前解決の学習順

同じ主要カテゴリの用語をまとめて確認できます。現在の用語を起点に、前後の用語へ進むと文脈を保ったまま読み進められます。

InfraEngKit内の関連機能