Summary

  • Le rapport Berkeley de 1984 décrivait BIND comme un service de noms pour les environnements Unix distribués ; il ne prétendait ni inventer le DNS ni avoir écrit son premier serveur.
  • En 1987, les guides documentaient BIND parmi les logiciels fournis avec 4.3BSD. Deux ans plus tard, un guide Internet le présentait comme un moyen intégré de remplacer la résolution fondée sur /etc/hosts.
  • Le changement était opérationnel : les spécifications décrivaient un comportement commun, tandis que la distribution du logiciel et les zones maintenues localement permettaient aux administrateurs de publier les noms de leur réseau.

Il fallait davantage qu’un protocole : un serveur à lancer et des données à maintenir

Un système de noms peut être élégant sur le papier sans modifier le travail quotidien. Il faut installer un serveur, lui fournir des données, les tenir à jour et faire passer les requêtes locales par le bon résolveur. La contribution de Berkeley au DNS naissant fut de rendre ce travail compatible avec l’environnement Unix.

En 1984, Douglas Terry, Mark Painter, David Riggle et Songnian Zhou publièrent un rapport technique sur le serveur Berkeley Internet Name Domain. Son résumé décrit une façon commune de nommer les ressources dans des environnements Unix distribués, d’y stocker des informations et de les récupérer, ainsi qu’un espace hiérarchique partagé entre des domaines correspondant à des entités administratives. Il s’agit d’un modèle logiciel et opérationnel, non d’une revendication d’invention du DNS.

Paul Mockapetris avait déjà écrit un serveur antérieur, Jeeves, pour USC-ISI et SRI-NIC ; l’historique rédigé par ISC distingue ce serveur du projet Berkeley.

La question pratique de BIND était de permettre à une machine Unix de participer à un système où les données étaient réparties entre plusieurs domaines administratifs. La réponse associait un serveur, des fichiers locaux et le chemin de résolution déjà utilisé par l’hôte. L’administrateur d’un domaine pouvait gérer les enregistrements faisant autorité pour sa partie de l’arbre ; un résolveur interrogeait les serveurs concernés et mettait les réponses en cache. L’espace de noms était distribué parce que les données et les responsabilités l’étaient, sans obliger chaque utilisateur à connaître l’emplacement de toutes les machines.

Le réseau en service a aussi modifié les spécifications

La chronologie est révélatrice. Les premières descriptions du DNS paraissent dans les RFC 882 et 883, en 1983. En janvier 1986, la RFC 973 de Paul Mockapetris consigne déjà les changements, les consignes d’exploitation, les problèmes observés et les limites du système alors utilisé. Elle précise que les changements largement employés doivent être considérés comme faisant partie de la spécification. Les implémentations et les opérateurs alimentaient donc le texte du protocole au fil de son fonctionnement.

Les versions révisées, RFC 1034 et RFC 1035, paraissent en novembre 1987. Elles définissent les concepts du DNS et ses détails d’implémentation. Des règles communes sur les noms, les enregistrements, les requêtes, les caches et les délégations étaient indispensables. Mais les RFC ne constituaient pas un logiciel que l’administrateur pouvait installer. Il fallait aussi un programme et des instructions d’exploitation.

Le rapport de Berkeley de 1984 présente BIND comme un service pour les ressources Unix distribuées. L’historique de BIND publié par ISC nomme l’équipe initiale et indique que le Computer Systems Research Group maintint le logiciel jusqu’à la version 4.8.3. Ce récit rétrospectif établit une filiation de développement, pas un décompte des installations.

La distribution de BSD a rendu le service accessible aux administrateurs

Une trace contemporaine figure dans la RFC 1033, le guide d’exploitation des domaines publié en novembre 1987. Son annexe porte explicitement sur BIND « distribué avec 4.3 BSD UNIX ». Elle explique les fichiers de démarrage et de cache propres à BIND, dont named.boot, et donne des exemples de zones. Elle ne prétend pas que chaque installation BSD faisait tourner un serveur de noms. Elle montre que les administrateurs pouvaient recevoir BIND dans une distribution Unix familière et trouver des consignes pour le configurer.

Ce conditionnement réduisait le coût de l’essai. Il n’était plus nécessaire d’écrire un serveur DNS pour créer un domaine. L’administrateur pouvait lancer le serveur avec un fichier d’amorçage, charger les données de zone, répondre aux requêtes locales et interroger d’autres serveurs lorsque le nom sortait de son autorité. Il restait du travail : les enregistrements devaient être exacts, les délégations cohérentes avec le domaine parent et les mises à jour suivies. BIND fournissait un outil en état de marche, pas une garantie de justesse.

La description la plus concrète vient deux ans plus tard. Dans la RFC 1118, Ed Krol décrit BIND comme intégré à 4.3BSD et utilisé pour consulter et stocker les noms d’hôtes, adresses, agents de messagerie et autres informations. Il indique que ce système remplaçait la résolution reposant sur /etc/hosts. Son exemple de l’Université de l’Illinois à Urbana-Champaign rend le changement d’échelle visible : seuls quelques hôtes figuraient dans la table distribuée par SRI ; la plupart des noms du domaine universitaire résidaient dans les tables BIND locales. Ils restaient accessibles aux autres hôtes équipés de BIND ou d’un autre résolveur DNS.

Il ne s’agissait pas de choisir entre une base unique et l’absence de coordination. SRI distribuait encore une table d’hôtes ; le DNS permettait à chaque institution de gérer un espace local plus vaste et de le rendre consultable selon des règles partagées. La RFC 1118 note aussi que BIND pouvait publier des informations de routage du courrier pour des machines internes qui n’étaient pas directement joignables par IP, notamment celles accessibles par UUCP. Un nom pouvait maintenir une référence de service alors même que l’emplacement réseau de l’hôte changeait.

Une autorité locale, avec des responsabilités locales

La frontière opérationnelle était plus précise que ne le laisse parfois entendre le terme « distribué ». Berkeley puis ses successeurs distribuaient le logiciel. Les documents de protocole décrivaient un comportement commun. Les administrateurs de chaque domaine géraient les enregistrements de leur partie de l’arbre. Les résolveurs et les serveurs exécutaient les requêtes. Aucun de ces éléments ne remplaçait les autres. Une zone périmée pouvait répondre de façon cohérente mais erronée ; une délégation désaccordée pouvait faire échouer un nom même si BIND tournait correctement.

La priorité donnée plus tard par Heng Lu au code en fonctionnement offre ici une question d’analyse, pas une affirmation sur les intentions des auteurs de BIND : que recevait et faisait concrètement un administrateur ? Les sources montrent un enchaînement entre un rapport de conception, un système ajusté à l’expérience, un logiciel fourni avec 4.3BSD et des noms locaux maintenus par les opérateurs. La publication comptait, mais elle ne remplissait pas la zone d’une université et ne répondait pas aux requêtes de ses usagers.

Les sources ont aussi leurs limites. La RFC 1033 établit la distribution avec 4.3BSD ; la RFC 1118 décrit son intégration et un exemple universitaire. Elles ne prouvent ni une installation universelle, ni une cause unique de l’adoption du DNS, ni la disparition de tous les fichiers d’hôtes. Le point historique défendable est plus précis : BIND a contribué à faire du DNS un service Unix qu’un administrateur pouvait exploiter. Chaque domaine pouvait gérer sa partie tout en restant interopérable avec le reste de l’arbre.

Sources