Résumé

  • La RFC 849 a montré qu'un fichier HOSTS.TXT exact au NIC ne garantissait pas la fraîcheur des copies effectivement utilisées par les sites.
  • Sa combinaison préférée envoyait rapidement une mise à jour une seule fois, puis confiait la reprise à un contrôle de version local au démarrage et à une interrogation périodique.

Une machine éteinte ne refuse pas une mise à jour. Elle ne la voit pas. Lorsqu'elle redémarre, elle peut reprendre son service sans alarme, avec une table des hôtes qui appartient encore à la veille.

Le fichier maître, lui, peut être parfaitement correct. C'est précisément ce qui rend le défaut trompeur : l'erreur ne se trouve ni dans l'enregistrement central, ni forcément dans le logiciel de résolution. Elle se loge dans la transition inachevée entre les deux.

La RFC 849, publiée par Mark Crispin en mai 1983 sous le titre Suggestions for Improved Host Table Distribution, a donné une forme technique à cette transition. Le texte prévient d'emblée que ses propositions ne sont pas des normes. Il s'agit d'une véritable demande de commentaires, dans l'espoir qu'un consensus prépare un standard ultérieur. On ne peut donc pas en déduire qu'un protocole a été déployé. En revanche, on peut y lire une anatomie particulièrement nette de la fraîcheur.

Le fichier commun avait déjà plusieurs vies

La table centralisée venait d'une organisation plus ancienne. La RFC 608 décrivait une source maintenue par le NIC, capable de produire périodiquement un fichier ASCII de noms, d'adresses et d'attributs. Le rythme envisagé était hebdomadaire ou adapté aux circonstances. Le résultat, <NETINFO>HOSTS.TXT, pouvait être récupéré par FTP.

Une source unique réglait la question de la version publiée par le NIC. Elle ne réglait pas la date à laquelle chaque site l'utiliserait.

En 1982, la RFC 810 a étendu le format aux besoins de l'Internet du DoD : réseaux, passerelles, hôtes, systèmes et certains protocoles. La table était accessible par FTP anonyme auprès de SRI-NIC ou par le Host Name Server. Mais la même spécification attribuait à l'utilisateur la responsabilité de traduire cette table dans le format dont il avait besoin.

La chaîne comptait donc déjà quatre objets : le maître, les octets reçus, la représentation locale après conversion et l'état actif consulté par les programmes. Quatre objets proches, mais pas interchangeables.

La RFC 811 a ajouté un service en ligne sur le port TCP 101. HNAME cherchait une entrée par nom, HADDR par adresse, et ALL renvoyait la table entière entre BEGIN et END. Le service facilitait l'accès à l'information courante du NIC. Il ne disait toujours pas, à faible coût, si le fichier déjà installé sur un site était de cette même édition.

Deux échecs opposés naissaient de la même ignorance

Crispin expliquait pourquoi les sites gardaient leur propre copie. SRI-NIC n'était pas jugé assez disponible pour constituer à lui seul un service de noms permanent. Le NIC permettait pourtant de vider tout le registre et proposait le fichier en FTP anonyme. Le maillon manquant était humain et temporel : quelqu'un devait savoir qu'une nouvelle version existait. Les annonces de mise à jour, observait-il, n'avaient pas toujours été régulières.

Un site pouvait alors conserver une vieille table sans le savoir. Il pouvait aussi faire l'inverse : transférer à nouveau un fichier identique, faute de moyen automatisé pour comparer son exemplaire avec celui du NIC.

Ces deux coûts — données périmées et transfert inutile — avaient la même cause. La présence d'un fichier téléchargeable ne fournissait pas la preuve qu'il avait changé.

Le numéro de génération transformait un transfert en décision

La deuxième proposition de la RFC 849 consistait à faire répondre le NIC sur la « version » courante de la table. Pour Tenex et TOPS-20, le numéro de génération du fichier convenait naturellement. Crispin conservait déjà un SYSTEM:HOSTS.TXT portant la même génération que le fichier du NIC et vérifiait de temps à autre si le numéro distant avait évolué. Il voulait automatiser cette opération.

Ce numéro n'attestait pas la vérité de chaque ligne. Il ne prouvait ni la conversion locale ni l'activation. Il permettait seulement de distinguer deux états : même édition, ou édition différente.

Cette modestie rendait le signal utile. Si le numéro n'avait pas bougé, il devenait inutile de transporter toute la table. S'il avait changé, le site disposait d'une preuve simple que sa copie méritait une reprise. L'observation légère précédait l'opération lourde.

La poussée rapide fabriquait une dette de relance

La première proposition allait dans l'autre sens. Chaque site coopérant aurait exécuté un serveur à l'écoute d'un port enregistré et accepté les mises à jour provenant de sites dits « trusted », en particulier SRI-NIC. Tant que le destinataire était en ligne, la nouvelle table pouvait arriver presque immédiatement.

Mais une poussée n'est complète que si le destinataire répond. Pour en faire une garantie, le NIC devait mémoriser les machines hors service et réessayer plus tard. À côté du registre des noms apparaissait ainsi un registre mouvant des abonnés, des tentatives, des échecs et des obligations de reprise. La vitesse obtenue sur le chemin heureux se payait par un état central croissant sur le chemin défaillant.

Le texte proposait aussi une somme de contrôle pour vérifier que le registre mis à jour était arrivé complet et intact. La portée de cette preuve doit rester exacte. La RFC 849 ne définit pas une authentification cryptographique de la source, ni une défense contre un remplacement hostile, ni une validation du sens de chaque entrée. La somme porte sur l'intégrité de la livraison. Un fichier intact peut contenir une erreur de registre ; un bon fichier peut encore échouer pendant sa conversion.

Le courrier déplaçait le paquet, pas l'état actif

Une troisième voie consistait à envoyer la table par courrier électronique à une liste de destinataires, chacun organisant ensuite sa procédure. C'était simple côté NIC. Crispin y voyait pourtant de nombreux problèmes : le courrier se prêtait mal au transport en masse d'un fichier appelé à grossir vers une population croissante.

Surtout, « message livré » n'est pas « table utilisée ». Entre les deux restent la file d'attente, la boîte aux lettres, l'extraction, la conversion et le basculement du résolveur. Le courrier pouvait transporter l'objet sans rendre visible la fin de l'opération.

La quatrième solution n'exigeait pas l'infaillibilité d'un canal

La préférence de Crispin allait à une combinaison. Le NIC pousserait l'actualisation une seule fois vers les hôtes inscrits. Il ne conserverait pas indéfiniment la dette des destinataires absents. À chaque démarrage, le site exécuterait un programme qui interrogerait le NIC, récupérerait une nouvelle version si nécessaire, puis pourrait effectuer une vérification périodique — quotidienne dans l'exemple — comme filet supplémentaire.

La poussée devenait le chemin rapide. L'interrogation au démarrage devenait le chemin de réparation pour une machine qui s'était trouvée éteinte au mauvais moment. Le contrôle périodique couvrait les systèmes qui n'avaient ni reçu l'annonce ni redémarré. Le numéro de version empêchait cette reprise de devenir un téléchargement quotidien à l'aveugle.

La répartition des responsabilités est plus importante que l'addition de deux techniques. Le NIC n'avait plus à conserver pour toujours l'histoire privée de disponibilité de chaque hôte. Le site, seul à pouvoir observer avec certitude sa version installée, prenait en charge sa propre récupération.

Cette organisation ne promettait pas une convergence instantanée. Le NIC pouvait être indisponible au retour du site. Le transfert pouvait s'interrompre, la somme différer, la conversion échouer ou l'ancien fichier rester actif. Mais chaque échec avait désormais une frontière observable et un prochain geste. Il n'était plus dissous dans l'affirmation générale « HOSTS.TXT est à jour ».

Le DNS a distribué l'autorité sans abolir le délai

Six mois plus tard, la RFC 881 constatait que presque tous les hôtes de l'Internet utilisaient alors une forme de table dérivée du maître HOSTS.TXT du NIC. Son calendrier envisageait une coexistence entre cette table et les noms de domaine.

La RFC 882 a posé le problème d'échelle : la taille de la table mondiale et surtout la fréquence de ses modifications approchaient la limite du gérable. Il fallait une base distribuée. La RFC 883 a réparti l'espace de noms entre des serveurs, distingué les zones faisant autorité des données en cache et prévu des rafraîchissements périodiques. Elle précisait qu'une modification du maître ne changeait pas toutes les copies immédiatement ; elle se propageait progressivement.

Il serait faux de présenter ce mouvement comme l'adoption de la RFC 849. Les propositions de Crispin n'étaient pas normalisées et le DNS répondait à une architecture plus large. Le lien historique est une discipline, non une filiation : une copie distribuée a un âge, une édition, un mécanisme de rafraîchissement et un comportement en cas d'échec.

La fraîcheur appartient à la dernière transition achevée

Un registre faisant autorité peut dire quelle association nom-adresse il reconnaît aujourd'hui. Cette déclaration ne réveille pas une machine éteinte. Une notification ne convertit pas un fichier. Une somme de contrôle ne l'active pas. Un numéro de génération ne change pas la base consultée par une application.

La RFC 849 laisse ainsi une grammaire de preuve : édition publiée, annonce tentée, octets reçus, intégrité acceptée, conversion terminée, état actif observé, reprise disponible. Le mot « mise à jour » ne devrait remplacer aucune de ces étapes.

Au seuil entre la grande table centrale et le service de noms distribué, le document a isolé une vérité simple. La publication est un événement chez la source. La fraîcheur est une condition vérifiée chez celui qui utilise les données. Le registre peut être à jour tandis que le réseau demeure en retard.

Sources