- ブラウザURL入力
- DNS名前→IP今ここ
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口
- アプリ処理
- DB保存
前回、CNAME だけが「他と同居できない」特別な種別であることを見ました。今回はその排他性が、頂点でどんな衝突を起こすかを見ます。
まず結論
ゾーンの頂点には SOA と NS が必ず置かれます。RFC 2181 §6.1 は、その2つを「すべてのゾーンにおける必須のレコード」と呼んでいます。一方 CNAME は他のデータと同じ名前に並べません。この2つが同時に成り立たないので、頂点に CNAME は置けません。
宛先は名前でしか指せないため、この衝突は構造的に残ります。そこを埋めているのが各事業者の独自機能です。IANA のレコード種別レジストリに ALIAS も ANAME も登録されていません。
`example.com` そのもの(頂点)を、CDN が指定した名前へ向けたい。CNAME を1行置けば済むでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
頂点は、必ず何かを持っている場所
前回『レコードは名前と値の1行 — 種別が決めるのは値の読み方』で、CNAME だけが他と同居できない特別な型であることを見ました。その排他性は置く場所を選ばないので、「必ず何かが置かれている名前」では衝突します。ゾーンの頂点が、まさにその名前です。RFC 2181 §6.1 はこう書いています。
The authoritative servers for a zone are enumerated in the NS records for the origin of the zone, which, along with a Start of Authority (SOA) record are the mandatory records in every zone.
origin の NS レコードと SOA レコードは、すべてのゾーンにおける必須のレコードである、と。ゾーンとして存在する以上、頂点は必ず SOA と NS を持っています。
用語についてひとつ。ここで「頂点」と呼んでいるものを、RFC 2181 §6 は origin と呼んでいます。
The domain name that appears at the top of a zone (just below the cut that separates the zone from its parent) is called the zone's "origin".
apex や naked domain も広く通じますが、規格の側の語は origin です。
同じ1行が、www では動き、頂点では置けない
実測です(macOS 26.5.2 / DiG 9.10.6 / 2026-09-17 JST)。
www.github.com. 2559 IN CNAME github.com.github.com. 60 IN A 20.27.177.113github.com. 60 IN A 20.27.177.113
www.github.com には CNAME が置かれ、その先の A まで一緒に返っています。一方 github.com(頂点)には CNAME を経由せず A が直接あります。
同じ「別名を置く」操作なのに、片方は成立し、片方は形にすらなりません。深さの規則があるのではなく、頂点には SOA と NS が既に居るという一点が違います。もうひとつ、CNAME の性質を見ておきます。
www.github.com. 3340 IN CNAME github.com.github.com. 300 IN MX 0 github-com.mail.protection.outlook.com.
MX を尋ねたのに、CNAME が返り、その先の名前の MX が返っています。CNAME は問い合わせの型を選びません。RFC 1034 §3.6.2 の「CNAME を見つけたら転送先の名前で問い合わせをやり直す」が型を問わず働くためです。
頂点の話に戻ります。もし頂点に CNAME を置けたとすると、そこへの SOA の問い合わせも NS の問い合わせも転送先へ向くことになります。ゾーンが自分の権威情報を返せなくなります。
頂点に SOA と NS が必ずあることを規定しているのは、どの文書のどこですか。
規格の側は、不可能だと認めている
CNAME の排他性は、RFC 2181 §10.1 が任意の名前について成り立つ4つの状態として規定しています。
An alias name (label of a CNAME record) may, if DNSSEC is in use, have SIG, NXT, and KEY RRs, but may have no other data.
例外として挙がっているのは SIG・NXT・KEY です。当時の DNSSEC の型名で、現行の RRSIG・NSEC・DNSKEY という語は RFC 2181 の本文にありません。現代の型名へ書き換えて引くと、原文に無い文になります。
肝心なのは、この例外リストに SOA も NS も入っていないことです。頂点に必須の2つが、例外の側にいません。
この制約を、標準化された文書が明示的に認めた箇所があります。RFC 9460(SVCB / HTTPS RR、2023年11月)の Abstract です。
They also enable aliasing of apex domains, which is not possible with CNAME.
「apex ドメインの別名化を可能にする。それは CNAME では不可能である」。不可能である、と規格の側が書いています。
- ・名前の深さは関係しない。3段目でも頂点なら置けず、2段目でも頂点でなければ置ける
標準の側に何が残ったか
頂点を CDN や負荷分散の宛先へ向けたい、という要求は消えません。標準の側でこれに応えようとした文書が draft-ietf-dnsop-aname「Address-specific DNS aliases (ANAME)」です。Abstract はこう書いていました。
This document defines the "ANAME" DNS RR type, to provide similar functionality to CNAME, but only for address queries. Unlike CNAME, an ANAME can coexist with other record types. The ANAME RR allows zone owners to make an apex domain name into an alias in a standards compliant manner.
アドレスの問い合わせに限って CNAME に似た機能を与え、他の種別と共存できるようにする、という提案です。いまどうなっているかを datatracker の API の値で見ます。
項目 値最終版 -04(2019-07-08 公開)state Expiredexpires 2020-01-09intended_std_level Proposed Standardstd_level None
-04 が最後で、2020-01-09 に期限切れとなり、以後更新されていません。 目指していた地位は Proposed Standard でした。「標準化されなかった」と片付けると、どこまで進んでいたかが落ちます。次にレジストリの側を確かめます。
(出力なし、exit 1)7:CNAME,5,the canonical name for an alias,[RFC1035],,
IANA の RR TYPE の機械可読版を、大文字小文字を無視して全文検索した結果です。"aname" は0件。"alias" の唯一の一致は CNAME の説明文中の "the canonical name for an alias" で、型名の登録ではありません。TYPE 欄の完全一致でも0件。登録されている99種のどこにもありません。
つまり頂点で別名相当の動きをする機能は、レコード種別ではなく事業者の権威サーバの機能です。
`www.github.com` は CNAME で `github.com` を指しています。この名前に MX を問い合わせると何が返りますか。
www では動き、頂点では置けない
同じ「CNAME を1行置く」操作が、www では成立し、頂点では形にできません。違いは名前の深さではなく、頂点に SOA と NS が必須で存在することです。実測では www は CNAME、頂点は A が直接返りました。
名前 返った種別 頂点かwww.github.com CNAME いいえgithub.com A はいwww.iana.org CNAME いいえiana.org A はい
標準の側で埋めようとした文書の行方
ANAME は「他の種別と共存できる別名」を定義し、頂点の別名化を標準準拠のやり方で可能にしようとした提案でした。Proposed Standard を目指して -04 まで改訂されましたが、2020-01-09 に期限切れとなりました。
対象 現在の状態draft-ietf-dnsop-aname Expired(-04 が最終、2019-07-08)IANA の ANAME 登録 0件(CSV 全文検索、大小無視)IANA の ALIAS 登録 0件(一致は CNAME の説明文のみ)RFC 9460 の SVCB Standards Track(2023年11月)
同じ「別名」でも、www では動き頂点では置けません。何が違うのでしょうか。そしてその違いは、なぜ事業者ごとの独自機能を生んだのでしょうか。
「その名前に既に何が置かれているか」を両方について挙げてください。頂点についてだけ、答えが空になりません。
この章のまとめ
- 頂点には SOA と NS が必須で存在する。RFC 2181 §6.1 の語は "the mandatory records in every zone"。規格上の呼称は origin(§6)。
- CNAME は他のデータと同居できない(RFC 2181 §10.1)。例外は SIG・NXT・KEY で、SOA も NS も入っていない。だから頂点に CNAME は置けない。
- 判定は名前の深さではなく「この名前に SOA はあるか」の1問。
- CNAME は問い合わせの型を選ばない。頂点に置けば SOA と NS への問い合わせまで巻き込まれる。
draft-ietf-dnsop-anameは -04(2019-07-08)が最終で状態は Expired(2020-01-09 期限切れ)。目指していたのは Proposed Standard。- IANA の RR TYPE レジストリに ALIAS も ANAME も無い。 それは事業者ごとの独自機能である。
- RFC 9460 の Abstract は "which is not possible with CNAME" と書き、SVCB がそれを enable すると述べる。可能にする、までが逐語。
レコード種別の語彙は既存のクイズ群「DNS(名前解決)」の DNS VI(実務トピック)に譲ります。次回は TTL を扱います。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「DNS には ALIAS というレコード種別があり、apex ではそれを使う」——この説明の評価として正確なのはどれですか。
用語集(4語)
- origin(ゾーンの頂点 / apex)
- RFC 2181 §6 は、ゾーンの最上位に現れるドメイン名をそのゾーンの "origin" と呼ぶ。規格上の語は origin で、apex や naked domain は通称。
- 必須のレコード(mandatory records in every zone)
- RFC 2181 §6.1 が、origin の NS と SOA について用いた表現。RFC 1035 §5.2 も「ゾーンの先頭にちょうど1つの SOA RR があるべき」を挙げる。
- CNAME の排他性
- RFC 2181 §10.1 が定める4つの状態の1つ。CNAME が1つある名前は、DNSSEC 使用時の SIG・NXT・KEY を除いて他のデータを持てない。
- ALIAS / ANAME
- IANA の RR TYPE レジストリに登録の無い呼称。事業者が自社の権威サーバへ実装した独自機能の名前。DNS のレコード種別ではない。既存のクイズ群の「ALIAS レコード」は慣用の呼称で、動作の説明は本レッスンと矛盾しない。