Résumé

  • La RFC 897 distinguait le passage aux noms hiérarchiques du passage d'une table centrale à des serveurs distribués ; un nom en .ARPA pouvait encore être résolu par HOSTS.TXT.
  • La RFC 921 publia ensuite le bilan du premier calendrier : renommage à l'heure, serveurs en retard, plusieurs jalons toujours inachevés.
  • L'existence des machines, le chargement des données, la conversion des applications et l'extinction de l'ancienne table formaient quatre preuves différentes.

Avant le DNS, l'unité apparente du système cachait déjà plusieurs opérations. La RFC 810 décrivait une table des hôtes tenue par le NIC et traduisible par machine. Chaque site devait pourtant la récupérer, la convertir dans son format local et l'installer. La RFC 811 offrait un serveur capable de répondre à une requête ou de livrer la table entière. La présence d'une bonne ligne au centre ne prouvait ni son arrivée ni son utilisation par un programme.

La RFC 881 formula le piège du déploiement. Dès que quelques acteurs utiliseraient des noms à points, ces noms traverseraient le courrier et les communications de tous les autres. Mais attendre que tous les logiciels soient prêts revenait à attendre presque indéfiniment. Le plan fit donc coexister une table de noms de domaine et la table ordinaire, avant de remplacer l'appel de bibliothèque de la table par un résolveur invisible pour la plupart des applications.

Les RFC 882 et RFC 883 définissaient l'autre architecture : données typées, serveurs, zones, délégations, résolveurs et caches. Elles disaient comment le système devait parler. Elles ne pouvaient pas attester qu'un mailer donné avait cessé d'ouvrir un fichier local.

Un nouveau nom dans un ancien chemin

La RFC 897, publiée en février 1984, isola deux transformations. La première changeait le nom lui-même : une chaîne globale et plate devenait une suite hiérarchique. La seconde changeait le support de traduction : des copies locales d'une table centrale cédaient la place à des requêtes dynamiques vers plusieurs serveurs.

Ses quatre étapes rendaient la séparation concrète. On ajoutait d'abord .ARPA aux anciens noms. On ouvrait ensuite quelques domaines. On changeait alors le mécanisme de résolution. Enfin, on permettait de nombreux domaines. L'étape initiale pouvait donc être réalisée par la vieille table. L'orthographe visible ne révélait pas la source de la réponse.

Le suffixe fixe limitait le désordre initial sans annuler la dette de renommage. Un ancien nom pouvait rester quelque temps comme surnom. Cette astuce aidait un destinataire qui conservait l'alias. Elle ne corrigeait pas le carnet d'adresses d'un correspondant, une adresse déjà copiée dans Cc, la réponse à un vieux message ou une liste de diffusion administrée ailleurs. Le coût quittait le périmètre de l'hôte dès que le nom circulait.

La base distribuée devait aussi conserver le lien entre une adresse et le nom principal. Ce lien était une exigence de cohérence, pas une preuve d'identité. Une résolution inverse correcte n'authentifiait ni l'organisation ni la machine qui répondait.

Une obligation différente selon la communauté

Le calendrier initial donnait des dates précises : noms de domaine principaux le 14 mars 1984, abandon des anciens noms le 2 mai, domaines généraux à plusieurs niveaux le 6 juin, domaines d'organisation le 18 juillet, table complète devenue inutile pour la recherche ARPA le 5 septembre, puis plan DDN le 3 octobre.

La politique n'imposait pourtant pas la même migration technique aux deux communautés. La recherche ARPA devait accomplir l'ensemble du passage. La communauté opérationnelle DDN adoptait la nouvelle forme des noms, mais pouvait continuer à résoudre au moyen de la table jusqu'à un calendrier ultérieur fixé par son propre programme. Le NIC devait entretenir cette table.

Deux systèmes pouvaient ainsi partager une syntaxe moderne tout en reposant sur des autorités de données différentes. Une date commune de renommage ne produisait pas une preuve commune de résolution.

La révision conserva la trace de l'échec

La RFC 920 finit par publier en octobre les conditions d'établissement des domaines et un ensemble révisé de domaines de premier niveau. La RFC 897 l'avait attendue en février. Ce retard ne fut pas effacé du récit.

La RFC 921 reprit l'ancien calendrier et l'annota. La table initiale de noms hiérarchiques et le changement de nom de mars avaient été réalisés à l'heure. Les serveurs du domaine ARPA existaient, mais en septembre plutôt qu'en avril. La table des domaines de premier niveau, l'ouverture de nouveaux domaines, les noms multisegments, les noms d'organisations, l'abandon de la table et le plan DDN restaient inachevés.

Le nouveau plan décrivit trois chantiers. Les machines comprenaient serveurs et résolveurs. La base devait être réellement chargée. Les programmes des utilisateurs devaient ensuite appeler les nouvelles procédures. En octobre 1984, les machines avançaient, la base ARPA existait et d'autres domaines étaient amorcés, mais les mailers, Telnet, FTP et autres programmes avaient peu changé.

La révision fixa de nouvelles échéances entre décembre 1984 et octobre 1985. Elle ne certifiait pas leur exécution future. Sa valeur documentaire tient plutôt aux catégories « fait », « fait en retard » et « pas encore fait ». Le calendrier devenait un instrument de mesure au lieu d'une décoration de politique.

Le dernier kilomètre resta dans les applications

En novembre 1987, la RFC 1031 décrivait encore trois états simultanés sur MILNET : table seule, mélange de table et de DNS, DNS seul. Un même hôte pouvait convertir Telnet et FTP avant le courrier, ou faire le contraire. La migration suivait les ressources et les logiciels disponibles, pas un interrupteur central.

Le document indiquait que la plupart des hôtes restaient alors au premier stade. Certaines architectures anciennes ou impossibles à modifier pourraient ne jamais être converties. Après l'arrêt de la table commune, elles auraient besoin d'un accord bilatéral, d'un dépôt communautaire ou d'une table locale. Le secours devenait une nouvelle relation de dépendance.

La RFC 1034 expliqua plus tard le coût de diffusion de HOSTS.TXT et conserva une interface de résolveur capable d'imiter l'ancien appel. Cette compatibilité protégeait les applications, mais elle masquait aussi la provenance réelle d'une réponse à qui ne regardait que l'écran.

Enfin, la RFC 1401 reproduisit une correspondance de 1992 dans laquelle l'IAB qualifiait la transition MILNET d'incomplète et associait les bases divergentes à des échecs de joignabilité. Il s'agit d'une intervention de politique publique, non d'un recensement neutre. Elle montre néanmoins que la coexistence pouvait survivre bien au-delà du premier calendrier.

Sources et limites

Le dossier repose sur les RFC 810, 811, 881, 882, 883, 897, 920, 921, 1031, 1034 et 1401. Elles établissent des mécanismes, des obligations, des dates et des constats documentaires. Elles ne prouvent pas une date universelle d'adoption, la conformité de chaque site, une identité authentifiée, la joignabilité présente ni le comportement d'un produit actuel.