Résumé

  • La RFC 830 proposait de résoudre le domaine jusqu'à l'adresse de son point de service, puis de confier aux Application Interface Processes une négociation distincte sur le transport et l'application disponibles.
  • Le serveur source parcourait la hiérarchie depuis le label le plus à droite ; les bases intermédiaires restaient locales et disjointes, tandis que les échanges entre composants recevaient un format commun.
  • Les RFC 882 et 883 choisirent une base distribuée de ressources typées, avec zones, autorité, renvois, caches et rafraîchissement. Cette réponse déclarative ne devint pas pour autant une preuve d'exécution.

Deux questions derrière un seul nom

Dans le modèle de la RFC 830, demander un service à un nom complet revenait à poser deux questions. La première était administrative : quel serveur représente le domaine de destination ? La seconde était opérationnelle : quel transport et quelle application ce domaine peut-il offrir pour la demande présente ?

La confusion entre les deux paraît naturelle, car le lecteur attend d'un « service de noms » une adresse finale. Le System for Internet Name Service, ou SINS, s'arrêtait plus tôt. Son service de domaines, indépendant des applications, renvoyait l'adresse du DNS associé au domaine terminal. Une interface d'application prenait ensuite le relais.

Ce découpage suivait la conception de la RFC 819. Un domaine était une juridiction de nommage et de traduction, non une description obligatoire de la topologie. Une organisation pouvait administrer ses enfants et conserver une convention interne différente. Le nom absolu fournissait le point de référence commun ; il ne devait pas absorber toutes les décisions locales.

Le parcours partait de la droite

Le nom proposé plaçait une partie locale devant une suite de domaines, du plus précis au plus général. Pour résoudre la partie domaine, le DNS de la source commençait par le label le plus à droite, celui du domaine supérieur.

Ce DNS jouait le rôle de pivot. Il connaissait l'adresse du serveur du domaine supérieur, puis lui demandait l'étape suivante. Chaque serveur intermédiaire connaissait ses sous-domaines immédiats. Il pouvait répondre par l'adresse du serveur suivant ou transmettre une fois la requête. La RFC refusait cependant qu'il devienne à son tour un pivot durable : la limitation simplifiait le protocole et conservait la coordination du parcours près de la source.

La distribution ne reposait donc pas sur une copie globale. Les DNS terminaux gardaient un petit répertoire des domaines supérieurs. Chaque serveur intermédiaire détenait seulement les correspondances de ses enfants directs. Les contenus nécessaires ne se recouvraient pas et les modifications pouvaient rester locales.

La RFC 830 n'exigeait même pas un format de base commun. Deux domaines pouvaient stocker leur table différemment si leurs échanges respectaient le contrat réseau. La normalisation portait sur le bord observable, pas sur la représentation interne.

L'interface demandait la capacité réelle

Atteindre le DNS terminal ne suffisait pas pour joindre l'application. Le processus source remettait à son AIP le nom complet et le service souhaité. Après résolution du domaine, l'AIP source contactait l'AIP de destination et ouvrait la négociation que le texte appelait « what-can-you-do-for-me ».

Le message pouvait désigner TCP ou UDP, un protocole d'application et un type de service. Une réponse positive comportait un service et une adresse. Dans les exemples TCP, l'adresse rassemblait adresse IP, numéro de protocole et port. Plusieurs adresses pouvaient être rendues ; la RFC préférait cette pluralité, car elle laissait un choix à la source.

Ce choix n'était pas une promesse d'équivalence. Deux adresses d'un domaine multiraccordé pouvaient suivre des chemins ou connaître des états différents. La réponse disait : voici les possibilités déclarées par le point terminal. Elle ne disait pas : chacune réussira.

La réponse la plus originale était l'incompatibilité utile. La source demandait NIFTP pour un transfert de fichiers. La destination ne proposait que FTP pour cette fonction. Si la source connaissait elle aussi FTP, la négociation pouvait choisir ce terrain commun. Le but restait le transfert ; le protocole particulier changeait.

Une conversation vivante n'était pas une autorisation

Le dialogue AIP apportait une information plus actuelle qu'une entrée fixe sur ce que déclarait le processus de destination. Il ne prouvait toutefois ni l'identité de l'utilisateur, ni son droit d'employer le service, ni la capacité disponible, ni la réussite de l'opération suivante.

Les preuves restaient séquentielles. Une résolution correcte pouvait conduire à un refus d'application. Une négociation compatible pouvait être suivie d'un échec de transport. Une connexion établie pouvait finir sur une erreur métier. Aucun de ces résultats ne réécrivait rétroactivement les autres.

Cette séparation protège aussi l'autorité. Le parent d'un domaine pouvait déléguer un nom. Le domaine pouvait publier l'adresse de son point de service. Son AIP pouvait annoncer une capacité. Seule la politique de l'application pouvait accepter l'acte concret. Le mot « disponible » ne transportait pas tous ces pouvoirs.

La minceur se trouvait dans la base, non dans le protocole

SINS adoptait une structure de commande commune pour plusieurs couples : application/AIP, AIP/DNS et AIP/AIP. Les éléments indiquaient nom, service, adresse ou commentaire. Une réponse négative pouvait montrer la partie du nom non résolue et expliquer l'échec.

La base persistante restait légère et locale, mais la conversation distribuée était détaillée. C'est un choix cohérent : ne rendre commun que ce qui doit être compris au moment de l'interopération. Il avait aussi un coût. Chaque domaine terminal devait porter l'intelligence de négociation et partager un vocabulaire de services.

Le cache révélait une autre limite. La RFC 830 savait qu'une résolution complète à chaque transaction serait inefficace. Elle supposait que des implémentations réutiliseraient les résultats, sans faire du cache une fonction normative. La liberté locale gagnait ; la durée, l'expiration et la distinction entre information fraîche et ancienne restaient hors du contrat commun.

Le DNS choisit une autre couche commune

La RFC 881 aborda le passage de HOSTS.TXT. Une table aux noms de domaine devait d'abord coexister avec la table ordinaire. Plus tard, un résolveur remplacerait l'appel de bibliothèque qui lisait la table, de sorte que les applications ne sauraient pas si l'adresse venait d'un fichier ou d'un serveur. Le fichier central finirait par ne garder que les serveurs des domaines supérieurs.

Les RFC 882 et 883 placèrent davantage de structure dans une base distribuée commune. Un nom désignait un ensemble d'informations. La requête ajoutait un type de ressource et, si nécessaire, une classe de protocole. Les serveurs détenaient des zones faisant autorité et des renvois. Les résolveurs poursuivaient la question et conservaient des réponses en cache.

La distinction entre autorité et cache devint explicite. Une zone provenait de données maîtres et de procédures de rafraîchissement. Une donnée en cache provenait d'une résolution antérieure et disparaissait après un délai. Les mêmes octets pouvaient être utiles sans posséder la même provenance.

L'interface locale avec l'application ne nécessitait plus un protocole réseau universel. Un appel de procédure ou de système suffisait. Le contrat partagé couvrait surtout les requêtes aux serveurs, les ressources, les renvois, les transferts de zone et le rafraîchissement.

La branche perdue explique la branche retenue

La RFC 1034 cite la RFC 830 parmi plusieurs propositions de nommage hiérarchique. Elle attribue séparément aux RFC 882 et 883 la base distribuée et les ressources généralisées dont l'expérience conduisit au DNS ultérieur. Il serait donc faux de présenter SINS comme un simple brouillon du DNS moderne.

Les deux conceptions partageaient la délégation et refusaient une table globale complète. Elles différaient sur l'endroit où rendre commune l'intelligence. RFC 830 normalisait une négociation vivante après la résolution du domaine. Le DNS normalisait des ressources déclaratives et la manière de les trouver, les copier et les rafraîchir.

Une donnée déclarative se distribue bien. Elle se met en cache, s'audite et se sert à plusieurs applications. Mais elle ne devient pas un test en direct. Une conversation vivante peut découvrir une alternative actuelle ; elle ajoute dépendance, latence et surface d'attaque. L'histoire n'ordonne pas de choisir toujours l'une. Elle exige de ne pas leur attribuer la même preuve.

Sources