第 4 章

レコード型 — A / AAAA / CNAME / MX / TXT / NS / SOA

レコード型を暗記ではなく「どの問いに答えるデータか」で整理し、CNAME と MX の落とし穴を押さえる。

型は暗記しない。「どの問いに答えるか」で覚える

第 3 章までで「名前 + 型」の問いが権威サーバまで届く流れを追いました。この章では、その型のバリエーションを見ていきます。

DNS のレコード型は数十種類ありますが、暗記は不要です。日常の運用で登場するのは 7 つ前後で、しかもそれぞれが明確に異なる問いに答えるデータだからです。「A とは何か」ではなく「IPv4 の行き先を知りたいときに引くのが A」— この向きで覚えると、管理画面でも zone file でも迷いません。

型	答える問い	典型用途	ひとこと
A	この名前の IPv4 は？	Web / API / LB の向き先	最も基本の行き先
AAAA	この名前の IPv6 は？	IPv6 対応	A と並んで置かれることが多い
CNAME	この名前の本名は？	SaaS 接続、LB の別名	同じ名前に他のレコードを同居させない
MX	この名前宛てメールの配送先ホストは？	メール受信	値は IP ではなくホスト名
TXT	この名前に紐づく文字列は？	SPF、所有確認トークン	意味の解釈はアプリ側の仕事
NS	このゾーンは誰が配る？	委任、権威サーバの指定	第 2 章の zone cut を支える型
SOA	このゾーンの管理情報は？	serial、各種タイマー	ゾーンの開始点。第 5 章で再登場

型名そのものより「どんな問いに答えるか」。この視点があれば、初見の型（SRV、CAA など）に出会っても同じ読み方が通用します。

小問 4-1 — 基本の型を用途から逆引きする

「この情報が欲しいときは、どの型を引くか」。用途 → 型の向きで確認します。

Q17. api.example.com の IPv6 アドレスを知りたいとき、引くべき型はどれですか。

A AAAA MX TXT

Q18. ドメイン所有確認のトークンや SPF の設定文字列を載せる先として、最もよく使われる型はどれですか。

NS SOA TXT CNAME

zone file を 1 本、通しで読んでみる

クラウド DNS の管理画面がどれだけ洗練されていても、その裏で表現されているのは結局これです。1 ゾーン分を通しで読めるようになっておくと、UI が変わっても揺らぎません。

$ORIGIN example.com.
@       3600 IN SOA ns1.example.com. hostmaster.example.com. (
                2026041801 3600 600 1209600 300 )
        3600 IN NS    ns1.example.com.
        3600 IN NS    ns2.example.com.
www      300 IN A     203.0.113.10
www      300 IN AAAA  2001:db8::10
api      300 IN CNAME service.vendor.net.
@       3600 IN MX    10 mail.example.com.
mail     300 IN A     203.0.113.20
txt-demo 300 IN TXT   "verify=abc123"

読み方の要点は 3 つです。

$ORIGIN example.com. — このファイル内の省略名を補う基準です。3 行目以降の www は内部的に www.example.com. として扱われます。
@ — $ORIGIN そのもの、つまりゾーンの apex（ここでは example.com.）を指す記号です。
末尾のドット — ns1.example.com. のように最後にドットがあれば絶対名（FQDN）、なければ $ORIGIN が補われます。末尾ドットを付け忘れると mail.example.com.example.com. のような名前が生まれる — zone file 編集の定番事故です。

内容を読むと: www は本名として A / AAAA を持ち、api は外部ベンダーのホスト名へ CNAME で向いています。apex の MX は配送先として mail.example.com を指名し、その mail には A が置かれています。次の 2 セクションで、この api（CNAME）と MX の 2 か所に潜む落とし穴を見ます。

小問 4-2 — CNAME の意味と同居禁止ルール

CNAME は便利ですが、「別名宣言」という性質からくる制約があります。

Q19. api.example.com CNAME service.vendor.net があるとき、最も正しい説明はどれですか。

api.example.com は IPv4 を 1 つだけ持つ api.example.com は service.vendor.net の別名であり、続きの解決は本名側に委ねられる api.example.com はメール配送先を表す api.example.com は DNSSEC の署名鍵である

Q20. api.example.com に CNAME を置いたとき、標準的な DNS のルールで同じ名前に同居させてよいレコードはどれですか。

A だけは同居できる MX だけは同居できる TXT だけは同居できる原則としてどれも同居させない

落とし穴 ① — CNAME は同居できない。だから apex に置けない

CNAME は「この名前は別名です」という名前全体に対する宣言です。同じ名前に A や TXT が同居していたら、「別名だと言いつつ自分のデータも持っている」ことになり、どちらを信じるべきか矛盾します。そのため、CNAME を置いた名前には原則としてほかのレコードを置けません。

この制約は、実務で必ずぶつかる問題を生みます。zone apex（example.com そのもの）を CDN や PaaS のホスト名へ CNAME で向けたいという要望です。しかし第 2 章で見たとおり、apex には SOA と NS が必ず置かれています。同居禁止ルールにより、apex への plain CNAME は成立しません。

そのため各 DNS プロバイダは ALIAS / ANAME / CNAME フラット化といった独自機能を用意し、「apex なのに CNAME のように振る舞う」体験を提供しています。プロバイダの独自機能だと知っていれば、乗り換えや障害調査のときに慌てずに済みます。

小問 4-3 — MX の 2 段階解決

「メールが届かない」調査の第一歩。MX が返すものを正確に押さえます。

Q21. MX レコードの値として正しいものはどれですか。

配送先メールサーバのホスト名配送先メールサーバの IP アドレス配送先メールサーバの HTTP URL DNSKEY のハッシュ

Q22. example.com MX 10 mail.example.com と mail.example.com A 203.0.113.20 があるとします。メールの配送先 IP に辿り着くまでに、最低いくつの異なる名前（owner 名）を辿りますか。

個

落とし穴 ② — MX は 2 段階。IP に届くまでがメール設定

MX の値は配送先のホスト名であり、IP アドレスではありません。送信側のメールサーバは、①宛先ドメインの MX を引いてホスト名を得る、②そのホスト名の A / AAAA を引いて IP を得る、という 2 段階を必ず踏みます。

調査のコツ: 「メールが届かない」と言われたら、MX → 配送先ホストの A / AAAA の順に 2 段とも確認してください。MX は正しいのに配送先ホストの A が消えている、という片側だけの故障がよくあります。片側ずつ確かめれば、切り分けは 2 手で終わります。

この章で持ち帰ること

レコード型は「どの問いに答えるか」の向きで覚える。用途 → 型と逆引きできれば十分
CNAME は別名宣言。同じ名前に他レコードを同居させられず、ゆえに apex には置けない
MX はホスト名を返す。配送先 IP までは MX → A / AAAA の 2 段階

ここまでで「誰が・何を」は揃いました。次章は最後のピース、「いつまで有効か」= TTL です。