Résumé

  • RFC 1279 représentait les domaines dans X.500 tout en séparant le domaine de l’organisation et la boîte aux lettres de la personne. Puisque les objets différaient, un alias ne convenait pas pour les relier.
  • AssociatedDomain et AssociatedName conservaient deux affirmations orientées. L’entrée de domaine devait rester sobre et pointer vers l’information organisationnelle au lieu de la recopier, sans supposer une relation univoque.
  • Le transfert de zone pouvait alimenter les enregistrements DNS d’un DSA, mais devait laisser intacts les attributs non DNS. Transport, écriture, conservation, lien, consultation et décision demeuraient des faits distincts.

Un projet expérimental, pas un remplacement déjà accompli

Publié en novembre 1991, RFC 1279, X.500 and Domains, définissait une proposition Experimental. Il cherchait à représenter la hiérarchie DNS dans le Directory Information Tree de X.500, afin que les outils d’annuaire puissent parcourir les domaines, retrouver leurs responsables et éventuellement participer à leur gestion.

Le texte ne confondait pas cette ambition avec un état de production. Pour les premiers travaux, il jugeait plus probable que les données restent maîtrisées dans les bases de domaines puis soient chargées dans le DIT. Son annexe décrivait des étapes : outils de consultation, transferts répétés, ajout de liens, distribution sur plusieurs DSA, comparaison avec un serveur DNS émulé, puis seulement maîtrise éventuelle de certaines branches DNS dans le DIT.

Une feuille de route n’est pas un compte rendu d’exécution. Un transfert possible n’est pas un transfert terminé, et la dernière étape d’un plan ne prouve ni adoption ni résultat.

Le nom d’un domaine devenait une suite de DomainComponent. Une partie locale de boîte RFC 822 pouvait prolonger cette branche. Ailleurs dans le même annuaire vivaient les entrées d’organisations, d’unités, de personnes et de rôles.

La ressemblance des libellés ne supprimait pas la différence des objets. UCL.AC.UK désignait une position dans l’espace DNS ; University College London était une organisation. Une boîte aux lettres pouvait être associée à une personne sans devenir cette personne.

RFC 1279 en tirait une conséquence nette : l’aliasing n’était pas le bon mécanisme. L’alias laisse entendre qu’un autre nom désigne le même objet. Ici, le système devait conserver une relation entre deux objets autonomes.

Deux pointeurs, deux points de départ

Le projet employait AssociatedDomain depuis une entrée organisationnelle vers le domaine, et AssociatedName depuis l’entrée de domaine vers l’organisation. Cette réciprocité apparente ne devait pas être reconstruite automatiquement.

Chaque direction appartenait à une assertion particulière. La première disait quel domaine était associé à une organisation ; la seconde indiquait quelle entrée organisationnelle enrichissait le domaine. En les conservant séparément, l’annuaire pouvait montrer qu’un lien retour manquait, qu’il avait une autre source ou qu’il avait été ajouté plus tard.

La relation n’était pas nécessairement univoque. Le RFC signalait qu’un domaine pouvait correspondre à plusieurs organisations, et qu’une organisation pouvait disposer de plusieurs domaines. Réduire ce graphe à un champ « propriétaire » unique aurait détruit une information que le document avait expressément préservée.

Un pointeur n’attestait donc ni propriété juridique, ni identité authentifiée, ni droit d’agir. La proximité d’une adresse de messagerie avec une fiche de personne ne certifiait pas l’utilisateur. Le lien exprimait une association documentée, avec une direction et une source, pas toutes les conclusions susceptibles d’être projetées sur elle.

Une fiche sobre vaut mieux que deux vérités concurrentes

Les attributs propres au domaine pouvaient rester sur sa fiche. Les enregistrements DNS et certaines informations de gestion y avaient leur place. Mais lorsque la branche organisationnelle détenait déjà l’information pertinente, RFC 1279 recommandait de ne pas la dupliquer. La fiche DNS devait plutôt rester sobre et pointer vers l’entrée de référence.

Cette règle évitait surtout un conflit de responsabilité. Deux copies d’un numéro de téléphone possèdent deux horloges de mise à jour. Si une mutation de personnel corrige l’entrée d’organisation mais pas les domaines liés, les deux valeurs restent lisibles et plausibles. L’interface ne sait plus laquelle a mandat pour parler au présent.

La répétition peut même imiter la corroboration. Dix domaines affichant le même ancien contact ne constituent pas dix sources ; ils peuvent être dix descendants d’une seule copie oubliée.

Avec un pointeur, l’organisation garde la maîtrise de ses attributs descriptifs et le domaine garde la maîtrise de son association. Une vue peut réunir les deux pour le lecteur, sans transformer cette composition visuelle en transfert d’autorité.

La correction devient également réversible. On modifie le lien erroné sans réécrire l’organisation ; on met à jour le contact à sa source sans rechercher toutes les reproductions. La provenance survit à la commodité de l’affichage.

Le texte d’un RR ne reproduisait pas l’horloge DNS

RFC 1279 proposait un format textuel pour les resource records DNS dans le DIT. Les noms devaient être complets et chaque record devait porter son TTL. Un attribut DNSRecord unique rendait le mécanisme extensible aux nouveaux types.

Le contenu devait être équivalent à celui du DNS pour circuler dans les deux sens. Pourtant, le texte excluait l’émulation du cache DNS et du traitement des TTL par l’annuaire OSI. Les entrées maîtresses étaient supposées entretenues par transfert de zone ou mécanisme équivalent.

Un nombre TTL présent dans une chaîne n’est pas une preuve qu’un compte à rebours identique s’exécute. RFC 1035 donnait au TTL un rôle dans l’usage et l’expiration du cache DNS. Les données autoritatives de zone, les données mises en cache, le refresh et l’expiry ne sont pas interchangeables. Copier une représentation ne copie pas tout son comportement temporel.

Il faut donc conserver l’origine DNS, la version de zone, le début et la fin du transfert, l’instant d’acceptation par le DSA, les refresh ultérieurs et la consultation qui a rendu la valeur visible. Sans cette chaîne, le TTL reste un champ historique privé de son contexte opérationnel.

Le transporteur n’héritait pas des attributs voisins

L’annexe proposait un outil de transfert de zone entre serveur DNS et DSA. Lorsqu’il écrivait dans le DSA, les attributs qui n’étaient pas des records DNS devaient rester intacts.

Cette contrainte dessinait une frontière de pouvoir. L’outil pouvait modifier la famille de données qu’il transportait. La cohabitation dans une même entrée ne lui donnait aucun mandat sur les coordonnées du gestionnaire, la description de l’organisation, les pointeurs ou d’autres attributs.

Une connexion acceptée ne prouve pas un transfert complet. Un transfert complet ne garantit pas chaque validation. Une écriture DNS ne prouve la conservation des attributs voisins que si les états avant et après sont observés. Une consultation réussie ne démontre pas l’action d’un utilisateur.

Le dossier durable sépare donc l’état de zone, la demande, l’ensemble reçu, l’écriture acceptée, les attributs préservés, les liens, la réponse de consultation et l’action ultérieure. Le mot « synchronisé » ne suffit pas.

La sécurité restait une possibilité, non un résultat

RFC 1279 disait ne pas traiter directement les questions de sécurité. Il estimait que certaines capacités de X.500 pourraient ouvrir une manière plus sûre d’accéder aux informations de domaine et de les gérer. Le conditionnel interdit de transformer cette perspective en authentification réalisée.

RFC 1309 décrivit ensuite le cadre général : des entrées représentent des objets, et des organisations peuvent maîtriser localement leurs informations dans des DSA distribués. Cela explique l’intérêt de séparer les objets, mais ne fournit aucun déploiement manquant au projet RFC 1279.

Sources et limites de preuve

RFC 1279 fonde la représentation des domaines, le refus de l’alias, les deux liens, la non-duplication, la limite du transfert et le parcours expérimental. RFC 1274 confirme les attributs d’association et les classes de domaine. RFC 1035 apporte le contexte du TTL et des zones DNS. RFC 1309 n’apporte que le modèle général des entrées X.500 et de la maîtrise locale distribuée.

Ces sources ne prouvent ni déploiement nommé, ni propriété juridique, ni identité authentifiée, ni transfert achevé, ni fraîcheur actuelle, ni consultation réussie, ni effet de sécurité, ni action d’un lecteur.