Aレコード・CNAME・MX・TXTの違いと使い分け

Aレコード・CNAME・MX・TXTは、いずれもDNSへ登録する情報です。ただし、値の意味はまったく異なります。種類だけを覚える必要はありません。「対象の名前」「返す内容」「キャッシュ時間」を一組で読むと、設定ミスを減らせます。

サーバー会社から値を受け取ったときは、種類だけを見て既存レコードへ上書きしないでください。同じドメインでも、Web・メール・サービス認証は別のレコードで動いています。変更する目的と対象の名前を先に確定します。

レコードは名前・種類・値・TTLを一組で読む

DNS管理画面には、ホスト名・種別・内容・TTLなどの入力欄があります。ホスト名は問い合わせ対象です。種別は値の解釈方法、内容は実際の接続先や文字列を示します。

TTLは回答をキャッシュしてよい時間です。画面によってはホスト名を「名前」、内容を「値」または「データ」と表示します。

ドメイン直下を@で表す画面もありますが、@はDNS上の共通レコード名ではなく、管理画面がルート名を表すための記号です。wwwだけを入力すると自動的にドメイン名が補われる画面もあれば、www.example.jpまで必要な画面もあります。提供元の入力例が完全な名前か、画面が末尾のドメインを補うかを確認してください。

4種類の基本的な対応は次のとおりです。値は説明用であり、実際の設定には契約先が発行した値を使います。

TTLの単位は通常秒ですが、選択式の管理画面もあります。変更前に短くすれば古い回答が残る時間を抑えられます。ただし、すでにキャッシュされた回答は、設定時のTTLが満了するまで残る可能性があります。

Aレコードは名前をIPv4アドレスへ向ける

Aレコードは、ドメイン名をIPv4アドレスへ結び付けます。Webサイトでよく使われますが、Aレコードそのものに「Web専用」という意味はありません。指定した名前への問い合わせに、IPv4アドレスを返すレコードです。IPv6アドレスには別のAAAAレコードを使います。

example.jpとwww.example.jpは別の名前です。ドメイン直下のAレコードを変更しても、wwwが別のAレコードを持っていれば自動では変わりません。反対に、wwwがドメイン直下を参照するCNAMEなら、参照先のAレコード変更が結果へ反映されます。

サーバー移転でAレコードを変更するときは、新サーバーに対象ドメインを設定し、HTTPSとコンテンツを確認してから値を変えます。IPアドレスだけを先に変更すると、サーバーがそのドメインを受け付けず、別サイトやエラーが表示される場合があります。

CNAMEはURL転送ではなく別名を作る

CNAMEは、ある名前を別の正式な名前へ結び付けます。たとえばwww.example.jpをexample.jpの別名として扱う用途です。値に入れるのはホスト名であり、https://example.jp/service/のようなURLやパスではありません。ブラウザのアドレスを別URLへ転送したい場合は、Webサーバー側のリダイレクトを使います。

RFC 1034とRFC 2181では、CNAMEを置いた名前に他種類のデータを共存させないことが示されています。wwwにCNAMEとTXTを同時に置く、といった構成は避けます。DNSSECの署名用レコードなどプロトコル上の例外はありますが、一般の管理画面で利用者が混在させるものではありません。

ドメイン直下にはMXやTXTなども置くため、標準的なCNAMEと両立しません。DNS事業者によってはALIAS・ANAME・CNAME flatteningなどの独自機能があります。標準CNAMEと同じ仕様だとは限りません。利用条件と返されるレコードを公式マニュアルで確認します。

MXは受信メールを渡すサーバーを決める

MXレコードは、独自ドメイン宛のメールをどのサーバーへ配送するかを示します。値には優先度とメールサーバーのホスト名を登録します。RFC 5321では、優先度の数値が小さい配送先を先に扱います。管理画面が優先度を別欄に分けている場合は、値へ重ねて書きません。

MXの配送先へIPアドレスを直接入れることはできません。さらに、配送先のホスト名はCNAMEの別名ではなく、AまたはAAAAでアドレスへ解決できる名前が必要です。複数のMXを指定された場合は、任意に減らさないでください。優先度もサービスの案内どおりに登録します。

MXを変更しても、過去の受信メールやメールソフトの設定は移りません。また、メールの送信元を認証するSPF・DKIM・DMARCも別のレコードです。実際の切り替えでは「MXレコード変更前後に確認するメール停止防止チェックリスト」の順番で、新しい受信箱を先に用意します。

TXTは名前と文字列で用途が決まる

TXTは文字列を保持する汎用レコードです。「TXTを追加する」という指示だけでは、何の設定か判断できません。ドメイン直下のSPFとselector._domainkeyに置くDKIM公開鍵は別用途です。

_dmarcに置くDMARCや外部サービスの所有確認もあります。名前と値の書式を合わせて用途を見分けます。

SPFは、そのドメインを送信元として利用できるサーバーを示します。RFC 7208では、対象となる名前に複数のSPFポリシーが見つかると評価できません。メールサービスを追加するときは、v=spf1で始まるTXTをもう一本作るのではなく、既存の送信経路を確認したうえで一つのポリシーへ反映します。

DKIMは送信メールの署名を検証する公開鍵です。セレクターが異なれば複数のTXTを併用できます。DMARCは_dmarcという別名にポリシーを置き、SPFまたはDKIMの結果とFromドメインの整合を使います。これらは同じTXTでも役割が違うため、複数サービスの値を一つの文字列へ連結しません。

変更前後は権威DNSへ同じ種類を問い合わせる

設定前には、現在の名前・種類・値・TTLを記録します。そのレコードを必要とするサービスも残してください。変更値は検索で見つけた例ではなく、契約中のサーバー会社やメール会社が自社アカウント向けに発行したものを使います。特に認証用TXTは、会社ごとに固有の文字列になる場合があります。

変更後は、見た目だけでなく同じ名前と種類を問い合わせて結果を比較します。たとえばAを変更したならA、MXならMX、SPFなら対象名のTXTを確認します。権威ネームサーバーへ直接問い合わせると、管理画面へ保存した値が公開側で返されているかを切り分けられます。

値が期待どおりでも、利用者側には古いキャッシュが残る場合があります。設定を何度も上書きする前に、権威DNSの回答・TTL・利用者側の回答を分けてください。作業記録へ目的を残しておけば、数カ月後に「用途不明のTXT」として誤って削除されることも防げます。