要約

  • RFC 3375 は、複数のレジストラが担当オブジェクトを管理する一方、特定の名前空間とゾーンについては一つのレジストリだけが権威を持つ共有登録モデルを整理した。
  • オブジェクトの識別、スポンサーシップ、共有資源との関連付け、移管、レジストリ取引の状態、DNS 公開は別々の事実である。一つの成功応答は次の段階の完了を証明しない。

登録者から見ると、ドメインの取得は一社との取引に見える。レジストラを選び、必要な情報を渡し、確認を受け取る。しかし、その会社が名前空間そのものを単独で運営しているわけではない。レジストラは共通のレジストリに接続し、作成、更新、更新期間の延長、削除、移管といった命令を送る。レジストリの情報の一部が、さらに DNS ゾーンへ反映される。

RFC 3375 は 2002 年 9 月に Informational 文書として公開された。Internet Standard ではなく、実装状況を調べた報告でもない。共有登録が例外的な事務処理から基盤サービスへ変わる時期に、汎用的なレジストリ・レジストラ間プロトコルへ何を要求すべきかを示した文書である。

まず三つの役割が区別された。登録者はレジストラを通じて名前を登録する。レジストラは登録者への窓口を提供し、認可された立場でレジストリへアクセスする。レジストリは委任に関わる中央リポジトリを管理し、通常はゾーンファイルの生成と配布も担う。共有システムでは、複数の独立したレジストラが同じレジストリを利用する。

販売窓口が増えても、技術的な権威が分割されるわけではない。RFC 3375 は、ある名前空間とゾーンに対して権威を持つレジストリは一つだけだとした。一つのレジストリが複数の空間を担当することはできる。レジストラが得るのは、スポンサーとなった特定オブジェクトへの管理能力であり、名前空間の主権ではない。

プロトコルにはセッション管理、照会、作成、変更、更新、削除、移管が必要だった。クライアントとサーバーの識別・認証、権限確認、状態応答も求められた。オブジェクトを変える取引にはレジストリ内で一意の識別子を付ける。これにより操作を追跡できるが、取引 ID は万能の領収書ではない。レジストリが命令を処理したことと、ゾーンが生成されたこと、権威サーバーが読み込んだこと、遠隔のリゾルバが観測したことは別である。

オブジェクト自身の識別は、管理者の交代を越えて持続する。RFC 3375 はグローバルに一意な識別子を要求し、同じリポジトリに存在する期間は、管理権が変わっても識別子を変えないとした。ドメイン移管はスポンサーの変更であって、過去のオブジェクトを消して新しいものを作る操作ではない。この連続性が監査を可能にする。

共有資源では、参照と制御の違いがさらに重要になる。レジストラ X が管理するネームサーバーを、レジストラ Y の担当ドメインが利用する場合がある。Y は既存サーバーを自分のドメインへ関連付けられなければならないが、そのサーバーを変更する権限までは得ない。参照したすべての者に制御を与えれば、他の多数のドメインに影響できてしまう。

移管は管理関係を正式に変える手続きである。新しい管理者になろうとするレジストラが要求を開始し、プロトコルは認可の確認、状態の表示、連動して移るオブジェクトの説明、決定前の取消し、承認または拒否の通知を支える必要がある。ドメイン内に登録されたネームサーバーが一緒に移るなら、その範囲も明示されるべきだった。

文書は厚いレジストリと薄いレジストリの双方を認めた。厚いモデルは委任情報に加えて連絡先などの社会的情報もレジストリに保管する。薄いモデルでは一部をレジストラ側に残す。汎用要件の狙いは、全事業者を同じデータベース構造へ押し込むことではなく、異なる運用モデルに共通の動詞を与えることだった。

DNS との境界は特に誤解されやすい。RFC 1034 と RFC 1035 はゾーン、権威サーバー、キャッシュ、名前解決を説明する。RFC 2136 は DNS ゾーンを動的更新する別の仕組みを示す。RFC 3375 はレジストリのオブジェクトと、レジストリによるゾーンファイル生成を扱う。更新料の支払い、連絡先変更、移管は成功しても DNS を直ちに変えないことがある。委任変更も、投影、配布、読込み、キャッシュの経過を経て初めて外部から見える。

RFC 2832 は Registry Registrar Protocol を定義していた。その後 RFC 3730 が EPP を規定し、RFC 5730 が基本仕様を置き換えた。RFC 5731、RFC 5732、RFC 5733 はドメイン、ホスト、連絡先のマッピングを定める。この系譜は仕様の精緻化を示すが、すべてのレジストリが全機能を実装した証明でも、共通の運用時間を保証する記録でもない。

RFC 2119 の規範語も慎重に読む必要がある。MUST は設計上の要求であり、現実の実装確認ではない。RFC 2277 の国際化方針が示すように、世界的な登録基盤では、文字、自然言語、連絡先、DNS 識別子を一つの問題として処理することもできなかった。

Lu Heng の「最小初期仕様」という考え方は、この構造を理解する助けになる。相互運用に必要な最小限を共同で定め、その後の判断は責任を持つ現場に残す。「現実の層」という視点では、登録者の依頼、レジストラの認可、スポンサーシップ、レジストリ受理、リポジトリ状態、ゾーン生成、権威応答、リゾルバ観測は連鎖していても同じ事実ではない。

RFC 3375 が残した教訓は、権限を曖昧にせず分けることで規模を得られるということだ。窓口は競争でき、名前空間は一貫した権威を保てる。オブジェクトは管理者が変わっても同一性を保ち、共有資源は複数に使われても全員の管理物にはならない。インフラを正しく理解するには、成功という一語ではなく、それぞれの層の証拠を集めなければならない。

出典