Résumé

  • Le 11 juillet 1997, un opérateur signale qu’un résolveur associe www.internic.net à une adresse d’AlterNIC et classe l’enregistrement parmi les données supplémentaires.
  • L’épisode mêle un conflit sur l’enregistrement des noms commerciaux à une défaillance technique distincte : un résolveur a conservé une correspondance qu’il n’aurait pas dû restituer comme réponse.

Une adresse Web, deux autorités différentes

AlterNIC contestait le rôle de Network Solutions dans l’enregistrement de domaines commerciaux de premier niveau. Le débat portait sur les acteurs autorisés à ajouter des noms comme .com ou .net, et sur les règles qui les encadraient. Pourtant, la trace conservée la plus révélatrice est plus étroite. Le 11 juillet 1997, Kevin Brintnall, opérateur réseau, publie sur NANOG une requête et un extrait de mémoire provenant du serveur de noms de Visi Internet. www.internic.net renvoyait 207.51.48.15 ; la recherche de cette adresse identifiait aragorn.alternic.net.

Dans son extrait, l’adresse inattendue porte la mention addtnl, c’est-à-dire qu’elle provenait des données supplémentaires de la réponse DNS. Brintnall précise aussi que sa mémoire de racine ne contenait aucun indice d’AlterNIC. Dans ce cas précis, l’utilisateur n’avait pas choisi une racine alternative. Une donnée rencontrée au fil de la résolution récursive avait modifié la réponse fournie par ce résolveur pour le serveur Web d’InterNIC.

Cette nuance compte, car les noms en jeu n’exerçaient pas le même pouvoir. La zone racine délègue les noms de premier niveau. Un bureau d’enregistrement accepte des inscriptions sous un domaine de premier niveau. Un résolveur récursif suit les délégations DNS et garde des données en mémoire afin de répondre localement aux requêtes suivantes. Le défi politique d’AlterNIC visait les règles du système de noms ; la trace de Brintnall montre une correspondance mise en cache par un résolveur. Elle ne montre pas qu’AlterNIC ait réécrit la zone racine publique.

Ce que la mémoire établit, et rien de plus

Le message publié sur NANOG est exceptionnellement concret pour une histoire du DNS. Il indique l’adresse du serveur, l’enregistrement A renvoyé, l’adresse source conservée en mémoire et l’annotation de provenance du résolveur. L’adresse source correspondait à une machine d’AlterNIC. Cette origine addtnl concorde avec l’explication publiée plus tard par WIRED : une réponse DNS pouvait transporter des enregistrements supplémentaires, et un résolveur trop confiant pouvait en garder un pour un nom différent de celui qu’il avait demandé.

Cette preuve établit une mauvaise réponse dans une mémoire. Elle ne compte pas tous les résolveurs touchés, ne prouve pas que chaque visiteur ait été redirigé et ne démontre pas que les serveurs racine publics étaient sous le contrôle d’AlterNIC. Les articles contemporains parlaient parfois de redirection de « l’Internet » ; la trace resserre l’affirmation : un résolveur proposait une autre destination pour un nom Web précis. La valeur 146598 figurant dans l’extrait est un champ de l’enregistrement, pas la durée d’une panne mondiale ni un nombre d’utilisateurs.

Le contexte politique était bien réel. Le Washington Post indique que Network Solutions détenait, au titre d’un accord avec la National Science Foundation, des droits exclusifs d’enregistrement pour .com, .org et .net. AlterNIC se présentait comme un registre concurrent et contestait ce que son opérateur décrivait comme la prétention de NSI à posséder ces noms. Ce rôle contractuel était puissant, mais il ne signifiait pas que NSI possédait tous les noms ni l’ensemble de la racine Internet. En dirigeant les visiteurs vers AlterNIC, le détournement rendait le débat visible ; il ne tranchait pas la question de l’autorité légitime sur l’espace public des noms.

Un incident de cache n’était pas une décision de politique

La réponse s’est jouée dans les logiciels et l’exploitation. En août 1997, l’avis BIND du CERT décrit l’empoisonnement du cache comme l’enregistrement par un serveur de noms de données reçues d’un serveur distant, puis leur restitution aux programmes clients. Il précise que la vulnérabilité avait été corrigée dans BIND 4.9.6 et recommande une voie de mise à niveau comprenant BIND 8.1.1. L’avis traite d’une classe de comportement des résolveurs, pas uniquement d’AlterNIC.

Publié en juillet 1997, le RFC 2181 classe les données de la section supplémentaire parmi les moins fiables et précise que les enregistrements supplémentaires non authentifiés ne devraient pas être restitués plus tard comme réponses. Le document clarifie le traitement attendu des données DNS ; les sources disponibles ne montrent pas qu’il ait été écrit à cause de cet épisode. Sa publication ne prouve pas non plus que les opérateurs aient immédiatement mis à niveau ou correctement configuré chaque résolveur.

Le débat américain sur les noms de domaine a suivi son propre cours. Le ministère du Commerce a ouvert une consultation publique en juillet 1997 ; le Green Paper, le White Paper et la création d’ICANN ont suivi en 1998. La chronologie de l’Internet Society retrace cette séquence sans attribuer sa cause au détournement d’AlterNIC. En 2000, l’IAB soutient dans le RFC 2826 que le DNS public a besoin d’une racine unique afin de préserver la cohérence des noms. C’est une position institutionnelle ultérieure, pas une expertise de la mémoire de Brintnall.

L’épisode relève ainsi de deux histoires à la fois : la contestation d’un rôle d’enregistrement concentré et la démonstration qu’un résolveur local pouvait transformer des données supplémentaires douteuses en nouvelle destination. La première question était de savoir qui devait fixer les règles des noms. La seconde, quelles données un résolveur devait croire. Les confondre ferait passer une ligne de cache pour un transfert de la zone racine — et une redirection visible pour la preuve d’un contrôle universel.

Sources