要約

  • RFC 1279 は X.500 にドメイン階層を表現したが、ドメインと組織、メールボックスと人物を区別した。異なるオブジェクトなので、alias による接続は不適切とされた。
  • AssociatedDomain と AssociatedName は方向を持つ関連を保存した。ドメイン項目は組織情報を複製せず、必要最小限の情報とポインタを持つ。関係は多対多にもなり得た。
  • DNS record を DSA へ移す zone-transfer tool は、非 DNS 属性を変更してはならなかった。転送、書込み、保全、関連、検索、本人性、結果は別々の証拠である。

一つの Directory に異なる現実を置く

1991 年 11 月の RFC 1279、X.500 and Domains は Experimental 文書だった。DNS の階層を X.500 Directory Information Tree に表現し、ドメインやメールボックスから管理情報を検索できるようにする実験を提案した。

出発点は DNS の置換ではない。当初は Domain Databases が原本を持ち、そこから X.500 へ情報を送る可能性が高いと書かれた。付録は閲覧、zone transfer、リンク補完、複数 DSA への分散、DNS server の模擬を順番に試し、最後に一部の DNS 階層を DIT で管理する可能性を置いた。

設計図、開始操作、完了、権限移転、利用結果は同じ出来事ではない。最後の段階が文章に存在しても、実世界で到達した証拠にはならない。

DNS 型の枝では各ラベルを DomainComponent として配置できた。RFC 822 mailbox の local part も特殊な component として続けられた。組織型の枝には大学、部門、人物、役割が別の項目として置かれる。

両方に似た名前があっても、表現対象は違う。ドメインは名前空間上の位置であり、組織は独自の属性を持つ主体である。mailbox は配送先であり、person の代用品ではない。

だから RFC 1279 は cross-link に aliasing を使わなかった。Alias は二つの名前が同じ対象を示すという強い意味を持つ。ここで必要なのは、異なる対象の間にある関係だった。

二方向は一つの事実ではない

組織項目からは AssociatedDomain で関連ドメインを示す。ドメイン項目からは AssociatedName で組織 DIT の項目を示す。

見た目は往復でも、二つは別の主張である。誰が組織側の関係を書いたか、誰がドメイン側を補ったか、時刻は同じかを保存できる。片方向が欠けても、UI が勝手に逆向きを作る必要はない。

RFC は一対一も保証しなかった。一つの domain が複数 organisation と関連し、一つの organisation が複数 domain と関連する場合がある。単一 owner 欄へ圧縮すれば、この多重性が消える。

関連は legal ownership、authentication、authorization の証明でもない。ドメインから組織へ到達できることは、全サービスの運営者を認証しない。mailbox と人物が近くに置かれても、送信者の本人性は別の証拠を要する。

関係を長く検証するには、述語、向き、作成者、時点が必要である。それらを捨てると、近さが同一性へ、同一性が権限へと誤変換される。

複製しないことは訂正権を守る

ドメイン固有の DNS 情報は domain entry に置ける。しかし組織側に既に存在する情報は複製せず、domain entry を簡素にして organisational DIT を指すことが推奨された。

同じ電話番号を二か所へ保存すると、二つの更新時計が生まれる。担当者交代で組織側だけ直れば、domain 側の古い値も形式上は正しいまま残る。検索画面はどちらに訂正権があるか判断できない。

複数ドメインへ古い値がコピーされれば、反復が独立確認のように見える。しかし出所は一つの古い記録でしかない。

Pointer なら責任が残る。組織項目は自分の連絡属性を管理し、ドメイン項目は関連そのものを管理する。画面は統合表示できるが、表示の統合は出所の統合ではない。

誤った関連はリンクだけを修正でき、連絡先変更は一つの原本で済む。対象と、対象へ到達した理由を同時に保存できる。

TTL の文字列は DNS の時計ではない

RFC 1279 は DNS resource record を text 形式で DIT に置く方法を選んだ。domain は完全形で、各 record は TTL を持つ。単一の DNSRecord 属性なら、新しい record type ごとに定義全体を増やさずに済む。

相互に情報を移せるよう DNS と等価な内容を目指した一方、OSI Directory は DNS caching や TTL handling を模倣しないと明記した。master entry は zone transfer などで維持される想定だった。

RFC 1035 の TTL は、source へ再照会せず cache を使える時間に関わる。Zone data、cache data、refresh、expiry には別の役割がある。TTL の数字を X.500 へ移しても、同じ countdown が動くわけではない。

必要な履歴は source zone、serial、transfer の開始と完了、受信集合、DSA の受理時刻、後続 refresh、検索時点である。数字だけが残っても、その値を現在と扱う根拠は戻らない。

運搬者の書込み範囲は狭かった

付録の zone-transfer tool は DNS server と DSA の間で情報を運ぶ。DSA へ書くとき、DNS record ではない属性を変更しないという条件が付いた。

同じ container にあるからといって、manager、telephone、組織説明、関連 pointer まで運搬者の管理対象にはならない。運ぶ record family が書込み権限の境界だった。

DSA 接続は transfer 完了ではない。完了は全値の受理を保証しない。DNS write は隣接属性の不変を自動的に証明しない。Lookup 成功は利用者の行動を証明しない。

Source state、request、received set、accepted write、protected attributes の前後、link、response、action を分ければ、どの段階で意味が変わったか追える。「同期済み」だけではこの区別を失う。

可能性を実績にしない

RFC 1279 は security issues を直接扱わず、X.500 の機能がより安全な管理につながる可能性だけを述べた。可能性は認証結果ではない。

RFC 1309 は entry が object を表し、各組織が distributed directory の中で local information を master できる一般像を説明した。その背景は object を分ける理由を補うが、RFC 1279 の実験完了を証明しない。

出典と限界

RFC 1279 は domain 表現、alias 拒否、二方向 link、非複製、transfer 境界、段階的実験を支える。RFC 1274 は関連属性と domain object class を確認する。RFC 1035 は DNS TTL と zone operation の背景だけに用いる。RFC 1309 は X.500 entry と分散した local mastery の一般説明に限る。

これらは named deployment、legal owner、authenticated identity、completed transfer、fresh value、successful lookup、security outcome、user action を証明しない。