DNSレコードの基礎 — A/CNAME/TXTレコードは何を指しているか

「ドメインを設定する」という作業は、多くの場合「DNSレコードを追加する」作業に等しい。サブドメインを作る、メールの到達性を上げる、外部サービスの所有権を証明する——目的は様々でも、実際にやることはドメイン管理パネルでレコードを1行追加することが多い。今回はDNSレコードの中でも特に頻出する A・CNAME・TXT の3種類が、それぞれ何を「指している」のかを整理した上で、自社ドメインで実際に使っている実例を見ていく。

DNSが解決しているもの

ブラウザに wpmm.jp と入力してからページが表示されるまでの間には、「この人間が読める名前は、実際にはどのサーバーのIPアドレスなのか」という問い合わせが挟まっている。DNS（Domain Name System）はこの問い合わせに答える分散データベースで、ドメインごとに「レコード」という単位で情報を管理している。レコードには複数の種類（タイプ）があり、タイプごとに答える内容が異なる。ここではよく使う3種類に絞って見ていく。

Aレコード — ホスト名をIPv4アドレスに直結する

Aレコードは最も基本的なレコードで、ホスト名（例: wpmm.jp）を特定のIPv4アドレスに直接紐付ける。「このドメインへのアクセスは、このIPアドレスのサーバーへ送ってください」という単純な地図情報だ。Webサーバーを新しく立てて独自ドメインで公開する際、まず設定するのがこのAレコードになる。

CNAMEレコード — ホスト名を別のホスト名に転送する

CNAME（Canonical Name）レコードは、あるホスト名を別のホスト名の別名として扱う。IPアドレスを直接指すのではなく、「このホスト名の実体は、あちらのホスト名と同じです」という間接参照になっている点がAレコードとの違いだ。CNAMEには制約がいくつかある。最も重要なのは、同じホスト名に対してCNAMEと他のレコード（MXやTXTなど）を共存させられないという点で、これはCNAMEが「その名前のすべての問い合わせを丸ごと転送する」仕組みだからだ。また、ドメインの頂点（zone apex、wpmm.jp そのものなど、サブドメインを持たない裸のドメイン）にはCNAMEを置けないという制約もあり、そこにはAレコードを使うのが一般的だ。

TXTレコード — 任意の文字列を持たせる

TXTレコードは、IPアドレスやホスト名ではなく任意のテキスト文字列をドメインに紐付けられるレコードだ。もともとは人間向けの補足情報を書くためのものだったが、現在では機械が読み取る用途がほとんどを占めている。代表的なのが外部サービスのドメイン所有権証明（サービス側が発行したランダムな文字列をTXTに追加することで「このドメインの管理権限を持っている」ことを証明する）と、メール認証関連の設定だ。

実例1: サブドメイン化はAレコードの追加から始まる

自社のENブログを en.wpmm.jp というサブドメインとして立ち上げた際、最初のステップはホスティングパネルでこのサブドメインを作成し、ドキュメントルートを指定することだった。この操作の裏側で行われているのは、en.wpmm.jp という新しいホスト名に対するAレコードの追加（あるいはホスティング側の権威DNSサーバーが暗黙に解決できるようにする設定）であり、この情報が世界中のDNSキャッシュに反映される（俗に「DNS浸透」と呼ばれる）までには一定の時間がかかる。この待機時間の存在は実務上地味に効いてくる部分で、サブドメインを作成した直後にそのサブドメインへWordPressをインストールしようとしても、名前解決がまだ古いキャッシュのままの環境からは接続できないことがある。ドメイン設定を変更した直後の作業では、変更が本当に反映されたかを別経路（dig コマンドや別のDNSリゾルバ経由の確認等）で確かめてから次の作業に進む方が、原因不明のエラーに時間を溶かさずに済む。

実例2: メール到達性はTXTレコードの3点セットで決まる

自社ドメインからの登録確認メールがGmail/Outlook等でうまく届かない問題を調査した際、最終的に効いたのはTXTレコードの追加だった。メール認証には SPF・DKIM・DMARC という3つの仕組みが関わり、いずれもTXTレコードとしてDNSに公開される。SPFは「このドメインからのメールを送ってよいサーバーの一覧」、DKIMは「メール本文に電子署名を付けて改ざんされていないことを証明する仕組み」、DMARCは「SPF/DKIMのどちらか（または両方）に失敗したメールをどう扱うか、その結果をどこに報告するか」を宣言するポリシーだ。自社ドメインではSPF/DKIMは以前から設定済みだったが、DMARCレコードだけが欠落していた。_dmarc.wpmm.jp というホスト名に対して

v=DMARC1; p=none; rua=mailto:info@wpmm.jp

というTXTレコードを追加することで3点セットが揃い、海外の主要メールプロバイダに対する到達性が改善した（p=none は「認証に失敗したメールを拒否も隔離もせず、ただ結果だけ集計レポートとして送ってほしい」という最も緩いポリシーで、いきなり p=reject にせず様子見から始める設計になっている）。SPF・DKIM・DMARCそれぞれの役割分担のより詳しい話は、認証メールが届かない問題の3点セットで扱っているので、興味があればそちらも参照してほしい。

まとめ

Aレコードは「名前をIPアドレスに直結する」、CNAMEレコードは「名前を別の名前に転送する」、TXTレコードは「名前に任意の文字列を持たせる」——3種類が答えている問いはそれぞれ別物だ。実務でつまずきやすいのは、レコードそのものの意味よりも「変更してから反映されるまでにタイムラグがある」という時間軸の存在で、サブドメイン作成やメール認証設定のように複数の作業ステップが絡む場面では、DNSの変更が確実に反映されたことを確認してから次に進む、という一手間が結果的に近道になる。