DNS レコード選び方：A・AAAA・CNAME・ALIAS・TXT・MX の使い分けと apex CNAME 問題

2026年5月3日約11分

ドメインを運用していると「ルートドメインを CDN に向けたい」「サブドメインを別サービスに飛ばしたい」「メールサーバを設定したい」など、DNS レコードを書く場面が頻繁に出てきます。型の選択を誤ると DNS が壊れる、メールが届かない、CDN が機能しないため、本記事では実用的な選定ガイドと、特にapex CNAME 問題として知られる罠の回避策を整理します。

基本 6 種類

レコード	役割	値の例
A	ドメイン → IPv4	`203.0.113.42`
AAAA	ドメイン → IPv6	`2001:db8::1`
CNAME	ドメイン → 別ドメイン	`target.example.net.`
TXT	ドメイン → 任意文字列	`"v=spf1 include:..."`
MX	メールサーバの指定	`10 mail.example.com.`
SRV	サービスのホスト/ポート指定	`0 5 5060 sip.example.com.`

これに加えて、後述する ALIAS / ANAME（プロバイダ独自）、NS（権威 DNS の指定）、CAA（証明書発行制限）などがあります。

A vs AAAA：IPv4 と IPv6

example.com を IP アドレスに解決させる最も基本的なレコード。

example.com.   IN  A     203.0.113.42
example.com.   IN  AAAA  2001:db8::1

両方設定しておくのが現代のベストプラクティス。Google Public DNS / Cloudflare DNS のような IPv6 対応リゾルバはまず AAAA を試し、無ければ A にフォールバックします。

Happy Eyeballs

ブラウザは Happy Eyeballs（RFC 8305）アルゴリズムで、AAAA と A の両方に同時接続を試み、先に接続できたほうを使う仕組みを持ちます。IPv6 経路が壊れていてもユーザーには影響しない設計。

ただし、サーバ側でAAAA の経路だけ動作不安定だとユーザーが断続的に遅さを感じます。両方設定するなら両方の経路を確実に動かすこと。

CNAME：別ドメインへの参照

www.example.com.  IN  CNAME  example.com.

www.example.com を example.com の別名として扱う。リゾルバは CNAME を見つけたら、ターゲット側のレコード（A / AAAA）を再帰的に解決します。

CNAME の典型用途：

www.example.com → example.com （冗長な www の解決）
app.example.com → cname.vercel-dns.com.（CDN・ホスティングサービスへの委譲）
assets.example.com → s3-website.amazonaws.com.（AWS S3 静的ホスティング）

CNAME の制約

CNAME を置いた名前には他のレコードを置けません：

foo.example.com.  IN  CNAME  bar.example.net.
foo.example.com.  IN  TXT    "info"   ← ✗ 同じ名前に CNAME と他のレコードは共存不可

これが RFC 1034 §3.6.2 で定義された制約。CNAME を使うと、そのサブドメインは完全に他に委ねることになります。

apex CNAME 問題

最も頻繁に踏む罠。ルートドメイン（apex / zone apex）に CNAME を設定できない：

example.com.   IN  CNAME  cname.vercel-dns.com.   ← ✗ RFC 違反

理由：apex には NS レコード（権威 DNS の指定）と SOA レコード（zone の管理情報）が必須で、CNAME と他のレコードの共存禁止に違反する。

「CNAME OK」「CNAME 不可」のサイト一覧：

場所	CNAME 可否
`www.example.com`	✓
`api.example.com`	✓
`example.com`（apex）	✗
`*.example.com`（wildcard）	✓

回避策 1：A レコードで IP 直指定

サービスが提供する IP を A レコードで指定：

example.com.   IN  A  76.76.21.21

問題：CDN サービスは IP が変わる可能性があり、IP 直書きは推奨されない。Vercel・Netlify・Cloudflare Pages などは固定 IP を提供しますが、変更リスクが残る。

回避策 2：ALIAS / ANAME / Flattening

DNS プロバイダが提供する疑似 CNAME：

Cloudflare：CNAME Flattening（apex に CNAME を書ける、内部で A に解決して配信）
Route 53：ALIAS（AWS 内部サービス向けに最適化）
DNSimple / Dynadot：ALIAS / ANAME（汎用）
Vercel：apex に対しては A 76.76.21.21 を推奨（独自 IP を持っている）

example.com.   IN  ALIAS  cname.vercel-dns.com.   ← プロバイダ独自記法

ALIAS はDNS プロバイダ側で動的に CNAME 解決して A レコードとして応答する仕組み。標準仕様ではないので、移行時に他プロバイダの ALIAS への書き換えが必要。

回避策 3：apex リダイレクト

apex を CDN にせず、www.example.com だけを CDN に向け、apex は HTTP リダイレクトで www.example.com に飛ばす。古い手法だが今も使われる。

example.com.       IN  A      203.0.113.42      ← 単純な HTTP リダイレクトサーバ
www.example.com.   IN  CNAME  cname.vercel-dns.com.

TXT：任意の文字列メタデータ

example.com.   IN  TXT  "v=spf1 include:_spf.google.com ~all"
example.com.   IN  TXT  "google-site-verification=abc..."

主な用途：

用途	形式
SPF（メール送信元認証）	`v=spf1 include:... ~all`
DKIM（メール署名公開鍵）	`v=DKIM1; k=rsa; p=...` （`<selector>._domainkey.` サブドメイン）
DMARC（メール認証ポリシー）	`v=DMARC1; p=reject;` （`_dmarc.` サブドメイン）
ドメイン所有確認	`google-site-verification=...`、`stripe-verification=...`
Let’s Encrypt DNS-01 認証	`_acme-challenge.example.com` の TXT

TXT レコードは複数設定可能。1 つの値の長さは 255 文字制限があるが、複数の文字列を空白区切りで連結できる：

example.com.   IN  TXT  "first-part" "second-part"

MX：メール配信先

example.com.   IN  MX  10  mail.example.com.
example.com.   IN  MX  20  backup.example.com.

MX の 10・20 は優先度（priority）で、小さいほど優先。複数 MX があるとき、まず 10 のサーバを試し、失敗したら 20。

メール運用に必須。Google Workspace なら 1 ASPMX.L.GOOGLE.COM.、Microsoft 365 なら 0 example-com.mail.protection.outlook.com.。

SRV：サービス検出

_sip._tcp.example.com.  IN  SRV  0 5 5060 sip.example.com.

_<service>._<protocol> の名前で、サービスのホストとポートを動的に発見する仕組み。Microsoft Active Directory、SIP、XMPP（Jabber）などで使われる。

Web サービスでの登場頻度は低い。

設計時の選定フロー

新しいレコードを書くとき：

メールが必要？ → MX を最初に。
静的サイト・CDN を apex に置く？ → ALIAS（プロバイダ独自）、または www 経由＋apex リダイレクト。
サブドメインを外部サービスに委ねる？ → CNAME。
ドメイン所有確認・SPF・DMARC を設定？ → TXT。
IPv6 対応する？ → A と AAAA を両方。
証明書発行を制限したい？ → CAA レコード。

TTL の選び方

TTL（Time To Live）はリゾルバがレコードをキャッシュする秒数：

用途	推奨 TTL
安定したレコード（A / AAAA / NS）	86400（1 日）〜 604800（1 週間）
ロードバランサ向け、変更予定あり	60-300 秒
移行期間中・実験	60 秒

TTL を短くしてから変更する慣習：移行の 1 日以上前に TTL を 60 秒に下げ、変更を反映、その後 TTL を戻す。これでキャッシュ伝播の時間を短くできます。

落とし穴

1. CNAME チェーンが深い

a.example.com → b.example.net → c.example.org → 203.0.113.42

各リゾルバは再帰解決するので、深すぎる CNAME チェーンは遅延を生み、タイムアウトのリスクもあります。CNAME のホップは 3 段までを目安。

2. NS レコードと CNAME の混同

サブドメインを別の DNS で管理させたい場合は NS レコード（DNS 委譲）であって CNAME ではない：

sub.example.com.  IN  NS   ns1.other-provider.com.
sub.example.com.  IN  NS   ns2.other-provider.com.

CNAME は「ドメイン → 別ドメイン」、NS は「このサブドメインの権威 DNS は別」。違いを理解せず CNAME で代用すると、サブドメイン以下の細かい設定ができなくなります。

3. キャッシュ NXDOMAIN

存在しないレコードへのリクエストは「NXDOMAIN」として否定キャッシュされます。ドメイン作成後すぐにテストすると、リゾルバが「無い」とキャッシュしている可能性。

新規ドメイン作成後は dig +trace example.com で権威 DNS から直接確認するのが確実です。

まとめ

DNS レコードは A / AAAA / CNAME / TXT / MX が日常 95% を占め、apex CNAME 問題と TTL 設計の 2 つを把握すれば実用上のトラブルはほぼ回避できます。ALIAS / ANAME はプロバイダ独自なのでロックインに注意。新規プロジェクトでは IPv6（AAAA）と CAA レコードも忘れずに設定すると、現代的な DNS 運用になります。

IP アドレスの形式・範囲確認は IP アドレスツールで確認できます。