Zusammenfassung

  • RFC 3088 leitete aus einer passenden Folge von DC-Komponenten eine Domain ab, fragte _ldap._tcp per SRV ab und gab daraus erzeugte LDAP-URLs als Verweis zurück.
  • Der Root-Dienst war ein Einstiegspunkt, keine globale Verzeichnisdatenbank. Das RFC empfahl, zunächst den lokalen Dienst zu nutzen und nur einem Verweis zur Root zu folgen.

Der erste Treffer einer verteilten Suche muss noch keine Antwort sein. Im April 2001 beschrieb das OpenLDAP-Projekt einen experimentellen Root Service, der LDAP-Server für domainbasierte Namen auffinden sollte. Die zentrale Bezeichnung klang umfassender als die tatsächliche Aufgabe: Der Dienst lieferte mögliche nächste Ziele, nicht die angefragten Personen- oder Organisationsdaten.

Ausgangspunkt war ein Distinguished Name (DN). RFC 2247 kann Domain-Komponenten in DC-Attributen abbilden. RFC 3088 prüfte die RDNs von links nach rechts und setzte aus geeigneten einwertigen DC-Komponenten einen DNS-Namen zusammen. Ein dazwischenliegendes, nicht passendes RDN setzte den Kandidaten zurück. Ob sich eine Domain ableiten ließ, hing damit von der konkreten DN-Struktur ab; ein allgemeines Entfernen von UID oder Namensbestandteilen reichte nicht.

Für example.net fragte der Dienst _ldap._tcp.example.net ab. SRV-Antworten konnten Ziele und Ports nennen. Daraus erzeugte OpenLDAP LDAP-URLs und gab sie als Referral zurück. Das RFC hält ausdrücklich fest, dass die beschriebene Implementierung die Auflösung in Resolver-Reihenfolge ausgab, statt SRV-Priorität oder -Gewicht selbst auszuwerten. Ein DNS-Feld ist noch kein Beleg dafür, dass der Client oder Server es tatsächlich verwendet.

Mit dem Referral war die Suche nicht abgeschlossen. Ein Client oder zwischengeschalteter LDAP-Server musste die URL verfolgen, und der Zielserver musste den Vorgang ausführen. Der Root Service sammelte keine Einträge aus allen Verzeichnissen und prüfte nicht, ob das Ziel den gesuchten Datensatz besaß. Die erste Antwort belegte eine mögliche nächste Station — nicht Existenz, Aktualität, Vollständigkeit oder Vertrauenswürdigkeit des endgültigen Eintrags.

Darum setzte das RFC auf lokale Dienste. LDAP-Server konnten höherliegende Anfragen an den OpenLDAP Root Service verweisen; eine direkte Anfrage des Clients war zwar möglich, wurde aber nicht empfohlen. Clients sollten lokal beginnen und nur dann zur Root gehen, wenn sie dorthin verwiesen wurden. DNS senkte so die Koordinationskosten zwischen getrennten Verzeichnissen, ohne alle Suchvorgänge in einen globalen Speicher zu zwingen.

RFC 3088 bezeichnete seine Mechanismen als experimentell und nicht endgültig. Der beschriebene Dienst unterstützte LDAPv3 und LDAPv2+ über TCP/IPv4; LDAPv2 konnte keine Referrals darstellen. Der Root-Dienst nahm anonyme Bindungen an, lehnte andere ab und bot weder Verschlüsselung noch Integritätsschutz für Informationen. Das RFC nennt DNS-Spoofing und Denial-of-Service als Risiken und warnt, dass LDAP-Sitzungsintegrität die DNS-Daten hinter einem Referral nicht automatisch verifiziert.

Der Erfahrungsbericht sagt, der Dienst laufe damals auf einem einzelnen Host. Die Autoren hielten gewöhnliches Load-Balancing bei steigendem Bedarf für ausreichend. Das ist ihre zeitgenössische Einschätzung, kein unabhängiger Kapazitätstest, keine Verfügbarkeitszusage und keine Messung breiter Nutzung.

Quellen