CNAME レコード
概要
CNAME レコード（Canonical Name Record） は、ドメイン名を別のドメイン名にエイリアスする DNS レコードです。RFC 1035 で定義されており、www.example.com を example.com に向けたり、独自ドメインを CDN のエンドポイントに向けたりする用途で使われます。CNAME の解決先は IP アドレスではなく別のドメイン名（正規名）であるため、エイリアス先の IP アドレスが変わっても CNAME レコード自体を更新する必要がありません。
CNAME には DNS 仕様上の重要な制約が 2 つあります。1 つは、CNAME が設定されたドメインには他のレコードタイプを同時に設定できないこと。もう 1 つは、ゾーンの頂点（Apex ドメイン）には CNAME を設定できないことです。これらの制約を理解せずに使うと、ゾーン設定のエラーやメール配送の障害につながります。
仕組み
CNAME はドメイン名を別のドメイン名にエイリアスしますが、他レコードとの共存禁止や Apex ドメインでの使用制限など DNS 仕様上の制約があります。
レコードの構造
CNAME レコードは次のフィールドで構成されます。
www.example.com. 3600 IN CNAME example.com.| フィールド | 例 | 説明 |
|---|---|---|
| NAME | www.example.com. | エイリアスとなるドメイン名 |
| TTL | 3600 | キャッシュ保持時間（秒） |
| CLASS | IN | インターネットクラス |
| TYPE | CNAME | レコードタイプ |
| RDATA | example.com. | エイリアス先の正規名（Canonical Name） |
CNAME の解決フロー
DNS クライアントが www.example.com を問い合わせると、権威ネームサーバーは CNAME レコードとして example.com を返します。クライアントはその正規名（example.com）に対してさらに問い合わせを行い、最終的に A レコードや AAAA レコードを取得します。
www.example.com. IN CNAME example.com.
example.com. IN A 93.184.216.34この場合、www.example.com を解決するには 2 回の DNS ルックアップが発生します。CNAME チェーンが深くなるほどルックアップ回数が増えるため、不必要に長い CNAME チェーンは避けるべきです。
CNAME と他レコードの共存禁止
RFC 1034 は、CNAME が設定されたドメインに他のレコードタイプを設定することを禁じています。たとえば www.example.com に CNAME と A レコードを同時に設定することはできません。これは CNAME の意味論的な整合性を保つためのルールです。
この制約が問題になるのが MX レコードとの組み合わせです。mail.example.com に CNAME を設定してから MX レコードで mail.example.com を指定するような構成は動作しません。RFC 2821 はメール配送先として CNAME を使うことを明示的に禁じています。
Apex ドメインに CNAME を設定できない理由
example.com（ゾーンの頂点）には SOA レコードと NS レコードが必ず存在します。CNAME と他のレコードの共存禁止ルールにより、Apex ドメインには CNAME を設定できません。Apex ドメインをロードバランサーや CDN のエンドポイントに向けたい場合は、後述する CNAME Flattening を利用します。
CNAME Flattening
CNAME Flattening は、DNS プロバイダーが Apex ドメインでも CNAME のような動作を実現する独自拡張機能です。Cloudflare、AWS Route 53（ALIAS レコード）、NS1 などの主要プロバイダーが実装しています。
内部的には、プロバイダーの権威ネームサーバーが CNAME を再帰的に解決し、最終的な IP アドレスを A レコードとしてクライアントに返します。クライアントからは通常の A レコードとして見えるため、DNS プロトコルの制約を回避できます。ただし、これは DNS プロトコルの正式仕様ではなく、各プロバイダー固有の実装です。
設定例
www サブドメイン、CDN、GitHub Pages への CNAME 設定パターンを示します。
www サブドメインのエイリアス
www.example.com. IN CNAME example.com.CDN エンドポイントへの向け先
AWS CloudFront や Cloudflare で独自ドメインを使う場合の典型的な設定です。
static.example.com. IN CNAME d1234abcd.cloudfront.net.IP アドレスを管理せず、CDN 側でのルーティングに委ねることができます。
GitHub Pages への向け先
www.example.com. IN CNAME username.github.io.CNAME チェーンの例（非推奨）
alias.example.com. IN CNAME www.example.com.
www.example.com. IN CNAME example.com.
example.com. IN A 93.184.216.34この構成では alias.example.com の解決に 3 回の DNS ルックアップが必要です。不要なチェーンは解決を遅くするだけなので、直接最終ターゲットを指すようにしてください。
確認方法
dig で CNAME レコードを確認するには次のコマンドを使います。
dig CNAME www.example.comCNAME が設定されている場合、ANSWER SECTION に次のように表示されます。
;; ANSWER SECTION:
www.example.com. 3600 IN CNAME example.com.CNAME チェーンの全体を一度に確認したい場合は +trace オプションを使います。
dig +trace www.example.com外部の視点からも確認したい場合は、Labee Dev Toolbox の DNS API を使うと、外部の視点から見た結果を取得できます。
curl "https://labee.dev/api/dns?domain=www.example.com&type=CNAME"{
"success": true,
"data": {
"domain": "www.example.com",
"records": {
"CNAME": ["example.com"]
}
},
"error": null,
"meta": { "responseTime": 38 }
}レスポンスの records.CNAME にターゲットドメイン名が文字列の配列で返ります。dig の結果と Labee API の結果が異なる場合は、リゾルバー側のキャッシュが原因です。TTL が切れるまで待つか、dig +time=1 +tries=1 で別のネームサー��ーに問い合わせて比較してください。
よくある問題
CNAME の DNS 仕様上の制約を理解せずに設定すると、ゾーンエラーやメール配送の障害につながります。
Apex ドメインに CNAME を設定しようとしてエラーになる
ほとんどの DNS プロバイダーの管理画面では、Apex ドメインに CNAME を設定しようとするとバリデーションエラーになります。エラーメッセージは「zone apex CNAME is not allowed」のような文言です。Cloudflare や Route 53 の ALIAS/Flattening 機能を使うか、ロードバランサーに直接 A レコードで向けてください。
MX レコードと CNAME を同じドメインに設定してしまった
メールサーバーのホスト名として使うドメインに CNAME を設定すると、RFC 2821 の制約によりメール配送が失敗します。mail.example.com を使うなら、そこには A レコードを設定し、MX レコードで直接指定してください。
CNAME を設定したのに反映されない
CNAME の TTL が長い場合（86400 秒など）、変更が伝播するまでに最大 24 時間かかります。TTL を事前に 300 秒に下げてから変更するのが標準的な対処です。また、プロバイダーの管理画面でドット（.）で終わる FQDN を入力するかどうかの書式ルールを確認してください（末尾のドットを省略して内部的に補完するプロバイダーがあります）。
CNAME Flattening に頼った構成でプロバイダーを移行する際の注意
CNAME Flattening は各プロバイダー独自の機能であるため、プロバイダー移行時に同等の機能があるかどうか確認する必要があります。Apex ドメインに Flattening を使っている場合、移行先プロバイダーがサポートしていなければ A レコードに変更するか、別のプロバイダーを選ぶ必要があります。