要約

  • RFC 3088は、条件に合うDC成分からドメインを取り出し、_ldap._tcpのSRVレコードを検索してLDAP URLを紹介として返した。
  • ルートサービスは探索の起点であり、世界中のレコードを持つデータベースではない。RFCはまずローカルサービスを使い、紹介を受けた場合にだけルートへ進むよう勧めた。

ディレクトリ検索の最初の返答は、「記録があります」ではなく「次はここに聞いてください」かもしれない。2001年4月、OpenLDAP Projectは、DNSベースの名前に対応するLDAPサービスを見つける実験的なRoot Serviceを記述した。そこに全組織や個人のレコードを集約したわけではない。

処理の入力は識別名（DN）だった。RFC 2247はDC成分でドメイン名を表す方法を示し、RFC 3088はDNからDNS名を組み立てる規則を定めた。RDNを左から読み、条件を満たす単一値のDC成分を連ねる。途中に対象外の成分が入ると、それまでの候補はリセットされる。したがって「先頭のUIDを消せばドメインになる」という単純な処理ではない。

たとえばexample.netなら、サービスは_ldap._tcp.example.netを検索する。DNS SRV応答には接続先とポートが含まれ得る。Root Serviceは各応答からLDAP URLを作り、LDAP referralとして返した。ただし、RFCが記述する実装はリゾルバーの順番で返し、RFC 2782のpriorityやweightを自ら適用していなかった。DNSに値が載ることと、アプリケーションがその値を使うことは別の証拠である。

referralが返っても検索は終わらない。クライアントか中継サーバーがURLを追い、移動先のLDAPサーバーが操作を処理する。ルートサービスが複数サーバーの結果をまとめたり、求めるエントリーの存在を検証したりするわけではない。確認できるのは候補となる次の接続先であり、最終データの鮮度、完全性、権威性ではない。

RFC 3088はローカル優先の運用を勧めた。サーバーは上位の問い合わせをOpenLDAP Root Serviceへ紹介できる一方、クライアントが直接ルートへ問い合わせる方法は推奨されない。まず地域のサービスを使い、そこで紹介されたときに限ってルートへ進む。DNSをディレクトリ間の接着剤に使いつつ、すべての検索を一か所に集めない設計だった。

RFC自身がこの仕組みをExperimentalと位置づけ、確定的な標準ではないと明記した。記述されたサービスはTCP/IPv4上のLDAPv3とLDAPv2+を扱い、referralを表せないLDAPv2は対象外だった。匿名bindは受け入れる一方、他のbindは拒否し、暗号化や情報の完全性保護も提供しない。DNS spoofingやDoSへの懸念をRFCは挙げており、LDAPセッションを保護しても、紹介元となったDNS情報まで検証できるとは限らないと注意している。

経験を記す節では、サービスは当時一台のホストで動き、必要なら一般的な負荷分散で拡張できるという著者の見立てが述べられる。これは実験の記述であり、独立した容量試験、可用性保証、普及率の証拠ではない。

出典