要約

  • RFC 1480 が .US に用意したのは、枝の委任、IP ホストの A による直接登録、非 IP ホストの MX による直接登録だった。名前の存在だけでは、どの仕組みと管理権限が背後にあるか判定できない。
  • 委任は指定管理者に枝の制御を渡す一方、公平な受付、技術的能力、正確な運用、冗長なサーバー、共同体への奉仕、合意された移管という継続責任を負わせた。上位データベースへの一行追加とは別の出来事である。

申請書の選択肢が権限の所在を示した

1993 年 6 月の RFC 1480 は、州、地域、K12、図書館、連邦機関などに .US の名前を分ける案を詳述した。利用者から見れば、点でつながった名前は一つの秩序に属する。

しかし申請書は一つの「ドメイン登録」欄で済ませなかった。上位の主データベースに情報を置く直接登録と、組織がネームサーバーを動かす枝の委任を分けた。直接登録も、IP アドレスを持つホストと UUCP などの非 IP ホストに分かれた。

この分類は、登録後の見た目より重要だった。変更できる者、通信を運ぶ装置、障害時に説明する者が、選択肢ごとに変わるからだ。

A が返っても子ゾーンの管理者にはならない

IP ホストの直接登録では、.US 管理側が自らのデータベースに A レコードを置く。RFC 1035 によれば A は 32 ビットのインターネットアドレスを保持する。それは名前の下に新しい名前を発行する権限を表さない。

ゾーン制御には別の合意が要る。RFC 1034 は、適切な親ゾーンを特定し、その管理者から制御委任の同意を得る手順を示した。NS は所有者名から始まるゾーンの権威サーバーとして期待されるホストを示す。

A は到達先アドレスについて語り、NS は権威の接続点について語る。どちらも有効でも、一方から他方を推定してはならない。直接レコードの修正窓口は上位側に残り、委任ゾーンの内容は指定管理者が扱う。

MX の先にまだ私的な経路が残った

RFC 1480 は、インターネットに直接つながらない UUCP ホストにも DNS 形式の名前を与えた。送信者は通常のメールアドレスを使い、MX が IP 接続済みの中継ホストを示す。表面上はネットワーク境界を意識しなくてよい。

ところが配送側では境界は消えていない。RFC 1035 の MX は、所有者名のメール交換を引き受けるホストを指定する。RFC 974 は交換先の選択を定める。それでも、名前の主体が IP ホストになったわけではない。

中継ホストの同意、非 IP ホストまで運ぶ技術手順、ローカルな経路規則が必要だった。途中に別の UUCP ホストがあれば、そこにも次の配送規則が要る。.US 管理者は MX を登録できても、中継者の承諾を代行できなかった。

したがって MX 応答は公開されたメール入口の証拠にとどまる。現在の同意、発呼成功、キュー処理、受信者への到着は、それぞれ別のログで確かめる必要がある。

委任されたのは名前だけでなく仕事だった

K12.TX.US や LIB.MN.US のような枝を外部に任せる理由は規模だった。一つの管理組織が .US 末尾の全登録を抱え続けることはできない。委任は作業を小さな単位に分割した。

RFC 1480 は指定管理者を単なるサーバー所有者として扱わない。申請者を公平に扱い、関連事業者の顧客を優遇せず、特定のメール方式、プロトコル、製品を条件にしないことを求めた。重要な利害関係者は、その管理者が適任であることに同意するべきだとした。

技術面では、正確なデータ、迅速な応答、堅牢な運用が責任となる。プライマリとセカンダリは IP で到達でき、上位管理者が状態とデータを点検できなければならない。地域災害で同時停止しないよう、物理的に離した設置も勧告された。

二つの NS 名があることと、二つの独立した障害領域があることは同じではない。権威応答と、公平性や共同体の支持も同じではない。

管理者交代は DNS 更新より広いイベントだった

trusteeship を別組織へ移すには、旧組織と新組織の双方から連絡を受け、相互合意と新管理者の責任理解を上位側が確認する必要があった。影響を受ける関係者の意見も役立つとされた。

同じゾーン名のまま、組織、サーバー、連絡先は変わり得る。最終的な NS 集合だけを残すと、合意、承認、切替、安定運用がどの順番で起きたかは消える。

RFC 1591 は翌年、この考えを国別ドメイン一般の公共サービスと trustee の責任として述べた。制度の読み方を補強するが、特定の委任が適正だったという受領証にはならない。

地理的な木は当時の管理設計だった

RFC 1480 は半年前の RFC 1386 を置き換えた。短期間の改訂は、成長する名前空間に文書が追随した証拠であり、各枝の実装数ではない。

地理や学校種別を使った長い名前は、誰もが短い「当然の名前」を得るためではなく、重複を避け、管理作業を分割するために選ばれた。RFC 920 から続く命名政策を、米国の具体的な運用単位に落とした案だった。

RFC Editor の記録 は文書を Informational とする。本文はセキュリティ問題を扱わないと明記した。冗長性や trustee の責務を、認証や安全性の保証へ読み替えることはできない。

後年の検証済み正誤表は、付録の BNF に欠けていた選択記号を補った。修正対象は文法であり、過去のゾーンの委任状態ではない。

名前を監査するなら現在値だけを見ない

最小の記録でも、所有者名、RR 種別、公開したゾーン、委任点、指定管理者、サーバー、観測時刻を分ける必要がある。メールなら MX のほかに中継同意、UUCP の各規則、配送試行と受領を残す。統治なら管理者選任と移管の証拠を残す。

DNS は違う仕組みを一つの使いやすい名前へまとめた。その成果を守るには、調査時だけはまとめられる前の責任境界を復元しなければならない。

出典