Mon blog

Le DNS est à la base de la plupart des transactions sur Internet. Presque toutes commencent en effet par une requête DNS. Par exemple si vous récupérez un fichier via BitTorrent (dont on pourrait penser qu'il n'utilise pas le DNS), le tracker est souvent trouvé via une URL donc via le DNS. Même si vous utilisez un système récent, tracker-less (celui-ci étant remplacé par une DHT), vous avez probablement trouvé les coordonnées du fichier qui vous intéressait via le Web donc via le DNS. Bref, si le DNS est en panne, il n'y a presque plus rien qui marche. Pourtant, à une époque, l'Internet fonctionnait sans le DNS. Comment s'est faite la transition ? Qu'est-ce qu'il y avait avant ?

Vue l'énorme quantité d'articles soi-disant historiques de vulgarisation sur les origines du DNS, vue la quantité de bêtises journalistiques qui ont été écrites sur ce sujet, il peut sembler difficile de remonter aux vraies origines et de trouver ce qui s'est passé. Pourtant, la plupart des acteurs de ce changement sont encore vivants et beaucoup ont documenté leurs efforts.

Commençons par les pères du DNS eux-même. Paul Mockapetris et Kevin Dunlap ont documenté les débuts de ce protocole en 1988, dans « Development of the Domain Name System » (le fichier PDF en question est une numérisation de l'original papier, il ne semble pas que la forme numérique originale aie été conservée ; même chose pour les autres articles de la série).

Tout commença, racontent les auteurs, en 1982, lorsque l'ancien système de nommage, HOSTS.TXT (qui était spécifié dans le RFC 608), montrait trop clairement ses limites, avec l'augmentation de taille de l'Internet. Plusieurs candidats avaient été envisagés pour son remplacement comme IEN 116 ou comme le système Grapevine de Xerox. Le premier était jugé trop simple, le second beaucoup trop compliqué (il essayait de tout faire, contrairement à la méthode qui a assuré le succès de l'Internet, faire des systèmes simples qui assurent 95 % des fonctions, sans chercher à tout résoudre). Une curiosité : dans Grapevine, les noms étaient hiérarchiques, comme dans le DNS, mais le nombre de niveaux était fixe (alors qu'un nom de domaine peut avoir un seul composant - par exemple dk, deux, trois, ou plus - par exemple ns1.dnsar.ati.tn). Grapevine n'avait que deux niveaux, le registre et la machine. Le travail commença donc sur le protocole DNS. (Cela n'apparait pas dans l'article mais, oralement, Paul Mockapetris raconte qu'il avait hérité de cette tâche car il était le plus débutant et que ce service DNS n'était pas considéré comme essentiel.) Et c'est là qu'on dispose d'une autre source, les fameux RFC puisque tous ont été conservés (parfois sous forme papier, nécessitant une renumérisation). Le DNS est donc né officiellement avec les RFC 882 et RFC 883 (la norme actuelle figure dans les RFC 1034 et RFC 1035).

Il semble que ce soit vers 1985 que certaines machines commencèrent à n'utiliser que le DNS pour accéder à l'information. (Je me souviens bien qu'au début des années 1990, il était fréquent que des documents comme les FAQ indiquent les adresses IP des serveurs cités, car certains « vieux de la vieille » n'avaient pas confiance dans le DNS qui, il est vrai, n'avait pas toujours la fiabilité d'aujourd'hui.)

L'article de Mockapetris et Dunlap détaille ensuite les principes fondateurs du DNS : nommage hiérarchique, compromis entre la simplicité et les demandes de certains enthousiastes qui voulaient en faire une vraie base de données distribuée, absence de sémantique dans les noms (un serveur SMTP n'est pas forcé de s'appeler smtp.example.net et on ne peut pas savoir, juste en regardant un nom, où sont les frontières des zones).

Parmi les choix qui se présentaient aux auteurs du nouveau protocole, la détermination du niveau de souplesse nécessaire. Il était prévu que d'autres acteurs que le monde Internet utilisent le nouveau protocole, ce qui avait mené à l'introduction des classes. Il y avait même l'idée qu'il y aurait une classe ISO alors que, finalement, le projet OSI avait développé sa propre usine à gaz, X.500, qui a sombré avec le reste de ce projet. Aujourd'hui, les classes continuent à utiliser deux octets dans chaque enregistrement DNS, sans servir à rien (et il est probable que la plupart des logiciels seraient très déroutés par d'autres classes que la classe IN, contrairement à ce que pensaient les promoteurs de Net4D).

La fin de l'article décrit le déploiement du DNS en 1988. Le RFC 1031 contenait une liste des mises en œuvre du DNS (les deux plus importantes étant BIND, toujours là, et Jeeves, bien oublié). À ce moment, HOSTS.TXT contenait encore 5 500 noms alors que le DNS en avait... 20 000 (depuis, le comptage est devenu impossible mais il y a certainement aujourd'hui des centaines de millions de noms).

Une section entière est dédiée aux serveurs de noms de la racine, ceux qui doivent répondre pour tous les noms, en général en renvoyant vers les serveurs du TLD. Ils n'étaient que sept à l'époque (aujourd'hui, il est difficile de donner le nombre exact). Quatre étaient des Unix avec BIND, trois des TOPS-20 avec Jeeves. Le trafic sur un serveur racine atteignait la valeur pharamineuse de... une requête par seconde (aujourd'hui, chaque machine physique voit passer plusieurs milliers, voire dizaines de milliers de requêtes par seconde).

Une fois le protocole défini, il restait une importante décision à prendre, sur le schéma de nommage. Le RFC 920 a été le premier à se pencher sur la question, sur laquelle on peut aussi consulter le passionnant article d'Elizabeth Feinler.

Cela, c'était du protocole et de l'organisation. Et le code ? Il existe d'autres articles sur les premières mises en œuvre du DNS :

• « The Berkeley Internet Name Domain Server »,
• « A Name Server Database »,
• « The Design and Implementation of a "Domain Names" Resolver »,
• « The Design and Implementation of the BIND Servers »,
• « Distributed Name Servers: Naming and Caching in Large Distributed Computing Environments ».

Dans A Name Server Database, l'auteur, David Riggle, se penche sur la partie « Stockage et recupération des données » d'un serveur de noms. L'article est très détaillé techniquement et discute même les plus petits détails. Au moment de l'article, en 1984, les TLD que nous connaissons n'existaient pas encore. Le premier schéma montre donc un arbre où l'Université de Berkeley est sous .ARPA. De même, la classe donnée comme exemple n'est pas IN (Internet) mais CS (CSnet). Et l'article mentionne comme « utile » l'option de recherche inverse du DNS, IQUERY (RFC 1035, section 6.4.2), bien oubliée aujourd'hui (car inutilisable en pratique : il faut connaitre le serveur faisant autorité dès le début, elle ne permet pas de le trouver en partant de la racine ; cf. RFC 3425) mais qui a été conscienceusement implémentée. Enfin, les chiffres n'étaient pas du tout les mêmes qu'aujourd'hui. L'auteur cite ainsi un bon résultat : faire tenir 300 noms de domaine dans 64k de mémoire... Le programme avait été écrit en C sur un Vax 11/780 Unix BSD 4.2. Pas question évidemment de réserver une telle machine pour un seul projet et les essais devaient coexister avec plein d'autres travaux, la machine ayant en permanence une charge entre 5 et 10...

Comme dans les autres textes sur le DNS de l'époque, des tas d'utilisations sont envisagées comme de stocker la liste des abonnés d'une liste de diffusion ou bien d'associer employé et numéro de bureau. On voit donc que rien n'est plus faux que la théorie selon laquelle le DNS n'aurait été conçu que pour trouver une adresse IP à partir d'un nom.

La première idée de l'implémenteur est de faire une base de données sur disque qui soit maintenue à la main, en éditant un fichier. Le serveur de noms, lui, ne la modifie jamais. En cas de crash, il n'y a donc pas de problème, il peut toujours repartir du fichier.

La seconde idée importante est de ne pas stocker les données sous la forme « évidente » d'un arbre mais sous la forme d'une table de hachage, indexée par le FQDN. La plupart des noms cherchés sont en effet des feuilles de l'arbre du DNS et la recherche des données nécessiterait donc un parcours de l'arbre dans toute sa profondeur. (La possibilité d'utiliser une « vraie » base de données comme Ingres est considérée dans l'article et écartée pour des raisons de performance.)

Dans The design and implementation of the Berkeley Internet Name Domain servers, Songnian Zhou met l'accent est mis sur le logiciel qui va utiliser cette base pour répondre aux questions posées. Mais, comme les autres articles de la série, il parle aussi de questions plus fondamentales, voire philosophiques. De nos jours, les articles seraient bien spécialisés, avec des rôles bien déterminés. Mais, à l'époque, on pouvait commencer un article sur l'implémentation du serveur en parlant des règles de nommage et en évoquant celles d'UUCP (plus exactement, celles d'UUCP à l'époque, fondées sur des noms relatifs, indiquant le chemin à parcourir).

Et le serveur lui-même, dans tout cela ? Le DNS de l'époque ne faisait pas de distinction claire entre un serveur faisant autorité et un cache récursif et le logiciel allait donc faire les deux, ce que BIND va faire jusqu'à la version 9 incluse (dans la version 10, les deux fonctions sont complètement séparées, et on peut même compiler le logiciel avec une seule des deux). Par contre, une fonction non prévue par les RFC allait être ajoutée : la mise à jour dynamique des données, qui ne sera normalisée que dans le RFC 2136, sous une forme très proche de ce que décrit l'article (qui explique, par exemple, pourquoi seul le serveur maître peut traiter ces mises à jour).

La programmation de ce nouveau logiciel n'avait pas été évidente. Par exemple, le serveur de noms est naturellement parallèle puisqu'il doit répondre à des requêtes simultanées de plusieurs clients. Le mécanisme normal de parallélisme sur les Unix BSD de l'époque était le processus mais BSD n'avait pas de mémoire partagée, ce qui rendait difficile (du moins c'est ainsi qu'on le voyait à l'époque) la communication entre les processus. Finalement, BIND aura un seul processus et utilisera select() pour traiter les questions. Dans un autre ordre d'idées, c'est dans cet article qu'apparait la spécification du format de fichier de configuration que BIND gardera jusqu'à la version 4 incluse. Quant à la mise en œuvre de la mise à jour dynamique, elle était fort complexe et fait l'objet de plusieurs pages.

La partie la plus amusante de la lecture d'un article aussi ancien est évidemment celle consacrée aux projets futurs. Ainsi, l'auteur perçoit bien l'importance d'ajouter des ACL et des mécanismes d'authentification (complètement absents de la première version). Moins bien analysée est l'idée d'utiliser le DNS pour stocker les informations sur l'utilisateur, auxquelles on accédait à l'époque avec la commande finger (qui avait été normalisée dans le RFC 742 et qui est aujourd'hui dans le RFC 1288). De nombreuses années avant ENUM ou .tel, la vision de l'enregistrement DNS User Information, UINFO (qui ne sera finalement pas adopté) est stimulante.