要約

  • RFC 3663は、約2,000万件のオブジェクトを持つリレーショナルデータセットを非正規化してLDAPに表すと、ディレクトリのオブジェクトが1億1,500万件を超える可能性があると見積もった。
  • 参照は関連性と運用上の境界を保つはずだったが、クライアントごとの解釈差や参照ループが生じた。実験は正規化バックエンドとクライアント向けの非正規化ビューに移行したものの、クライアントは個別のディレクトリ構造を理解する必要があった。

データの形から始まった

ドメイン登録は一つのレコードだけでは完結しない。複数の連絡先やネームサーバーが一つのドメインに結び付き、同じネームサーバーが複数ドメインを支えることもある。レジストリとレジストラも、行政上の情報を同じ責任範囲で持つわけではない。関係をすべてディレクトリツリーに展開すると、共通の人物やサーバーを何度も複製しかねない。

2003年12月のRFC 3663は、VeriSignが立ち上げたReferral LDAP Serviceを実験として記録している。狙いは、LDAPと既存のLDAP型を使ってドメインの管理情報を検索できるかを試すことだった。設計上の見積もりは大きい。約2,000万件のリレーショナルオブジェクトが、提案された非正規化Directory Information Tree（DIT）では1億1,500万件超のディレクトリオブジェクトに膨らむ可能性があるという。これはその規模の構築を確認した測定値ではなく、設計を選ぶ段階でRFCが示した見積もりである。ディレクトリの形は、命名規則だけでなく保存と運用の問題になった。RFC 3663

この実験の背景には、より古い経緯がある。InterNICの当初の契約では、ドメイン管理情報のためにX.500ディレクトリを作る計画だったが、当時のサーバー実装の問題からNICNAME/WHOISサーバーが暫定的に設置された。RWhoisはその方式を拡張しようとしたものの、RFC 3663によればドメイン情報用途では広く受け入れられなかった。Referral LDAPが目指したのは、構造化された検索と結果、機械処理のしやすさ、そして役割分担が進むレジストリから適切なレジストラへ問い合わせを導くことだった。RFC 954 RFC 2167 RFC 3663

参照は複雑さの置き場所を変えた

最初のDIT案では、トップレベルドメインのツリーとネームサーバー・連絡先のツリーの間に、サーバー内部参照を多用した。各関係の重複を減らし、別サーバーへの分散にもつながる可能性があったからだ。ただしLDAPの参照は、行を一つ追加するだけの仕組みではない。クライアントは別サーバーをたどるかを判断し、元の検索の目的を保ち、次の応答を処理しなければならない。

ldapsearchを使った初期試験では、参照の解釈や追跡方法が実装ごとに異なり、ループに陥りやすいクライアントもあった。最終案は、データを正規化したまま保持し、クライアントには非正規化した見え方を返すカスタムバックエンドだった。これによりサーバー内部参照を使わずに済んだ。RFCは、大規模データには特注のバックエンドが必要になりそうだが、小規模なデータなら既製サーバーでも対応できると述べる。記録同士のつながりは消えず、必要な形に組み立てる担当が変わった。RFC 3663

サーバー間参照には別の意味があった。レジストリとレジストラが別組織、別ネットワークで運営されるという境界を表すためだ。しかし、検索フィルターに該当しない参照でも結果に入り、通常50件のサイズ上限を埋めることがあった。問い合わせた側には、レコードではなく次の接続先ばかりが返る可能性がある。RFCはこれを検索分配の難しさとして記し、LDAPプロトコル自体の欠陥だとはしていない。RFC 3663 RFC 2251

汎用プロトコルでも汎用クライアントにはならない

LDAPは共通のアクセス方式を提供したが、実験で作られたGUIクライアントはサービス固有のDITとスキーマを知る必要があった。別のLDAPサービスにそのまま接続して、同じように情報を活用することはできない。構造の違いをすべて隠す「万能」クライアントは、情報を十分に使えないか、一般利用者には複雑すぎるかのどちらかになり得る。RFC 3663

ユーザーへの説明も容易ではなかった。Webクライアントを唯一の窓口だと誤解する人がおり、検索結果だけでは背後にあるLDAPやレジストリ・レジストラ・登録者の関係が伝わりにくかったという。CとJavaのクライアントライブラリは、入れ子の検索や高度な参照追跡を行うのに十分だったが、問題の多くは使いやすさにあった。RFCは各クライアントの人気を正確に測れないとも認めている。これは実験での観察であって、利用者全体の調査ではない。RFC 3663

検索コストとデータ収集の問題も残った。LDAPで表現できる検索を何でも許せば公開サービスには重すぎるため、実験は検索方法を限定した。それでも制限を辞書的な名前の総当たりで迂回できないか、という質問が多かった。WHOISの運営者の多くは、その行為をデータマイニングと見なしていた。さらに安全性に関する節は率直で、識別名とパスワードによるアクセス制御の実演は、本番環境の基準にしてはならないと記している。RFC 3663 RFC 2026

問われたのは、誰が変換を担うか

RFC 3663の歴史的な価値は、汎用ディレクトリ技術だけでは移植可能な利用体験を作れないと、実験の側が明かした点にある。データの正規化はオブジェクトの重複を抑える一方、クライアントが求める表示をカスタムバックエンドに作らせる。組織間参照は運営主体の境界を保つが、検索の成否をクライアントの挙動や各階層の方針に左右させる。

このサービスでは、特定のレジストラや登録者を探したい場合でも検索の入口がレジストリに固定されていた。DNS SRVやNAPTRによるサーバー発見は実装されなかった。LDAPサーバーの調査範囲も限定的だ。対象は.com、.net、.org、.eduのゾーンファイルで、ドメイン名とldapまたはdirというホスト名の389番ポートを調べ、SRVレコードは検索していない。RFCにある「稼働中ドメインの約0.5%」という値は、その方法と標本に限った推定であり、インターネット全体の調査でも現在の比率でもない。RFC 3663

本当の選択は、ツリーかリレーショナルデータベースかだけではなかった。誰が、関係型の記録をディレクトリ表示へ変換し、参照を次の接続先に結び付け、最後にユーザーが探す情報へ戻すのか。パイロットは大量の重複オブジェクトや不安定な参照連鎖よりも、その一部を専用サーバーとサービス構造を理解するクライアントに持たせた。共通プロトコルは部品の形をそろえたが、利用者の道筋までは描かなかった。

出典