CNAMEとAレコード：使い分けとApexの制約

AレコードとCNAMEが実際にしていること

どちらのレコードも同じ問い——この名前はどこを指すのか——に答えますが、答えに使う情報の種類が違います。そしてこの一点の違いが、以降のすべての規則を説明します。

Aレコードは名前をIPv4アドレスへ直接結び付けます。example.com → 203.0.113.10。ここで連鎖は終わりです。リゾルバーは必要なものを得て、それ以上たどりません。（IPv6版はAAAAレコードで、本記事の内容はそのまま当てはまります。）

CNAMEレコードは名前を別の名前へ結び付けます。www.example.com → example.com、あるいはshop.example.com → myshop.myprovider.net。リゾルバーが受け取るのはアドレスではなく、これから引き直すべき2つ目の名前です。CNAMEは「canonical name（正式名）」の略で、このレコードは文として読むのがいちばん分かりやすい。これの本当の名前はあちらだ、そちらを尋ねてくれというわけです。

この付け替えこそが狙いです。指している先がいつかIPアドレスを変えても、CNAMEなら何も触らずに動き続けます。アドレスを書き留めていないからです。

本当に効いてくる違い

実務上、選択は1つの問いに収まります。そのアドレスは誰のものか。

• 自分のもの——サーバー、VPS、自分が管理する固定IPのロードバランサー。Aレコードを使います。アドレスは分かっていて、知らないうちに変わることはなく、直接の答えがいちばん速い。
• 他人のもの——ホスティング、CDN、ショップ構築サービス、フォームやステータスページのサービス。CNAMEを使います。相手のアドレスは変わります。しかも多くは黙って、予告なく。CNAMEにしておけば、相手の変更があなたの障害にはなりません。

どのプラットフォームの設定ページもIPではなくCNAMEの作成を求めるのはこのためです。慣習ではなく、引っ越す権利を留保しているのです。相手の現在のIPをAレコードに固定した時点で、あなたは黙って相手のメンテナンス対象から外れています。

もう1つ構造上の違いがあり、ここでつまずく人が多い。CNAMEを持つ名前は、ほかのレコードを一切持てません。規格が明示しています。www.example.comがCNAMEなら、同じ名前にTXTもMXもAも置けません。多くのプロバイダーは2つ目のレコードの保存を拒みますが、受け付けたうえで予測できない挙動をするものもあります——午後をつぶす、きわめて不快な過ごし方です。

なぜApexはCNAMEにできないのか

Apex——ルート、ゾーンApex、ネイキッドドメインとも呼ばれます——は、前に何も付かないexample.comです。そしてゾーンの中で唯一、CNAMEにできない名前です。プロバイダーが勝手に設けた制限ではなく、上の規則から導かれます。

Apexには、ドメインが動くために存在しなければならないレコードがすでに載っています。権威ネームサーバーを示すNSレコードと、ゾーンを記述するSOAレコードです。これらは定義上Apexに置かれます。CNAMEは同じ名前の上にほかのレコードを許さず、ApexはNSとSOAを持つことを要求される。したがってApexのCNAMEは矛盾です。規格に従うDNSサーバーは、それを返しません。

ここには、最悪のタイミングで気づくことになる実務的な帰結があります。MXレコードもApexに置かれます。もしどこかのプロバイダーがApexにCNAMEを押し込ませてくれたなら、あなたはWebサイトの向き先を変えただけではなく、メールを未定義の状態に置いたのです。その名前は「正式名は別の場所にある」と主張しながら、同時にMXの問い合わせにも答えなければならないからです。

ではApexには何を置くか

実用になる答えは4つあり、おおむね優先すべき順に並べます。

プロバイダーのaliasレコードを使う

最近のDNSプロバイダーはたいてい、CNAMEのように振る舞いながらApexでも使えるレコード型を用意しています。ALIAS、ANAME、CloudflareのCNAMEフラット化。名前は違っても仕組みは同じで、ネームサーバー自身が宛先を解決し、得られたAレコードで問い合わせに答えます。外から見えるのはごく普通のAレコードなので規格に触れず、しかもあなたはIPを書き留めていません。

プロバイダーが提供しているなら、これが正解です。難点は、これがDNSの機能ではなくプロバイダーの機能だということ。対応していない先へゾーンを移すと、このレコードは付いてきません。

Apexをwwwへリダイレクトする

本体のサイトをCNAMEでwwwに置き——これは完全に正当です——Apexはそこへのリダイレクトにします。多くのレジストラーとすべてのCDNが、ドメイン転送やリダイレクト規則という名前で1行の設定として提供しています。肝心なところに素直なCNAMEが置け、正規のホスト名が1つに決まるので、SEOの観点でも望ましい形です。

代償は見た目だけ。表示されるURLにwww.が入ることで、これについては強い好みを持つ人がいます。

承知のうえでAレコードを使う

プラットフォームが固定IPアドレスを公表し、文書で約束しているなら、ApexのAレコードで構いません。効いている言葉は「約束している」です。相手のCNAME先にpingを打って見つけたIPは約束ではなく、その時点のスナップショットであり、必ず変わります。

この道を選ぶなら、計画した移行の前にレコードのTTLを下げておきましょう。実際にアドレスが動いたとき、キャッシュ待ちで足止めされずに済みます。

いま何が入っているかを確かめる

何かを変える前に、管理画面の要約を信じるのではなく、ゾーンの実際の状態を見ます。Apexとwwwを別々に問い合わせて比べてください。見たいのは、それぞれがAレコードで答えるのかCNAMEで答えるのか、そして想定外のものがすでに入っていないか、です。無料のDNSルックアップツールなら、それぞれのレコード種別・値・残りTTLが分かります。

CNAMEが正しい選択になる場面

宛先が自分の管理外の名前であれば、CNAMEを選びます。

• プラットフォームを指すサブドメイン——shop、docs、status、blog、helpをホスティングサービスへ。正しい用途として最も多いのがこれです。
• オリジンの前に置くCDN。CDNがd1234.cloudfront.netのようなホスト名を渡してくる場合です。
• ドメイン確認やサービス用のレコード。ベンダーがCNAMEでの作成を求めるもので、長いランダムなラベルが付くことが多い。
• wwwをApexに追随させる。1か所の変更で両方が更新されます。

4つのいずれでも値打ちは同じです。ベンダーが基盤を変えても、あなたのDNSは手を触れないまま動き続けます。

Aレコードが正しい選択になる場面

アドレスが自分のものなら、Aレコードが正解です。

• 固定IPの自前サーバーやVPS。
• Apex。aliasレコードが使えず、プラットフォームが安定したIPを公表している場合。
• ロードバランサー。プロバイダーがホスト名ではなくアドレスで渡してくる場合です。
• 基盤側のホスト——たとえばMXレコードに書かれるメールサーバーは、AまたはAAAAで解決できなければなりません。MXレコードはCNAMEを指してはならず、メールサーバーはそれを拒みます。

最後の点はメール移行でつまずきがちです。CNAMEにしたmail.example.comは一見無害で、しかも診断が面倒な形で配送を壊します。

増える1回の問い合わせと、2つ目のTTL

CNAMEは1手増えます。リゾルバーがあなたの名前を尋ね、「この別の名前を尋ねよ」と返され、もう一度尋ねる。実際にはこの往復は数ミリ秒で、ほぼ常にキャッシュから返るので、CNAMEを避ける理由にはなりません。ただし知っておくべき帰結が2つあります。

1つ目。CNAMEが別のCNAMEを指し、それがさらに別のCNAMEを指す連鎖は、そのたびに1手増えます。2段なら普通ですが、長い連鎖は遅延の問題であり、脆い依存です。どこか1つが壊れれば、あなたの名前は落ちます。

2つ目。CNAMEは2つ目のTTLを連れてきます。リゾルバーはあなたのCNAMEをあなたのTTLでキャッシュし、宛先のレコードを宛先のTTLで別にキャッシュして、それぞれ独立に減っていきます。何かを変えたときの実際の待ち時間は長い方です。だからTTLの長いプロバイダーを指すCNAMEは、あなたがどれだけTTLを下げても自分の設定より遅れることがあります。変更を計画しているなら、TTLと反映の実際の仕組みに無停止で進める手順があります。

よくある失敗

• プロバイダーの画面が許したからApexにCNAMEを押し込む。MXレコード——つまりメール——を未定義の挙動に置くことになります。
• すでにCNAMEがある名前にTXTやMXを足す。規格違反で、しかもどう失敗するかはプロバイダーによって違います。
• 求められたCNAMEの代わりに、プラットフォームの現在のIPをAレコードへ写す。動かなくなる日まで動きますし、知らせは来ません。
• MXレコードをCNAMEに向ける。受信側のメールサーバーが拒みます。Aレコードを持つ名前を使ってください。
• wwwを設定してApexを忘れる、またはその逆。どちらを正規にするか決め、他方をそこへ向け、証明書は両方を覆うようにします。
• 先にTTLを下げず、レコードの種別と値を同時に変える。そのうえで、なぜ世界の半分がまだ古い宛先を見ているのかと悩むことになります。

まとめ

IPアドレスが自分のものならAレコード、他人のホスト名を指していて相手の基盤変更を見えないままにしたいならCNAME。ApexはNSとSOAを持たねばならず、CNAMEは同じ名前に同居を許さないので、ApexをCNAMEにはできません。そこではプロバイダーのALIAS・ANAME・CNAMEフラット化を使うか、Apexをwwwへリダイレクトするか、プラットフォームが安定したアドレスを公表している場合にかぎりAレコードを使います。いまドメインが何に解決するのか、レコード種別と残りTTLまで含めて無料のDNSルックアップツールで確認し、新しいホストの証明書はSSL証明書チェッカーで確かめてください。

関連ツールとガイド：

• DNS検索 — A、AAAA、MX、TXT、NS などの DNS レコードを値と TTL 付きで照会、さらに逆引き DNS も。
• SSL証明書チェッカー — 任意のドメインの SSL 証明書、発行者、有効期限、残り日数を確認。
• DNS変更に時間がかかる理由：TTLと反映のしくみ — DNS変更は遅いのではなく、キャッシュされています

よくある質問