Résumé

  • La RFC 3663 estimait qu’une représentation LDAP non normalisée pouvait transformer un jeu relationnel d’environ 20 millions d’objets en plus de 115 millions d’objets d’annuaire.
  • Les renvois devaient préserver les relations et les frontières opérationnelles. Les comportements incohérents et les boucles de renvoi ont conduit l’expérience vers un stockage normalisé, une vue adaptée aux clients et des logiciels qui connaissaient tout de même l’arborescence utilisée.

Le premier problème était la forme des données

Un domaine n’est pas un objet isolé. Il peut être associé à plusieurs contacts et serveurs de noms ; un serveur de noms peut, à son tour, desservir plusieurs domaines. Les registres et les bureaux d’enregistrement n’exercent pas non plus les mêmes responsabilités. Reproduire chaque relation dans une arborescence risque donc de répéter les mêmes personnes et serveurs à de nombreux endroits.

Publiée en décembre 2003 comme expérimentation, la RFC 3663 décrit le service Referral LDAP lancé par VeriSign pour explorer l’usage de LDAP dans la consultation de données administratives sur les domaines. Son estimation de conception est frappante : environ 20 millions d’objets relationnels auraient donné plus de 115 millions d’objets dans une représentation non normalisée du DIT, l’arbre d’information du répertoire. Ce chiffre est une estimation rapportée par le document, pas le bilan d’un déploiement de cette taille. RFC 3663

L’expérience prolongeait une histoire plus ancienne. Le contrat initial de l’InterNIC prévoyait un répertoire X.500 pour les données administratives des domaines ; les difficultés des logiciels serveur disponibles ont mené à un service NICNAME/WHOIS temporaire. RWhois a ensuite proposé une extension, sans gagner une large adoption pour ces données, selon la RFC. L’objectif de Referral LDAP était plus restreint : offrir des requêtes et des résultats structurés, faciliter la lecture par machine et relier le registre au bureau d’enregistrement approprié, dans un contexte de séparation croissante des rôles. RFC 954 RFC 2167 RFC 3663

Les renvois ont déplacé le travail

La première arborescence utilisait des renvois internes entre les arbres des domaines de premier niveau et ceux des serveurs de noms et des contacts. Ils pouvaient éviter de répéter chaque relation et laisser envisager une répartition de la charge entre serveurs. Mais un renvoi LDAP demande au client de comprendre qu’il doit poursuivre la recherche ailleurs, puis de gérer la réponse de cette autre étape.

Les essais avec ldapsearch ont révélé des interprétations et des traitements incohérents des renvois ; certains clients entraient dans des boucles. Le choix final fut un backend personnalisé, où les données restaient normalisées tandis que le client voyait une représentation dénormalisée, sans renvois internes au serveur. La RFC juge qu’un grand jeu de données exigerait probablement ce backend sur mesure, tandis que des jeux plus petits pourraient fonctionner avec des serveurs prêts à l’emploi. La relation n’avait pas disparu : sa reconstruction avait changé de lieu. RFC 3663

Les renvois entre serveurs répondaient à une autre contrainte. Ils matérialisaient la séparation entre registre et bureau d’enregistrement, souvent exploités par des organisations et sur des réseaux distincts. Or les renvois pouvaient apparaître dans les résultats même s’ils ne correspondaient pas au filtre demandé, jusqu’à remplir une limite de taille généralement fixée à 50 entrées. Le client risquait alors de recevoir des destinations plutôt que les données recherchées. La RFC présente ce problème comme une difficulté de distribution des requêtes, non comme la preuve d’un défaut général de LDAP. RFC 3663 RFC 2251

Un protocole commun ne fait pas un client universel

LDAP fournissait une interface d’accès générique, mais les clients graphiques de l’expérience dépendaient fortement du DIT et du schéma particuliers du service. Ils ne pouvaient pas être réutilisés tels quels face à un autre annuaire LDAP et exploiter toutes ses données. Un client qui masque chaque différence structurelle risque soit d’exposer moins d’informations, soit de devenir trop complexe pour un utilisateur ordinaire. RFC 3663

Cette difficulté se voyait aussi dans l’usage. La RFC rapporte que certains visiteurs du client web pensaient que ce dernier était l’unique accès aux données et comprenaient mal le protocole LDAP ou la séparation entre registre, bureau d’enregistrement et titulaire. Les bibliothèques C et Java permettaient des requêtes imbriquées et des renvois élaborés ; pourtant, les principaux problèmes des clients relevaient souvent de l’ergonomie. Le document reconnaît qu’il était impossible de mesurer précisément leur popularité. Il s’agit d’observations de l’expérience, pas d’une enquête représentative. RFC 3663

Le contrôle des recherches restait lui aussi une contrainte. Une recherche LDAP quelconque pouvait coûter trop cher pour un service public ; l’expérience n’autorisait donc que certaines formes de requêtes. Des utilisateurs demandaient néanmoins comment contourner les limites par des requêtes récursives de dictionnaire, pratique que de nombreux exploitants de WHOIS associaient à l’extraction de données. La section sécurité est sans ambiguïté : l’authentification démontrée par nom distinctif et mot de passe ne devait pas servir de modèle de production. RFC 3663 RFC 2026

La vraie question : où placer la traduction

La valeur historique de la RFC 3663 tient à sa franchise sur les compromis. Un protocole de répertoire commun n’apportait pas une expérience cliente portable. La normalisation limitait la multiplication des objets, mais un backend adapté devait produire la vue attendue par les clients. Les renvois préservaient la séparation entre opérateurs, mais leur efficacité dépendait de l’implémentation cliente, des limites de requête et de rôles organisationnels distincts.

La RFC notait que toute recherche commençait au niveau du registre, même lorsque l’utilisateur visait un bureau d’enregistrement ou un titulaire précis. Elle ne mettait pas en œuvre la découverte par DNS SRV ou NAPTR. Son enquête sur les serveurs LDAP était tout aussi circonscrite : quatre fichiers de zone, des sondes sur le port 389 pour les domaines et les noms d’hôte ldap ou dir, sans recherche SRV. Son estimation d’environ 0,5 % de domaines actifs équipés d’un serveur LDAP dans cet échantillon ne décrit ni l’Internet entier ni la situation actuelle. RFC 3663

Le choix n’opposait donc pas seulement un arbre à une base relationnelle. Il fallait décider qui ferait la traduction entre l’enregistrement relationnel, la vue de répertoire, la destination du renvoi et la question de l’utilisateur. Le pilote en a confié une partie à un serveur spécialisé et à des clients avertis, plutôt qu’à des millions d’objets répétés ou à des chaînes de renvois fragiles. Le protocole rendait les éléments reconnaissables ; il ne fournissait pas à lui seul le chemin.

Sources