レコードは名前と値の1行 — 種別が決めるのは値の読み方

第25週で、名前解決がルートから権威へ辿る経路を追いました。今回はその終点で待っている「表の1行」を見ます。

example.com.    270    IN    A    104.20.23.154
   名前         TTL   クラス 種別   値

種別(TYPE)が決めているのは、いちばん右の値をどう読むかだけです。A なら4バイトのIPv4アドレス、AAAA なら16バイトのIPv6アドレスとして読む。種別は値に付いたラベルであって、他の行について何も言っていません。だからAとAAAAは、読み方が違う2つの値が並んでいるだけで、競合のしようがありません。

もうひとつ。同じ名前・同じ種別のレコードは、1つの集合(RRSet)として扱われます。 RFC 2181 §5.2 は、集合の中でTTLが異なることを deprecated とし、こう規定しています。

the TTLs of all RRs in an RRSet must be the same

DNSが受け渡しする最小の単位は1行ではなく、この集合です。

ここで例外が出てきます。RFC 1034 §3.6.2 の逐語です。

If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different. This rule also insures that a cached CNAME can be used without checking with an authoritative server for other RR types.

CNAMEがあるノードには、他のデータを置くべきでない。理由が2つ書かれています。正規名と別名でデータが食い違わないこと、そしてキャッシュしたCNAMEを、他の型について権威へ確認せずに使えることです。

現行の規定は RFC 2181 §10.1 にあります。

状態                                          備考
CNAMEが1つある(SIG/NXT/KEY を伴ってよい)   他のデータは持てない
CNAME以外のレコードが1つ以上ある            種別は何種類あってもよい
名前は存在するが、レコードが無い            第25週の NODATA
名前自体が存在しない                        第25週の NXDOMAIN

例外として挙がる SIG / NXT / KEY は、RFC 2181 が書かれた当時のDNSSECの型名で、現行の RRSIG / NSEC / DNSKEY ではありません。

では、なぜCNAMEだけが同居できないのか。CNAMEは値の読み方の指定ではないからです。他の種別が「この値をこう読め」と言うのに対し、CNAMEは「この名前への問い合わせを、あの名前への問い合わせに差し替えろ」と言っています。効く対象が1行ではなくその名前の表そのものです。

差し替えである以上、問い合わせた種別は関係ありません。AでもMXでもTXTでも、まるごと転送先へ向きます。だとすると、同じ名前に他のレコードを置いても誰も読みに来られません。読みに来られない行を許せば、正規名と別名でデータが食い違う余地が生まれます。RFC 1034 の「this ensures that the data ... cannot be different」はこのことです。

なお RFC 2181 §10.1.1 は、CNAMEレコードの左辺を「CNAME」と呼ぶ慣用を「This is unfortunate」「an entrenched usage」と評しています。