Résumé

  • RFC 3088 extrayait un domaine de certaines séquences d'attributs DC, interrogeait les enregistrements SRV _ldap._tcp et renvoyait des URL dans une référence LDAP.
  • Le service racine servait d'amorce, pas de base mondiale : le RFC recommandait un service local et ne conseillait le recours à la racine qu'après une référence.

Une réponse de premier serveur pouvait n'être qu'un aiguillage. Publié en avril 2001 sous statut expérimental, RFC 3088 décrivait le service racine d'OpenLDAP : un mécanisme qui aidait à trouver un serveur LDAP associé à un nom fondé sur le DNS. Il ne rapatriait pas la fiche demandée.

La chaîne commençait par le DN. RFC 2247 permettait de représenter des étiquettes de domaine par des composants DC; RFC 3088 analysait ces composants selon un algorithme précis. Il parcourait les RDN de gauche à droite, ajoutait certaines valeurs DC à la suite candidate et remettait celle-ci à zéro lorsqu'un composant non admissible interrompait la séquence. La forme du DN déterminait donc si un nom DNS pouvait être construit. Ce n'était pas une règle universelle consistant à retirer le nom d'utilisateur.

Pour example.net, le service interrogeait _ldap._tcp.example.net. Les enregistrements SRV contenaient des hôtes et ports possibles. Il les convertissait en URL LDAP, puis les renvoyait comme référence. Détail déterminant : l'implémentation décrite préservait l'ordre du résolveur et n'appliquait pas elle-même les priorités et poids SRV définis par RFC 2782.

Une opération LDAP de base pouvait ainsi recevoir une référence quand le DN visé se laissait associer à des URL. Restait à un serveur ou au client de poursuivre l'opération, puis au serveur désigné de répondre. La première réponse ne prouvait ni l'existence de l'entrée, ni sa fraîcheur, son exhaustivité ou l'autorité du destinataire. La référence désignait une prochaine question possible ; elle n'était pas le résultat de la recherche.

Le RFC conseillait une progression locale d'abord : un serveur pouvait renvoyer les demandes supérieures vers le service racine, mais les clients devaient normalement utiliser leur service local et ne contacter la racine qu'après y avoir été dirigés. Le dispositif réduisait le coût de coordination grâce à DNS, sans faire d'un point central le dépositaire de tous les annuaires.

Le texte rappelait lui-même que les mécanismes restaient expérimentaux et non définitifs. Le service décrit acceptait les liaisons anonymes, refusait les autres et fonctionnait sur TCP/IPv4. Il ne chiffrait pas les échanges et ne protégeait pas leur intégrité; RFC 3088 signalait l'exposition à l'usurpation DNS et au déni de service. Une intégrité de session LDAP ne suffisait pas à authentifier les données DNS qui avaient fabriqué la référence.

La section rétrospective rapportait un hôte unique et l'opinion des auteurs selon laquelle un équilibrage de charge courant pourrait suffire si la demande augmentait. Cela décrit leur expérience, pas un test de capacité indépendant, une garantie de disponibilité ou une mesure d'adoption générale.

Sources