Zusammenfassung

  • RFC 3663 schätzte, dass eine nicht normalisierte LDAP-Darstellung aus einem relationalen Bestand von ungefähr 20 Millionen Objekten mehr als 115 Millionen Verzeichnisobjekte machen könnte.
  • Verweise sollten Beziehungen und betriebliche Grenzen erhalten. Unterschiedliches Clientverhalten und Verweisschleifen führten das Experiment jedoch zu einem normalisierten Backend mit einer denormalisierten Clientansicht. Die Clients mussten weiterhin die konkrete Verzeichnisstruktur kennen.

Erst änderte sich die Datenform

Eine Domain ist kein isolierter Datensatz. Sie kann mehrere Ansprechpartner und Nameserver haben; derselbe Nameserver kann viele Domains bedienen. Registry und Registrar halten zudem nicht dieselben administrativen Zuständigkeiten. Werden sämtliche Beziehungen direkt in einen Verzeichnisbaum ausgerollt, können gemeinsame Personen und Server an vielen Stellen wiederholt erscheinen.

RFC 3663 erschien im Dezember 2003 als Experimental-Dokument. Sie beschreibt den von VeriSign gestarteten Referral-LDAP-Dienst als Versuch, LDAP und gängige LDAP-Typen für administrative Domain-Daten zu nutzen. Die Entwurfsschätzung war deutlich: Aus einem relationalen Bestand von rund 20 Millionen Objekten könnten in der vorgeschlagenen, nicht normalisierten Directory Information Tree (DIT) mehr als 115 Millionen Verzeichnisobjekte werden. Das ist eine im RFC berichtete Schätzung für den Architekturvergleich, kein Nachweis, dass ein Dienst dieser Größe so aufgebaut wurde. Die Form des Verzeichnisses wurde damit zu einer Speicher- und Betriebsfrage statt einer bloßen Benennungsentscheidung. RFC 3663

Das Experiment stand in einer längeren Vorgeschichte. Der ursprüngliche InterNIC-Vertrag sah für administrative Domain-Daten ein X.500-Verzeichnis vor. Schwierigkeiten mit verfügbaren Serverimplementierungen führten zunächst zu einem vorläufigen NICNAME/WHOIS-Dienst. RWhois sollte diesen Ansatz später erweitern, fand laut RFC 3663 für Domain-Daten aber keine breite Akzeptanz. Referral LDAP verfolgte ein engeres Ziel: strukturierte Anfragen und Ergebnisse, bessere maschinelle Lesbarkeit und eine Weiterleitung vom Registry-Bestand zum passenden Registrar, während sich die Zuständigkeiten zwischen beiden aufteilten. RFC 954 RFC 2167 RFC 3663

Verweise verlagerten die Komplexität

Der erste DIT-Entwurf setzte stark auf interne Verweise zwischen dem Baum für Top-Level-Domains und getrennten Bäumen für Nameserver und Kontakte. So sollten Beziehungen nicht überall kopiert werden; außerdem war eine Verteilung auf verschiedene Server denkbar. Ein LDAP-Verweis ist jedoch nicht bloß eine weitere Ergebniszeile. Ein Client muss entscheiden, ob er ihm folgt, den Zweck der ursprünglichen Suche bewahrt und die spätere Antwort verarbeiten.

Erste Tests mit ldapsearch zeigten unterschiedliche Interpretationen und Verarbeitungsweisen. Manche Clients konnten sich leicht in Verweisschleifen verfangen. Die endgültige Lösung war ein angepasster Backend-Speicher, der normalisierte Daten vorhielt, dem Client aber eine denormalisierte Ansicht präsentierte und dadurch interne Serververweise vermied. RFC 3663 geht davon aus, dass große Datenbestände wahrscheinlich ein solches Backend benötigen würden; kleinere könnten mit Standardservern auskommen. Die Verbindungen zwischen den Einträgen verschwanden nicht. Eine andere Komponente musste sie in die benötigte Ansicht überführen. RFC 3663

Verweise zwischen Servern erfüllten eine andere Aufgabe: Sie bildeten ab, dass Registry und Registrar von unterschiedlichen Organisationen, Maschinen oder Netzen betrieben werden konnten. Dennoch konnten Verweise in Suchergebnissen auftauchen, obwohl sie nicht zum angegebenen Filter gehörten, und ein übliches Limit von 50 Einträgen füllen. Wer Datensätze erwartete, erhielt möglicherweise vor allem weitere Ziele. Die RFC beschreibt das als Problem der Suchverteilung, nicht als Beleg für einen grundsätzlichen LDAP-Fehler. RFC 3663 RFC 2251

Ein generisches Protokoll ergab keinen universellen Client

LDAP bot einen gemeinsamen Zugriffsweg. Die grafischen Clients mussten aber den konkreten DIT und das Schema des Dienstes kennen. Sie ließen sich nicht unverändert an ein anderes LDAP-Verzeichnis anschließen und konnten dessen Daten dann vollständig nutzen. Ein universeller Client, der alle Strukturunterschiede verbirgt, würde entweder weniger Informationen zeigen oder für durchschnittliche Nutzer zu kompliziert werden. Wiederverwendbar war die Protokollschnittstelle; das zugrunde liegende Datenmodell war es nicht automatisch. RFC 3663

Die Distanz zeigte sich auch in der Bedienung. Laut RFC hielten manche Nutzer den Webclient für den einzigen Zugang und verstanden weder LDAP als Zwischenschicht noch das Zusammenspiel von Registry, Registrar und Registrant. Die C- und Java-Bibliotheken konnten verschachtelte Suchen und komplexe Verweisverfolgung bewältigen; viele Schwierigkeiten betrafen dennoch die Nutzbarkeit. Das Dokument räumt außerdem ein, dass sich die Popularität der Clients nicht genau messen ließ. Es sind Beobachtungen aus dem Experiment, keine repräsentative Nutzerstudie. RFC 3663

Auch strukturierte Daten beseitigten weder Suchkosten noch die Sorge vor massenhafter Sammlung. Beliebige LDAP-Abfragen konnten für einen öffentlichen Dienst zu teuer werden, weshalb das Experiment nur bestimmte Suchformen zuließ. Nutzer fragten trotzdem nach rekursiven Wörterbuchabfragen, um die Beschränkungen zu umgehen; viele WHOIS-Betreiber bezeichneten dies als Data Mining. Der Sicherheitsabschnitt warnt ausdrücklich, dass die demonstrierte Zugriffskontrolle mit Distinguished Name und Passwort kein Modell für einen Produktivdienst sei. RFC 3663 RFC 2026

Die eigentliche Frage war: Wer übersetzt?

Der historische Wert der RFC 3663 liegt in ihrer Offenheit über die Zielkonflikte. Eine generische Verzeichnistechnik erzeugte keine portable Nutzungserfahrung. Normalisierung begrenzte die Vervielfachung der Objekte, verlangte aber ein angepasstes Backend, das die erwartete Ansicht für Clients wiederherstellte. Verweise wahrten Grenzen zwischen Betreibern, machten den Erfolg einer Suche jedoch von Clientverhalten und Richtlinien jeder Ebene abhängig.

Die RFC merkte an, dass Suchen weiterhin auf Registry-Ebene beginnen mussten, selbst wenn sie einen bestimmten Registrar oder Registranten betrafen. DNS-SRV- oder NAPTR-Ermittlung wurde nicht umgesetzt. Auch die LDAP-Servererhebung blieb begrenzt: Sie nutzte Zonendateien für .com, .net, .org und .edu, prüfte Port 389 bei Domainnamen sowie Hosts namens ldap oder dir und suchte nicht nach SRV-Einträgen. Die Schätzung, etwa 0,5 Prozent der aktiven Domains in dieser Stichprobe hätten einen LDAP-Server, ist weder eine Internet-weite Erhebung noch eine Aussage über den heutigen Zustand. RFC 3663

Die Entscheidung lautete also nicht einfach Baum oder relationale Datenbank. Es ging darum, wer einen relationalen Eintrag in eine Verzeichnisansicht, einen Verweis in das nächste Ziel und eine technische Antwort zurück in die gesuchte Information übersetzt. Das Pilotprojekt legte einen Teil dieser Arbeit in einen spezialisierten Server und Clients, die die jeweilige Struktur kannten, statt Millionen wiederholter Objekte oder fragile Verweisketten hinzunehmen. Das gemeinsame Protokoll machte die Bauteile vertraut. Den Wegweiser lieferte es nicht.

Quellen