Le test de Jon Postel en 1998 portait sur les transferts de zone, pas les requêtes DNS

Résumé

• Le courriel de Jon Postel du 28 janvier 1998 demandait aux serveurs secondaires de la racine de récupérer une copie auprès de DNSROOT.IANA.ORG; il indiquait que les données seraient identiques à celles d’A-root et que les règles de modification de la zone ne changeaient pas.
• Le 3 février, Postel a déclaré la vérification terminée et demandé aux opérateurs de revenir à A-root. Les messages prouvent l’existence de demandes, pas la configuration de chaque opérateur.

Deux opérations dans un même service DNS

Un résolveur qui cherche un nom et un serveur secondaire qui actualise sa copie d’une zone n’effectuent pas la même opération. Le résolveur envoie une requête DNS à un serveur faisant autorité. Le secondaire obtient séparément les données qu’il servira auprès d’un serveur maître. Ces deux rôles peuvent coexister sur une même machine, mais ils ne constituent pas la même transaction réseau.

Cette distinction appartenait déjà à la conception opérationnelle du DNS. La RFC 1034 décrit un serveur primaire qui coordonne les modifications et des secondaires qui vérifient le numéro de série SOA avant de récupérer une copie actualisée. La RFC 1035 définit AXFR comme une requête de transfert de zone complète. Un résolveur qui demande un enregistrement ne demande pas un transfert AXFR de la zone racine.

En janvier 1998, une même machine pouvait répondre aux requêtes comme serveur racine et fournir aux autres serveurs racine une source pour actualiser leurs données. La demande de Postel concernait ce second rôle. Elle ne demandait pas aux résolveurs d’envoyer leurs requêtes ordinaires à l’hôte de l’IANA.

Le courriel délimitait une demande de transfert

Le message archivé est daté du 28 janvier 1998 et porte l’objet « root zone secondary service ». Postel demandait aux serveurs secondaires du domaine racine de récupérer la zone « par transfert de zone » directement auprès de DNSROOT.IANA.ORG, à l’adresse 198.32.1.98. Il indiquait que les données seraient une copie exacte de la zone alors disponible sur A.ROOT-SERVERS.NET. Il précisait aussi qu’aucune politique ni procédure de modification de la zone racine ne changeait.

La phrase qui délimite la portée de la demande compte autant que le nom du serveur. L’instruction ne concernait que la zone racine. Les opérateurs qui fournissaient un service secondaire pour d’autres zones, y compris les domaines de premier niveau, devaient conserver leurs sources habituelles. Le courriel décrivait donc une modification proposée d’un chemin de réplication, pas une redirection de tout le service DNS ni le remplacement de toutes les relations amont.

Les mêmes archives conservent une déclaration à la presse dans laquelle Postel décrit un essai visant à réorganiser la circulation des informations de la zone racine. Il affirme que son contenu continuerait d’être déterminé et préparé comme auparavant. Ces textes avancent deux points distincts : les données doivent rester identiques et un autre serveur de l’IANA doit être testé comme source des copies secondaires. Ils ne fournissent ni configuration de chaque secondaire ni résultat détaillé des transferts.

L’essai côtoyait une autre question administrative : qui pouvait autoriser les changements apportés aux enregistrements eux-mêmes. Le courriel de janvier laissait explicitement ces procédures intactes. Une source de transfert peut fournir une copie sans devenir l’auteur de tous ses enregistrements. Les messages disponibles ne montrent pas que l’IANA ait commencé à modifier ou publier un nouveau jeu de données de la zone racine pendant cet essai.

Changer une source ne redirige pas les requêtes

L’épisode prête à confusion parce qu’A-root occupait deux fonctions : il répondait aux requêtes comme l’un des serveurs racine et était présenté comme la source établie du fichier de zone. Ces rôles étaient associés à une même machine, mais le protocole de transfert permettait de distinguer la source de distribution des serveurs qui répondaient aux résolveurs.

On peut formuler la conséquence comme une inférence conditionnelle. Si un secondaire récupère une copie identique et la charge correctement, changer le serveur dont vient cette copie ne modifie pas, à lui seul, les enregistrements renvoyés à un résolveur. Le courriel archivé indique que la copie de l’IANA devait être identique ; il ne publie ni comparaison par serveur ni mesures de requêtes prouvant que cette condition était satisfaite partout.

Lors d’une audition ultérieure au Congrès, NSI a déclaré qu’elle agissait comme serveur racine « primaire » dans le cadre de son accord avec le gouvernement, qu’aucun contrat ne liait les treize opérateurs entre eux et que les autres opérateurs n’étaient pas tenus de récupérer le fichier chaque jour. Ce témoignage aide à comprendre que le terme « primaire » décrivait un arrangement opérationnel, pas un ordre contractuel imposé à chaque secondaire. Il ne dit pas qui a accepté la demande de Postel en 1998.

La demande de retour borne l’épisode

Le 3 février, dans un message intitulé « root zone transfer verification completed », Postel a déclaré l’essai terminé et demandé aux opérateurs de reprendre l’obtention de la zone auprès d’A-root. La demande ne concernait toujours que la zone racine. La rétrospective RSSAC-023v2 indique que Postel avait demandé à Jim Koda et Paul Vixie d’établir un serveur primaire à l’ISI pour l’essai, puis avait contacté plusieurs opérateurs avant de leur demander de revenir à l’ancien primaire quelques jours plus tard.

Cette histoire technique ultérieure confirme la séquence et ne parle que de « plusieurs » opérateurs. Ni elle ni les courriels conservés ne fournissent la liste de ceux qui ont modifié leur configuration, un journal AXFR complet ou un reçu indiquant quand chacun est revenu à A-root. Une demande atteste d’une intention ; elle ne prouve pas que chaque destinataire l’a exécutée.

Les sources ne permettent pas non plus de mesurer l’effet sur le service. La déclaration de Postel exprimait une forte confiance dans une transition sans interruption, mais une prévision n’est pas une télémétrie. Les messages ne sont accompagnés ni d’une série de requêtes, ni d’un journal d’incidents, ni d’une comparaison indépendante de toutes les copies en service.

Sources

Les documents les plus proches de l’événement sont la copie conservée de la demande du 28 janvier et du message de retour du 3 février de Postel. L’archive reproduit un bloc de signature PGP, que cet article n’a pas validé indépendamment. La rétrospective du RSSAC fournit un récit institutionnel ultérieur. Les RFC 1034 et 1035 définissent le mécanisme de transfert, pas la configuration de chaque opérateur en 1998. Le témoignage de NSI figure dans une audition de la commission judiciaire de la Chambre des représentants et lui est attribué.