要約

  • 1999 年の RFC 2672 は、DNAME 所有者と一致する接尾辞を対象接尾辞に置き換え、すべての子孫名を構造的に振り向ける仕組みを導入した。一つの規則で未作成の名前まで扱える。
  • DNAME は所有者自身を振り向けず、委任も作らない。頂点には SOA と NS が残り、委任は親ゾーンのゾーンカットに置かれた NS RRset によって成立する。
  • RFC 6672 は運用上の境界を明文化した。問い合わせごとの CNAME 合成、署名済み DNAME による DNSSEC 検証、子孫データの隠蔽、ワイルドカード DNAME の忌避、ループ制限、長すぎる置換結果への YXDOMAIN である。

一つの名前と一つのゾーンの間

RFC 1034 の DNS には、すでに二種類の誘導があった。CNAME は特定の所有者名を別の正規名への別名とする。ゾーンカットの NS RRset は、子ゾーンの権威サーバーをリゾルバーに知らせる。

前者は一つのノードの名前関係であり、後者は管理境界の変更である。ところが、任意の子孫について左側のラベル列を保ち、共通する右側の接尾辞だけを交換する操作はなかった。

old.example から new.example への移行で www だけに CNAME を置いても、mail や lab.mail、将来の名前は救えない。逆に旧ゾーンを委任し直せば、変える必要のない権威まで変わる。必要だったのは、単一名の別名より広く、委任より意味の狭い書き換え命令だった。

接尾辞を一度だけ記述する

RFC 2672 は 1999 年 8 月、タイプ 39 の DNAME を定義した。問い合わせ名の末尾が DNAME 所有者と完全なラベル単位で一致すると、その部分を対象名に置き換える。

old.example から new.example への DNAME があれば、www.lab.old.example は www.lab.new.example になる。www.lab は維持される。対象ゾーンのデータをコピーするわけではなく、対象の運営権を得るわけでもない。

当初の仕様は、ネットワークの番号変更に伴う逆引き管理や組織改称を動機に挙げた。これらは普及率の証拠ではない。共通する発想は、列挙できない子孫集合を一つの管理規則で扱うことだった。

記述量は減るが、影響範囲は減らない。一行の誤りが部分木全体の探索先を変える。DNAME は作業を圧縮すると同時に、判断を集中させた。

所有者名だけは旧い場所に残る

現行仕様の RFC 6672 が強調するのは、DNAME 所有者自身は置換されないという点だ。子孫だけが対象になる。

したがって www.old.example は新しい接尾辞へ進めるが、old.example そのものは旧い頂点で答えられる。そこには共存可能なデータがあり得る。ゾーン頂点なら SOA と NS も引き続き必要だ。

DNAME がゾーン全体の鏡になれない理由はここにある。組織改称では、旧頂点の MX を別途保持する必要があるかもしれない。Web サーバーや証明書も旧名を受け入れなければならない。DNS が到達経路を作っても、アプリケーションの同一性判断までは変更できない。

この例外は弱点ではない。DNAME が約束するのは子孫名の構造的対応であって、二つのドメインの完全な同一性ではないと示す境界である。

一般規則から CNAME を合成する

DNAME を適用するサーバーは、その DNAME とともに問い合わせ名専用の CNAME を合成する。www.lab.old.example への質問なら、www.lab.new.example への CNAME が回答に入る。ゾーンファイルにその個別行が保存されている必要はない。

DNAME は公開された一般規則、合成 CNAME は一回の問い合わせに対する実行結果である。DNAME を直接扱えないクライアントも、既知の CNAME を追える。再帰キャッシュサーバーもクライアントのために合成を行わなければならない。

TTL は運用経験で改められた。旧仕様では合成 CNAME は TTL 0 だったが、RFC 6672 は DNAME の TTL を使う。旧実装との共存のため、リゾルバーは両方を受け入れる。

かつて想定された EDNS の DNAME 理解シグナルは結局仕様化されなかった。相互運用性は存在しない能力交渉ではなく、通常の DNS 応答と互換的な処理で成立した。

DNSSEC は結果の製造規則を署名する

将来どの子孫名が問い合わせられるかは事前に分からない。ゾーンは無限個の合成 CNAME を先回りして署名できない。そこで DNSSEC は DNAME を署名する。

検証リゾルバーは署名を確認し、自ら接尾辞置換を実行し、未署名 CNAME がその決定的な派生結果であるかを確かめる。証明は「認証済み規則」と「再現可能な計算」の組であり、オンラインで作られた各結果の独立署名ではない。

サーバーが自由に別名を発明できるわけではない。左側ラベルは保たれ、所有者接尾辞はラベル境界で一致し、対象は署名済み DNAME から取られなければならない。

ただし、一つ目の振り向けが正しいことは、終点全体の正しさを意味しない。先には CNAME、別の DNAME、未署名ゾーン、あるいはエラーがあり得る。RFC 6604 は RCODE と状態ビットを連鎖の終端結果として解釈するよう整理した。

別名は委任ではない

RFC 9499 は、DNAME 所有者のサブドメインを alias と定義する。一方、delegation は親ゾーンが子の起点に NS RRset を置き、ゾーンカットで独立ゾーンを作ることだ。

NS referral は、元の名前について誰を権威とみなすかを変える。DNAME は探す名前を変える。その後、置換後の名前が対象側にすでに存在する委任構造をたどる。

このため、頂点以外で委任を示す NS と DNAME は同じ所有者を共有できない。子ゾーンが頂点に DNAME を置くなら、それはカットの下側、子ゾーンの権威データとして SOA・NS と共存する。

源ゾーン運営者は指し先を決める。親子の運営者は源ゾーンの委任を維持する。対象運営者は到達先データを決める。応答が滑らかにつながっても、この三つの権限が一つになるわけではない。

規則の下のデータは見えなくなる

同一ゾーンで DNAME 所有者の下に資源レコードを置いてはならない。サーバーが読み込んでも、探索は先に DNAME に出会い、下位データは occluded、すなわち隠蔽された状態になる。

一行を追加しただけでも、公開上は多数の名前を消したように見える。変更途中のキャッシュには、旧い子孫データと新しい DNAME が同居し得る。RFC 6672 は一時的な扱いに幅を認め、古い TTL の満了で整合性が戻るとする。

導入前には部分木全体を棚卸ししなければならない。撤回も分散時間で考える。権威サーバーから DNAME を消しても、まだ有効なキャッシュコピーは直ちには消えない。

一つの所有者に DNAME は一つだけで、CNAME とも共存しない。広い効力を与える代わりに、同じ地点から競合する二つの命令を出せないようにしている。

ワイルドカードが規則まで合成する危険

通常の DNAME は固定された規則から個別 CNAME を合成する。ワイルドカード DNAME では、ワイルドカード展開がまず DNAME 所有者を作り、その一時的所有者がさらに振り向け規則を作る。

RFC 4592 は、異なるキャッシュが非決定的な規則を得かねず、DNS の整合性を脅かすとした。RFC 6672 はこの形を非推奨とし、サーバーが警告、更新拒否、ゾーン拒否を行えるようにする。

固定された権威事実から結果を合成するなら検証できる。しかし、振り向ける権限そのものを問い合わせごとに合成すると、誰がどの範囲を決めたのかが曖昧になる。無限の質問を受けられることと、無限の制御規則を即興で作ることは別である。

ループと長さが計算量を制限する

DNAME 同士、または DNAME と CNAME はループを作れる。一つの置換が名前を同じ規則の適用範囲へ戻すこともある。正当な長い連鎖を許しつつ、一問い合わせに使う資源は制限しなければならない。

置換後の名前が DNS の最大長を超える場合、権威サーバーは YXDOMAIN を返し、DNAME と署名があればその証拠も示す。これは NXDOMAIN とは違う。元名が存在しないのではなく、計算結果を DNS 名として表現できない。

NS、MX、PTR、SRV の対象名は正規ホスト名でなければならず、そのアドレス探索を CNAME や DNAME に依存させられない。権威やサービス発見を成立させる基礎名の背後に、追加の別名連鎖を隠さないためだ。

源管理者は循環や過大な置換を避け、権威サーバーは正確な失敗を返し、リゾルバーは無限の作業を拒む。設定の簡潔さは、計算費用を他者へ無制限に転嫁する権利ではない。

技術的な連続性と組織的な連続性

DNAME は移行中も旧い子孫名を到達可能にできる。保存するのは構文上の対応と問い合わせ経路であり、所有権、契約、鍵、証明書、可用性、アプリケーションの受け入れではない。

したがって、信頼できる移行には別々の証拠が要る。源の規則を誰が変更できるのか。対象データを誰が運営するのか。サービスで旧名と新名を誰が受け入れるのか。DNS が何事もなく答えるほど、この制度的な確認を省いてはいけない。

DNAME は名前木の遠い場所へ問い合わせを動かせる。しかし、木を構成する権威までは動かせない。その制約こそが、部分木全体へ及ぶ別名を監査可能にした。

出典と証拠の限界

CNAME、ゾーンカット、NS 委任の原型は RFC 1034：https://www.rfc-editor.org/rfc/rfc1034.html

DNAME の初期仕様と動機は RFC 2672：https://www.rfc-editor.org/rfc/rfc2672.html

ワイルドカード DNAME の問題は RFC 4592：https://www.rfc-editor.org/rfc/rfc4592.html

振り向け連鎖の終端状態は RFC 6604：https://www.rfc-editor.org/rfc/rfc6604.html

現在の置換、合成、DNSSEC、失敗規則は RFC 6672：https://www.rfc-editor.org/rfc/rfc6672.html

現在の alias と delegation の定義は RFC 9499：https://www.rfc-editor.org/rfc/rfc9499.html

これらは現在の世界的導入率や普遍的な運用効果を示さない。番号変更や組織改称は設計例である。DNAME で名前解決できても、源と対象の所有者が同じ、アプリケーションが旧名を受け入れる、証明書が有効、または管理権限が移転したとは証明できない。