Les premiers annuaires de contacts WHOIS et la dérive

Résumé

La RFC 812 a défini NICNAME/WHOIS en 1982 comme un annuaire lisible par l’homme pour localiser les utilisateurs du réseau. La RFC 954 a élargi la population consultable en 1985, mais aucune de ces spécifications n’a fait d’un nom, d’un identifiant, d’une organisation, d’un hôte ou d’un champ de contact retourné une preuve de droit légal ou de contrôle opérationnel actuel.
Quatre familles d’enregistrements se sont développées selon des trajectoires différentes: les entrées d’annuaire personnel, les contacts d’hôtes et de réseaux DDN, les enregistrements de noms de domaine et leurs affichages WHOIS publics, et les enregistrements de ressources de numéros. Leur interface de requête commune n’en a pas fait un système de titre continu.
Un incident de décembre 1990 fournit une preuve directe de dépendance opérationnelle et d’attribution limitée de responsabilité: un enregistrement de réseau du NIC DDN a orienté les sites concernés et le CERT/CC vers une institution, tandis que les journaux, l’administration locale et une enquête directe restaient nécessaires pour identifier la machine et l’opérateur.
Un litige de février 1996 concernant l’enregistrement CLUE.COM constitue un cas complet de légitimité administrative dans la procédure d’enregistrement sous-jacente de Network Solutions. Le titulaire enregistré a reçu un avis, a contesté le changement menacé et a obtenu une injonction préservant l’enregistrement. Le dossier judiciaire ne montre pas qu’une consultation WHOIS publique ait créé cette légitimité de manière indépendante.
Le litige Kremen documente une autre collision d’octobre 1995: Network Solutions a modifié sa base de données d’enregistrement faisant autorité après avoir reçu une instruction falsifiée, produisant des conséquences pratiques. Le WHOIS public pouvait refléter l’état modifié, mais les preuves ne montrent pas qu’une consultation publique ait causé le changement ou conféré la propriété.
En 1996, les données d’enregistrement et de réaffectation des ressources de numéros étaient des entrées prescrites pour les décisions de contact opérationnel et d’allocation supplémentaire. La RFC 2050 exigeait néanmoins une documentation justificative, protégeait les informations sensibles désignées par le demandeur et prévoyait un examen par la hiérarchie du registre. Aucun cas examiné ici ne montre qu’une simple ligne publique d’enregistrement de numéros ait décidé seule d’un droit.

Lire le schéma avant de lui attribuer une autorité

Les premières spécifications sont à aborder comme une archéologie de schéma. Avant de demander quand le WHOIS est devenu une preuve, il faut se demander ce que ses enregistrements étaient censés contenir, qui était censé y figurer, et ce qu’une réponse prétendait accomplir.

RFC 812, rédigée par Ken Harrenstien et Vic White et datée du 1er mars 1982, décrivait NICNAME/WHOIS comme un serveur de requêtes et de réponses transactionnel sur la machine SRI-NIC. Il fournissait un annuaire à l’échelle du réseau aux utilisateurs d’ARPANET pour le compte de la Defense Communications Agency. Un utilisateur envoyait une ligne de commande, recevait une réponse et se déconnectait. La réponse était destinée à un lecteur humain plutôt qu’à une interprétation automatisée.

La population attendue était personnelle. La Defense Communications Agency demandait l’enregistrement de chaque individu disposant d’un répertoire sur un hôte ARPANET et capable de faire passer du trafic à travers le réseau. Les informations d’enregistrement comprenaient un nom, des coordonnées institutionnelles ou postales, un contact téléphonique et une boîte aux lettres réseau. Ces champs montrent la quantité d’informations de contact personnel que le service exposait, mais reproduire de vraies entrées n’est pas nécessaire. Leur fonction originelle était la découverte.

RFC 954, rédigée par K. Harrenstien, M. K. Stahl et E. J. Feinler et datée d’octobre 1985, conservait le port 43 et l’architecture une requête, une réponse. Elle décrivait le service comme un annuaire pour les utilisateurs d’Internet et indiquait à nouveau que sa sortie était lisible par l’homme. Sa population consultable était plus large: les personnes et boîtes aux lettres enregistrées, les organisations de réseau, les nœuds DDN et leurs hôtes associés, ainsi que les utilisateurs enregistrés de l’accès terminal MILNET.

Les champs remplissaient déjà des fonctions différentes. Un nom aidait un utilisateur à trouver une personne. Un identifiant (handle) distinguait cette personne d’autres ayant des noms similaires et servait de référence réutilisable dans la base de données. Une organisation indiquait une affiliation. Les champs de boîte aux lettres et de téléphone fournissaient des canaux de communication. Les associations d’hôte et de nœud situaient une personne dans les opérations du réseau.

Aucune de ces propositions, en elle-même, n’indiquait que la personne restait employée par l’organisation, pouvait l’engager, contrôlait chaque système associé ou possédait un droit légal ou contractuel sur un identifiant Internet.

La différence entre un annuaire et un système de preuve réside en partie dans ce qui entoure les champs affichés. Un système de preuve soulève des questions sur la provenance, l’autorité de soumission, l’authentification, les dates d’effet, les versions remplacées, les corrections contestées, les raisons des changements et l’examen. Les RFC 812 et RFC 954 spécifiaient le service de requête publique. Elles ne spécifiaient pas de piste d’audit publique répondant à ces questions.

Cette omission ne doit pas être exagérée. Un document de protocole n’est pas un manuel d’exploitation complet. L’absence de règle d’authentification dans la spécification de requête ne prouve pas que le personnel du NIC acceptait chaque mise à jour sans correspondance, vérification téléphonique, relations établies avec le site ou jugement humain. Elle établit quelque chose de plus restreint: le destinataire de la réponse publique ne recevait pas un compte rendu normalisé indiquant qui avait fourni chaque champ, comment l’autorité de cette personne avait été testée, quelles valeurs antérieures avaient été remplacées, ou si une autre partie contestait l’enregistrement actuel.

Cinq éléments doivent donc rester distincts:

la base de données d’enregistrement ou d’identification sous-jacente de l’institution;
la réponse WHOIS publique générée à partir de cette base de données;
la procédure par laquelle un enregistrement ou un contact a été ajouté, modifié ou supprimé;
les systèmes opérationnels associés à l’identifiant, y compris l’administration de l’hôte, le routage et la délégation DNS;
les contrats, la correspondance d’allocation, les nominations organisationnelles, le consentement et les documents juridiques extérieurs à la base de données.

Confondre ces couches fait paraître la consultation publique plus puissante que ne le permettent les preuves historiques. Une réponse WHOIS pouvait décrire un enregistrement. Une transaction d’enregistrement pouvait modifier la base de données faisant autorité d’un registrar. Un changement opérationnel distinct pouvait altérer le service DNS ou l’utilisation du réseau. Un tribunal ou un registre pouvait décider ultérieurement si la transaction était valide. Il s’agissait d’événements liés, non d’un seul événement.

L’échelle probatoire examinée ici est:

commodité de l’annuaire -> dépendance opérationnelle -> attribution de responsabilité -> légitimité administrative -> inférence semblable à un droit

Chaque échelon supérieur exige plus qu’une spécification montrant qu’un champ existait. Il nécessite un acteur daté, un enregistrement particulier, une décision, une source de vérité concurrente et un résultat observable. Lorsque les archives ne fournissent qu’une procédure prescrite, la conclusion doit rester une attente documentée plutôt qu’un acte de dépendance accompli.

Nom et identifiant: l’enregistrement d’annuaire personnel

À quoi servaient les champs

Le champ du nom répondait à la question la plus simple: quelle personne recherche-t-on? L’identifiant rendait cette réponse plus stable à l’intérieur de la base de données. Un utilisateur pouvait effectuer une recherche large puis sélectionner une entrée particulière par son identifiant. D’autres enregistrements pouvaient pointer vers l’identifiant sans reproduire tous les champs de contact.

C’était une réalisation technique importante. Les noms ne sont pas uniques, les initiales varient et les affiliations organisationnelles changent. Un identifiant durable réduisait l’ambiguïté dans les enregistrements du NIC. Il constituait une preuve solide de la ligne de base de données que l’utilisateur avait sélectionnée.

Ce n’était pas une pièce d’identité. Les RFC 812 et RFC 954 ne décrivaient pas de preuve documentaire d’identité, de signature liée à l’identifiant, ni d’autorité externe certifiant chaque affiliation. Un identifiant établissait la continuité dans la base de données plus clairement que la continuité dans l’emploi, les responsabilités ou la capacité juridique de la personne.

Le champ de l’organisation était également descriptif. Il aidait à distinguer les personnes et indiquait où elles pouvaient être trouvées. Un enregistrement pouvait rapporter avec précision une association institutionnelle au moment de la saisie et devenir obsolète après une mutation, une réorganisation ou un départ. Le champ ne contenait pas de contrat de travail ni de délégation d’autorité.

Soumission, mise à jour et authentification

La RFC 812 demandait aux individus d’envoyer leurs informations d’enregistrement au NIC. La RFC 954 utilisait un canal de registrar pour des soumissions comparables. Les spécifications identifient le sujet attendu et la destination de l’information, mais elles ne décrivent pas un protocole de mise à jour authentifié distinct.

Les spécifications qui subsistent permettent l’audit limité suivant:

Soumission et provenance:les informations provenaient d’un individu cherchant ou tenu de s’enregistrer auprès du NIC.
Autorité de mise à jour:les RFC n’énoncent pas de règle complète pour décider qui pouvait remplacer un enregistrement de personne existant.
Authentification:aucune méthode uniforme de vérification d’identité n’est spécifiée dans les documents de protocole publics.
Correction:des canaux d’assistance et d’enregistrement existaient, mais les RFC ne décrivent pas de procédure de correction contestée.
Remplacement et temps actuel:la réponse publique représentait la réponse actuelle de la base de données; les spécifications ne définissent pas d’historique des temps d’effet par enregistrement.
Conservation historique:aucune séquence publique des valeurs antérieures n’est spécifiée.
Examen des conflits:les RFC n’expliquent pas comment le personnel trancherait entre des revendications incompatibles concernant la même entrée personnelle.
Limite de confidentialité:les informations de contact personnel étaient délibérément exposées parce que la découverte de personnes était le but originel du service.

Inconnu ne signifie pas inexistant. La correspondance interne ou les pratiques du personnel ont peut-être fourni des contrôles que les RFC ne documentaient pas. La conclusion défendable est que ces contrôles ne faisaient pas partie de la preuve présentée à l’utilisateur de la réponse publique.

L’échelon soutenu par cette famille

L’enregistrement d’annuaire personnel établit directement la commodité de l’annuaire. En 1982 et 1985, l’utilisateur identifié était un entité ARPANET ou DDN cherchant une personne, une boîte aux lettres, une organisation ou une association d’hôte. La décision portait sur l’endroit où adresser un message ou une demande. Les sources concurrentes comprenaient un annuaire d’employeur, un compte d’hôte, une liste de site, un contact téléphonique ou une confirmation de la personne ou de l’institution.

Les sources examinées ici ne documentent pas de cas antérieur à 1997 où la présence d’un identifiant personnel NIC, en elle-même, aurait décidé d’un droit légal, d’une autorité organisationnelle ou d’un contrôle technique. La durabilité du champ pouvait inviter à ces inférences, mais sa fonction documentée restait la découverte.

Hôte et réseau: l’enregistrement de contact opérationnel DDN

De l’affiliation à un devoir d’agir

Un opérateur distant confronté à un dysfonctionnement ou un incident de sécurité n’avait pas simplement besoin du nom de quelqu’un dans une institution. Il avait besoin de quelqu’un qui puisse enquêter sur un hôte, modifier une configuration, déconnecter un système ou ordonner au personnel local de le faire.

Des sources contemporaines définissent cette responsabilité. LeDomain Administrators Guide, RFC 1032, daté de novembre 1987, distinguait l’administrateur de domaine des contacts techniques et de zone. L’administrateur était censé coordonner et gérer le domaine et posséder l’autorité pour agir ou déléguer. Les contacts techniques et de zone maintenaient le logiciel et les données du serveur de noms et travaillaient avec le personnel technique ailleurs.

RFC 1173, datée d’août 1990, décrivait les responsabilités des gestionnaires d’hôtes et de réseaux. Il s’agissait explicitement d’un résumé informatif de la « tradition orale » d’Internet, et non d’une norme IAB. Même avec cette limitation, son test substantiel est révélateur. Il exigeait que les personnes responsables des réseaux connectés soient enregistrées auprès du NIC approprié et tenues à jour. Un gestionnaire de réseau était censé posséder un accès de gestion du système ou l’autorité pour désactiver, déconnecter ou cesser de transférer le trafic d’un système défaillant. Un gestionnaire d’hôte avait de même besoin de l’autorité, de l’accès et des outils nécessaires pour contrôler l’hôte.

L’enregistrement et la réalité externe étaient donc liés mais non identiques. L’enregistrement nommait la personne. Les privilèges réels, l’accès physique, l’autorité de l’employeur et la coopération locale déterminaient si cette personne pouvait remplir le rôle.

Leguide de 2011 des archives SRI ARC/NICfournit une carte rétrospective de la collection et identifie des documents concernant les liaisons techniques, les administrateurs d’hôtes, les coordinateurs de site de nœud et d’autres groupes de contact. Il aide à localiser les enregistrements pertinents; il n’est pas traité comme une preuve contemporaine de la raison pour laquelle chaque rôle a été créé ou de l’autorité précise que chaque titulaire possédait. Ces propositions nécessitent des documents d’époque tels que les RFC 1032, RFC 1173, des directives, des documents d’enregistrement et des rapports opérationnels.

Un compte rendu daté de la manière dont les fichiers de contact étaient tenus à jour

Un enregistrement opérationnel plus précis subsiste dans le rapportDescriptions of NIC Tables and Listsde Mary K. Stahl, un rapport final daté du 5 avril 1991. Le Network Information Systems Center de SRI International a préparé le rapport pour la Defense Communications Agency dans le cadre du contrat DCA200-90-C-0027, SRI Project ECU 1050, CDRL No. 027. Il figure dans la collection du Computer History Museum intituléeDefense Communication Agency materials, 9 of 13.

Le rapport identifie plusieurs dérivés distincts plutôt qu’un seul fichier WHOIS indifférencié.

La section 3.1, à la page 7 du rapport, décrit les fichiers d’administrateurs d’hôtes MILNET. Leurs données étaient extraites de la base de données WHOIS du NIC. Les informations initiales provenaient des Network Change Directives, après quoi le Hostmaster du NIC sollicitait des corrections auprès des administrateurs d’hôtes chaque mois. Le fichier dérivé était généré chaque semaine.

La section 3.7, à la page 10 du rapport, décrit un fichier organisant les administrateurs d’hôtes par adresse réseau. Elle indique également que les données initiales provenaient des Network Change Directives et étaient tenues à jour par des sollicitations mensuelles en ligne de corrections. Le fichier était généré chaque semaine.

Le rapport indique également que les fichiers et les tables portaient un numéro de version ou une date de dernière mise à jour au niveau du fichier. Cela fournissait une information temporelle utile: un utilisateur pouvait identifier une génération publiée particulière. Cela ne fournissait pas nécessairement un historique public de chaque valeur antérieure pour chaque contact.

Pour les enregistrements d’hôtes et de réseaux DDN, l’audit devient plus concret:

Soumission et provenance:les informations initiales sur l’hôte pouvaient provenir des Network Change Directives; les modifications ultérieures venaient d’administrateurs d’hôtes reconnus, de coordinateurs de site de nœud ou du personnel réseau.
Autorité de mise à jour:les titulaires de rôle étaient censés soumettre des corrections, et le Hostmaster les sollicitait. Le rapport ne définit pas chaque test utilisé lorsqu’un nouveau correspondant prétendait remplacer un titulaire de rôle existant.
Authentification:un rôle établi et un canal de correspondance créaient une confiance procédurale, mais le rapport ne décrit pas de système uniforme de vérification d’identité ou d’authentification des messages pour toutes les mises à jour.
Correction:les sollicitations mensuelles et les soumissions volontaires offraient des voies de correction récurrentes.
Remplacement et temps actuel:les fichiers régénérés chaque semaine et les versions au niveau du fichier montraient les cycles de publication, pas nécessairement la date d’effet de chaque changement organisationnel externe.
Conservation historique:le rapport décrit les dérivés actuels et leur génération. Il n’établit pas une séquence publique, complète et par enregistrement des contacts remplacés et des raisons.
Examen des conflits:le Hostmaster occupait une position d’interprétation, mais le rapport ne décrit pas de procédure générale d’arbitrage pour les demandeurs concurrents du même rôle.
Limite de confidentialité:certains dérivés opérationnels contenaient des données personnelles et de contact détaillées. Ces détails ne sont pas reproduits ici.

Le système de maintenance était structuré. Il n’équivalait pas à une chaîne de preuves authentifiées inspectable publiquement. Un enregistrement actuel pouvait encore être en retard par rapport à un changement de personnel sans que personne n’agisse de manière malhonnête.

Dépendance opérationnelle et attribution de responsabilité en décembre 1990

Un incident réel fournit le mouvement antérieur à 1997 le plus clair au-delà de l’utilisation prescrite.

Dans un article présenté au symposium sur la sécurité USENIX de 1992,Alessandro Berni, Paolo Franchi et Joy Marino ont décrit des incidents de sécurité Internet en Italie. Leur compte rendu indique que deux sites ont observé des tentatives d’intrusion associées à un réseau en Italie et ont contacté le CERT Coordination Center. Pendant la réponse, la base de données WHOIS du DDN NIC a associé le réseau à l’Université de Milan.

Les éléments probatoires peuvent être énoncés sans exposer les détails de contact historiques:

Date:décembre 1990, documentée dans l’article de 1992.
Acteurs:les sites affectés et le CERT/CC.
Enregistrement utilisé:l’association de réseau du DDN NIC et les informations de contact.
Décision:quelle institution devait recevoir le rapport d’incident initial et être invitée à enquêter avant que les opérateurs n’envisagent d’isoler le réseau.
Sources de vérité concurrentes:les journaux système et de paquets, les informations de routage, l’administration réelle de la machine impliquée, les dossiers institutionnels locaux et la confirmation directe.
Résultat:la consultation a identifié une institution pertinente et a initié le contact, mais l’administrateur responsable de la machine n’a pas été immédiatement établi et la communication est restée difficile.

Ce cas prouve la dépendance opérationnelle. L’enregistrement a changé ce que les intervenants ont fait ensuite: il a sélectionné une institution à contacter.

Il soutient également une forme limitée d’attribution de responsabilité. L’entrée réseau a associé le trafic observé à un réseau organisationnel et a placé cette organisation dans le chemin de réponse. Elle n’a pas identifié l’individu qui a effectué l’activité, localisé de manière concluante la machine spécifique ni prouvé qui avait la capacité de l’arrêter.

Les journaux ont établi les événements observés. Le WHOIS a fourni une association institutionnelle. L’enquête locale devait relier le trafic à une machine. L’autorité organisationnelle et l’accès technique déterminaient qui pouvait agir. L’enregistrement était un pont entre un identifiant et une institution, pas un système complet d’attribution.

Les preuves atteignent solidement la dépendance opérationnelle et l’attribution de responsabilité. Elles ne montrent pas qu’une entrée publique de contact réseau ait conféré une légitimité dans un changement administratif contesté ou établi un droit sur le numéro de réseau.

Organisation, domaine, contacts et serveurs: l’enregistrement de domaine

L’organisation et le domaine

La RFC 1032 demandait à un administrateur de domaine de soumettre un questionnaire d’enregistrement et décrivait l’administrateur comme responsable de la mise à jour des données du domaine. Sa section de vérification indiquait que le WHOIS pouvait être utilisé pour examiner l’organisation associée à un domaine, le nom de domaine, les contacts administratifs, techniques et de zone, ainsi que les serveurs de noms listés.

C’était plus qu’une découverte personnelle. C’était une utilisation prescrite du WHOIS pour comparer un enregistrement avec la configuration de domaine prévue.

Pourtant, la RFC 1032 fournissait également une contre-preuve contemporaine à toute théorie de titre de propriété. Elle indiquait que le NIC n’agirait pas en tant qu’arbitre dans les litiges locaux sur qui avait le « droit » d’enregistrer un domaine. De tels litiges devaient être réglés entre les parties avant l’enregistrement. Le NIC pouvait répondre aux questions techniques mais ne prétendait pas adjuger le droit sous-jacent.

Les champs devraient donc être lus séparément:

Organisation:l’entité représentée dans la demande d’enregistrement.
Contact administratif:la personne responsable de la politique ou de la coordination organisationnelle.
Contacts techniques et de zone:les personnes responsables du fonctionnement du serveur de noms et des données connexes.
Serveurs de noms:les systèmes destinés à répondre de manière autoritaire pour le domaine.
Affichage WHOIS:la représentation lisible par l’homme par le registrar des faits enregistrés.
Délégation DNS:le placement opérationnel du domaine dans le système de nommage hiérarchique.

Une réponse WHOIS publique pouvait être comparée à une demande et au DNS actif. Elle ne pouvait pas, sans preuves supplémentaires, prouver que le contact administratif possédait encore l’autorité corporative ou que l’organisation détenait tous les droits légaux impliqués par le nom.

La RFC 1032 établit un utilisateur et une décision normatifs: en novembre 1987, un administrateur de domaine était invité à consulter le WHOIS pour vérifier si les données du domaine étaient correctement représentées. Les sources concurrentes étaient la demande soumise, les enregistrements du domaine supérieur, le DNS actif et les nominations organisationnelles. La RFC ne documente pas un administrateur particulier effectuant cette comparaison et obtenant un résultat enregistré. Elle prouve une vérification opérationnelle attendue, non un événement de dépendance accompli.

Correction de domaine dans l’enregistrement DDN de 1991

Le rapport d’avril 1991 de Stahl donne au fichier de contacts de domaine une provenance spécifique. La section 3.8, à la page 10 du rapport, indique que le dérivéDOMAIN-CONTACTStirait ses informations des demandes d’enregistrement de domaine traitées par le Hostmaster du NIC et des corrections soumises par les administrateurs de domaine. Les données brutes étaient stockées dans la base de données WHOIS du NIC, et le fichier de contacts était généré chaque semaine.

Le rapport distingue également les contacts administratifs, techniques et de zone. Ces rôles n’étaient pas interchangeables simplement parce qu’ils apparaissaient ensemble.

Le rapport conforte une voie de correction définie mais laisse d’autres questions ouvertes:

un administrateur de domaine reconnu pouvait soumettre une correction;
le Hostmaster traitait la demande source ou la correction;
un nouveau dérivé hebdomadaire pouvait exposer l’état actuel modifié;
le rapport n’énonce pas de méthode d’authentification universelle pour chaque correction;
il n’établit pas que tout utilisateur public pouvait récupérer tous les contacts remplacés;
il ne décrit pas une procédure uniforme pour juger les demandes de correction incompatibles.

Cela constitue une preuve de mutation gérée. Ce n’est pas la preuve qu’un contact administratif affiché acquérait une autorité légale simplement parce qu’il était affiché.

Le flux de travail des demandes d’InterNIC en 1993

RFC 1400, datée de mars 1993, documentait la transition des services d’enregistrement non DDN vers InterNIC. À partir du 1er avril 1993, le WHOIS d’InterNIC devait contenir des informations sur les adresses IP, les domaines, les numéros de systèmes autonomes et les points de contact individuels associés aux nœuds actifs. La couverture générale d’annuaire personnel n’était plus la population principale du service d’enregistrement central.

Le document décrivait également un processus de demande structuré. Un demandeur soumettait un modèle à une boîte aux lettres d’enregistrement automatisée. Un analyseur vérifiait les informations qui pouvaient être testées mécaniquement, y compris les conflits de noms de domaine, et renvoyait un message de vérification ou de rejet. Le demandeur examinait la manière dont l’analyseur avait interprété la soumission. Des corrections pouvaient être renvoyées et revérifiées. Une vérification satisfaisante libérait la demande pour le traitement final par le personnel d’enregistrement. Une vérification sans réponse expirait après sept jours. Un numéro de ticket exposait l’état de la demande, et un affichage WHOIS pouvait porter une date de dernière mise à jour.

Ces contrôles amélioraient la forme, le timing et la traçabilité, mais leur modalité importe.

Le formulaire de vérification était envoyé audemandeur initial. La RFC 1400 ne dit pas qu’un contact administratif existant le recevait parce qu’une liste WHOIS antérieure conférait l’autorité. La position procédurale du demandeur découlait du fait d’avoir soumis la demande. Le formulaire retourné vérifiait l’interprétation par l’analyseur des données soumises; il ne constituait pas, en soi, la preuve que le demandeur possédait l’autorité légale pour représenter l’organisation.

La RFC 1400 indique également que les questions de sécurité n’étaient pas discutées dans le mémo. Cette absence ne prouve pas que le personnel n’utilisait pas de vérifications téléphoniques, de documents papier, de correspondance antérieure ou de jugement institutionnel. Elle empêche que le flux de travail automatisé soit cité comme preuve d’une norme universelle de vérification d’identité.

Pour le flux de travail de domaine de 1993:

Provenance:le système liait une demande, un demandeur, un formulaire analysé et un ticket.
Authentification:la RFC ne spécifie pas de test indépendant universel de l’autorité organisationnelle.
Correction:les erreurs de l’analyseur et les soumissions rejetées avaient un chemin de correction explicite.
Temps:les informations d’ouverture de ticket et un champ de dernière mise à jour fournissaient des repères temporels actuels.
Historique:les exemples publics n’établissent pas une séquence complète des versions soumises et des décisions du personnel.
Examen:le personnel d’enregistrement effectuait le traitement final, mais la RFC ne définit pas l’arbitrage de deux demandes concurrentes.
Légitimité administrative:le document prouve la place du demandeur initial dans cette demande, pas une légitimité acquise à partir d’un champ de contact public existant.

Une comparaison limitée tirée de la RFC 1591

RFC 1591, datée de mars 1994, concernait la structure et la délégation DNS. Elle n’est utile qu’à titre de comparaison spécifique aux domaines.

Le document exigeait des contacts administratifs et techniques pour un domaine délégué, mais la responsabilité reposait sur plus qu’un champ. Un gestionnaire désigné était censé servir la communauté concernée, exploiter le domaine avec compétence, répondre aux demandes, maintenir un service précis et résilient, et conserver le soutien des parties significativement intéressées. Un transfert de responsabilité du gestionnaire désigné nécessitait des communications des anciennes et nouvelles organisations, les parties affectées étant également pertinentes.

Dans les litiges sur les droits à un nom, la RFC 1591 limitait le rôle de l’autorité d’enregistrement à fournir des informations de contact et indiquait que l’enregistrement ne créait pas de statut de marque. Elle envisageait également un examen lorsque les parties ne parvenaient pas à un accord.

Les acteurs datés étaient l’IANA, le gestionnaire de niveau supérieur, les anciennes et nouvelles organisations, et les parties affectées. Un enregistrement de contact pouvait identifier qui approcher. Une décision de délégation dépendait des performances opérationnelles, de l’accord, des communications et de l’examen.

Il s’agit d’une comparaison au sein du DNS. Elle ne peut pas établir la propriété d’un bloc d’adresses IP, et elle ne prouve pas que chaque changement de domaine de second niveau suivait le même processus.

Un cas complet de légitimité administrative: CLUE.COM en 1996

La politique de règlement des litiges de noms de domaine de Network Solutions de juillet 1995 prescrivait des options de notification et de procédure pour le titulaire enregistré lorsqu’une revendication de marque qualifiée était présentée. Les descriptions ultérieures de cette politique, prises isolément, établissent la procédure plutôt qu’une dépendance accomplie. Un cas spécifique fournit la preuve manquante.

L’avis de 1998 dans l’affaireOppedahl & Larson c. Network Solutionsdécrit le dossier entourant l’adoption de la politique de juillet 1995. Il identifie les admissions des parties, la pièce relative à la politique et la réponse de la politique à un enregistrement fédéral de marque certifié identique à un nom de domaine enregistré. Le registrar pouvait écrire au titulaire du domaine et proposer des options spécifiées. Ce compte rendu judiciaire confirme la procédure, tout en enregistrant des litiges sur son application aux titulaires existants.

Une procédure judiciaire distincte et contemporaine documente l’application de la politique à un enregistrement particulier. Dans l’affaireNetwork Solutions, Inc. c. Clue Computing, Inc., le tribunal de district des États-Unis pour le district du Colorado a consigné que Clue Computing détenait l’enregistrement CLUE.COM géré par Network Solutions et que Hasbro faisait valoir une revendication de marque concurrente.

Le 1er février 1996, Network Solutions a informé Clue Computing que son utilisation du domaine pourrait enfreindre la marque de Hasbro. Le registrar exigeait que Clue Computing produise une certification de marque ou accepte l’attribution d’un nouveau nom de domaine. Clue Computing n’est pas resté un nom passif dans un affichage. Il a réagi en tant que titulaire reconnu, a intenté une action devant un tribunal d’État contre Network Solutions et a cherché à empêcher le registrar de mettre l’enregistrement en suspens.

Le 25 juin 1996, le tribunal de district du comté de Boulder a interdit à Network Solutions de modifier l’enregistrement et l’utilisation de CLUE.COM. Network Solutions avait entre-temps déposé une action fédérale en interpleader, se présentant comme un dépositaire prêt à attribuer l’enregistrement et l’utilisation selon les directives du tribunal. Le tribunal fédéral a rejeté cette action. Il a conclu que l’injonction étatique existante empêchait Network Solutions de placer le domaine sous contrôle fédéral et que le litige impliquait également les obligations contractuelles de Network Solutions envers Clue Computing.

Les éléments probatoires sont inhabituellement complets:

Date:avis le 1er février 1996, suivi de l’action étatique, de l’injonction de juin et de la décision fédérale en 1996.
Acteurs:Network Solutions, Clue Computing, Hasbro, le tribunal de district du comté de Boulder et le tribunal fédéral de district.
Enregistrement spécifique:l’enregistrement CLUE.COM dans le système d’enregistrement faisant autorité de Network Solutions, ainsi que le dossier de litige du registrar et la soumission de marque concurrente.
Décision:si le titulaire enregistré devait produire des preuves qualifiantes, accepter un nom de remplacement, faire face à une suspension ou obtenir une protection judiciaire.
Sources de vérité concurrentes:l’enregistrement, la preuve de marque de Hasbro, la relation d’enregistrement, l’utilisation réelle, les obligations contractuelles et les ordonnances judiciaires.
Résultat:le titulaire enregistré a reçu un avis, est entré dans la contestation procédurale et a obtenu une injonction préservant l’enregistrement pendant que le litige se poursuivait; l’interpleader fédéral a été rejeté.

Ce cas démontre une légitimité administrative à l’intérieur de la procédure d’enregistrement sous-jacente du registrar. L’enregistrement actuel déterminait quelle partie Network Solutions traitait comme le titulaire dont l’utilisation était menacée et dont la réponse importait.

Il ne montre pas que Network Solutions a acquis l’identité de cette partie uniquement en exécutant une requête WHOIS publique. L’avis se rapporte à l’enregistrement faisant autorité géré par Network Solutions, à la politique du registrar, à sa correspondance et au litige qui en a résulté. Le WHOIS public pouvait exposer les informations d’enregistrement et de contact, mais l’affaire n’établit pas que l’affichage public a créé la position procédurale de Clue Computing.

L’enregistrement n’a pas non plus tranché la question ultime de la marque. L’enregistrement de marque de Hasbro fournissait une revendication concurrente. Clue Computing s’appuyait sur le processus contractuel et judiciaire. L’injonction préservait le statu quo; il ne s’agissait pas d’une déclaration finale selon laquelle les données de contact publiques prouvaient la propriété.

L’échelon de la légitimité administrative est donc prouvé, mais seulement avec une qualification importante: il est prouvé pour le traitement par le registrar de la partie enregistrée dans son système d’enregistrement faisant autorité, et non comme un pouvoir constitutif général des champs WHOIS publics.

La collision d’octobre 1995: mutation de base de données et contrôle pratique

Le dossier d’appel fédéral ultérieur dans l’affaireKremen c. Cohenreconstruit un changement d’enregistrement différent d’octobre 1995.

Network Solutions a reçu une lettre prétendant autoriser la suppression d’un enregistrement de domaine existant et l’enregistrement par une autre partie. Agissant sur la base de la lettre, Network Solutions a supprimé l’enregistrement antérieur de sa base de données, a enregistré le domaine au nom d’une autre organisation et a listé un nouveau contact administratif. La lettre s’est avérée plus tard être un faux. Le nouveau titulaire a utilisé le domaine. Lorsque la restauration a été demandée, Network Solutions a d’abord exigé une ordonnance du tribunal. Le litige a finalement abouti à la restauration de l’enregistrement.

L’avis a été rédigé des années après la transaction. Il constitue une preuve de la séquence reconstituée et des conclusions judiciaires, et non un journal d’exploitation contemporain.

Cinq réalités doivent rester distinctes:

Base de données d’enregistrement faisant autorité:Network Solutions a supprimé un enregistrement et en a saisi un autre.
Sortie WHOIS publique:une requête pouvait afficher des informations dérivées du système d’enregistrement actuel, mais l’avis ne dit pas qu’une consultation publique a causé le changement.
Procédure de changement:Network Solutions a agi sur la base de la lettre soumise.
DNS et utilisation:le nouvel enregistrement a été suivi d’une utilisation pratique du domaine.
Preuves documentaires et légales:l’autorisation apparente était en conflit avec le consentement authentique et a été jugée ultérieurement falsifiée.

L’acteur daté était Network Solutions. L’enregistrement spécifique était son entrée de domaine sous-jacente, pas une réponse WHOIS publique. La décision était de mettre fin à un enregistrement, d’en reconnaître un autre et de refuser plus tard une restauration administrative sans ordonnance du tribunal. Les sources concurrentes étaient la demande initiale, l’autorité organisationnelle réelle, la lettre contestée, les témoignages et les conclusions judiciaires. Le résultat a été un changement dans la personne qui pouvait utiliser l’enregistrement en pratique, suivi plus tard d’une restauration judiciaire.

Il s’agit du plus fort exemple antérieur à 1997, dans le matériel examiné ici, d’une conséquence semblable à un droit produite par la mutation d’un système d’enregistrement faisant autorité. L’opération de base de données du registrar a fait plus que mal orienter un message; elle a modifié l’état d’enregistrement opérationnel et l’utilisation pratique.

Cela ne prouve pas que le WHOIS public lui-même a transféré le domaine, conféré la propriété ou poussé Network Solutions à agir. Tout au plus, une réponse publique aurait reflété l’état modifié après la transaction. L’opération constitutive a eu lieu dans les systèmes d’enregistrement et d’administration DNS faisant autorité.

L’affaire ne prouve pas non plus que chaque procédure de mise à jour ancienne était non authentifiée ou peu fiable. Elle documente un échec conséquent impliquant une instruction falsifiée. Généraliser à partir de celle-ci dépasserait les preuves.

Numéro de réseau, ASN et contact: l’enregistrement de ressource de numéros

Le précurseur du contact de réseau DDN

Le rapport d’avril 1991 de Stahl décrivaitNETWORK-CONTACTS, un fichier lisible par l’homme pour les numéros de réseau Internet enregistrés. La section 3.10, à la page 11 du rapport, indique que les informations provenaient des demandes d’enregistrement de numéros Internet traitées par le Hostmaster du NIC et des corrections soumises par les coordinateurs de réseau. Les données brutes étaient stockées dans la base de données WHOIS du NIC. Le dérivé était généré chaque semaine.

Le fichier de contact associait un numéro de réseau et un nom de réseau à un contact et à un identifiant NIC. Son objectif opérationnel était clair: passer d’un numéro à une organisation ou une personne responsable. Il ne contenait pas la correspondance complète d’allocation, l’accord du fournisseur, les preuves d’utilisation ou l’état de routage.

Ce précurseur ne doit pas être confondu avec un enregistrement créé par un registre régional ultérieur. La lignée institutionnelle s’est poursuivie, mais l’opérateur de l’enregistrement et le processus environnant ont changé.

La population InterNIC après avril 1993

La RFC 1400 a placé les adresses IP et les numéros de systèmes autonomes, avec les points de contact associés, dans le service InterNIC après la transition. Cela a formalisé une population centrée sur les objets: une personne apparaissait de plus en plus parce qu’elle était liée à un objet d’infrastructure enregistré.

La transition a amélioré la découvrabilité centrale, mais l’existence d’un objet adresse ou ASN ne prouvait pas en soi un droit. La correspondance d’allocation, la décision administrative du registre, les relations avec les fournisseurs, le routage réel et la conformité continue restaient distincts.

RWhois comme comparaison de conception

RFC 1714, datée de novembre 1994, proposait le protocole Referral WHOIS pour un environnement de registre distribué. Elle distinguait les réponses faisant autorité et celles en cache, définissait des zones d’autorité et utilisait des valeurs de série qui changeaient lorsque les données changeaient. Elle permettait également les opérations d’enregistrement et anticipait les informations d’authentification.

Ces fonctionnalités montrent que les concepteurs reconnaissaient la provenance, l’autorité, la réplication et la mutation comme des préoccupations distinctes. Elles ne prouvent pas que chaque mise à jour de production InterNIC ou de registre régional utilisait les mécanismes proposés.

La méthode d’authentification restait ouverte. La RFC 1714 indiquait que des travaux supplémentaires étaient nécessaires pour la délégation non supervisée et que davantage de recherches étaient requises pour l’authentification du client. Sa section formelle sur la sécurité n’analysait pas les questions de sécurité. Le document permettait également que les données supprimées disparaissent d’un serveur primaire plutôt que d’exiger une conservation permanente uniquement pour le rafraîchissement secondaire.

RWhois est donc une comparaison de conception de 1994, pas la preuve d’un système d’audit déployé universel. Ses valeurs de série suivaient l’état d’une zone d’autorité; elles n’étaient pas nécessairement une explication publique de qui avait changé chaque objet, sous quelle autorité, et pourquoi.

RFC 2050 et les données d’enregistrement conséquentes

En novembre 1996, laRFC 2050a placé l’enregistrement dans une politique d’allocation plus large. Elle décrivait un registre public documentant les allocations et les assignations d’espace d’adressage à des fins d’unicité et de dépannage. Les fournisseurs étaient tenus de soumettre rapidement les informations de réaffectation.

Le document donnait trois raisons pour ces soumissions:

les opérateurs avaient besoin de savoir qui utilisait un numéro de réseau et qui contacter en cas de problèmes opérationnels ou de sécurité;
les informations de réaffectation aidaient à démontrer l’utilisation d’une allocation existante avant que de l’espace d’adressage supplémentaire ne soit justifié;
les données soutenaient les études d’allocation.

La RFC 2050 stipulait qu’aucun bloc CIDR supplémentaire ne serait alloué par un registre régional ou un fournisseur en amont jusqu’à ce qu’environ 80 pour cent des informations de réaffectation aient été soumises. Elle indiquait également que les fournisseurs devaient conserver une justification documentée pour les assignations et que l’indisponibilité de la documentation pouvait affecter les allocations futures.

Il s’agissait d’un changement significatif dans les conséquences. L’enregistrement n’était plus seulement une entrée d’annuaire créée après une allocation. La tenue à jour des données de réaffectation faisait partie des obligations administratives continues du fournisseur.

La RFC 2050 n’a toutefois pas réduit l’allocation à une simple ligne WHOIS. Un registre pouvait exiger des plans d’ingénierie, examiner les assignations précédentes, vérifier l’utilisation, demander une documentation organisationnelle et auditer une demande. Elle distinguait les allocations aux fournisseurs des assignations aux entreprises finales. Elle recommandait de traiter les adresses basées sur les fournisseurs comme des prêts liés à la connectivité et avertissait que l’allocation ne garantissait pas la routabilité. Les transferts nécessitaient l’approbation du registre régional selon les critères applicables.

La signification de l’échelon supérieur de l’enregistrement est donc normative plutôt que spécifique à un cas:

Politique datée:RFC 2050, novembre 1996.
Acteurs nommés par la politique:registres régionaux, registres locaux, fournisseurs et organisations demandeuses.
Enregistrement:données d’allocation, d’assignation et de réaffectation.
Décision:contact opérationnel et si l’utilisation démontrée justifiait de l’espace d’adressage supplémentaire.
Sources de vérité concurrentes:assignations des clients, preuves d’utilisation, plans d’ingénierie, tables de routage, contrats avec les fournisseurs, documents organisationnels et correspondance du registre.
Conséquence spécifiée:une information de réaffectation ou une justification insuffisante pouvait affecter les allocations futures.
Limite:la source ne documente pas un fichier d’allocation particulier antérieur à 1997 dans lequel un registre nommé a pris et achevé cette décision.

La RFC 2050 prouve la relation politique entre l’enregistrement et l’allocation. Sans dossier de cas, elle ne prouve pas avec quelle cohérence la règle a été appliquée ni qu’une sortie WHOIS publique seule a décidé d’une demande spécifique.

Examen et confidentialité en dehors du protocole de consultation

La RFC 2050 fournit deux limites importantes qu’un compte rendu centré sur le WHOIS peut manquer.

Premièrement, la section 6 donnait à une organisation le droit de faire appel d’une décision de registre auprès du registre parent. Le registre d’assignation devait rendre disponible la documentation pertinente. D’autres appels pouvaient remonter la hiérarchie et, après épuisement des autres voies, être portés devant l’IANA pour une décision finale. Chaque registre devait documenter sa procédure d’appel.

Deuxièmement, la section 4.6 exigeait qu’un registre d’assignation traite comme confidentielles les informations spécifiquement marquées comme sensibles par une organisation demandeuse. Lorsque la confidentialité ne pouvait être assurée, le registre parent pouvait être impliqué dans l’assignation.

Aucun de ces contrôles n’était une fonctionnalité du protocole de requête du port 43. Le registre public et le dossier de demande confidentiel n’étaient pas des ensembles de données identiques. Le dossier d’appel et l’enregistrement de contact public étaient également différents. Un utilisateur consultant le WHOIS ne verrait pas nécessairement les preuves d’ingénierie sensibles, le raisonnement du registre ou les documents transmis en appel.

Pour les enregistrements de ressources de numéros, l’audit est donc:

Provenance:les fournisseurs, les registres locaux ou les organisations demandeuses fournissaient les assignations et les pièces justificatives.
Autorité de mise à jour:la RFC 2050 imposait des obligations de soumission rapide, mais elle ne spécifiait pas une méthode technique d’authentification unique pour chaque mise à jour.
Authentification et vérification:les registres pouvaient auditer et exiger des documents corroborants; l’enregistrement public n’exposait pas toutes ces preuves.
Correction et remplacement:le processus du registre environnant pouvait réviser les enregistrements, mais la RFC 2050 ne définissait pas un historique public universel des versions.
Temps:une soumission rapide était requise; une ligne publique actuelle ne révélait pas nécessairement l’historique complet des effets.
Examen:les appels suivaient la hiérarchie du registre et pouvaient en fin de compte parvenir à l’IANA.
Confidentialité:l’enregistrement avait une composante opérationnelle publique, tandis que les informations marquées sensibles par le demandeur devaient rester confidentielles.
Droit:l’enregistrement pouvait affecter l’administration des allocations, mais il ne garantissait pas la routabilité ni ne servait d’instrument complet de titre.

Comparaison des quatre familles d’enregistrements

L’interface WHOIS partagée dissimulait des limites probatoires différentes.

Famille d’enregistrement	Sujet principal	Utilisation antérieure à 1997 la plus solidement prouvée	Preuves de mise à jour et de correction	Limites historiques et d’examen
WHOIS d’annuaire personnel	Un individu et les canaux de contact	Commodité de l’annuaire	Informations d’enregistrement envoyées au NIC; aucune règle publique complète d’authentification des mises à jour dans la RFC 812 ou la RFC 954	Pas d’historique public spécifié des versions par enregistrement ni d’examen des identités contestées
Contacts d’hôtes et de réseaux DDN	Hôtes, réseaux et rôles opérationnels responsables	Dépendance opérationnelle et attribution limitée de responsabilité	Directives réseau, sollicitations mensuelles de corrections, mises à jour volontaires et dérivés générés chaque semaine documentés dans le rapport d’avril 1991	Les versions au niveau du fichier n’exposaient pas nécessairement chaque champ remplacé ou décision de conflit
Enregistrement de domaine et WHOIS	Organisation, domaine, contacts et serveurs de noms	Vérification prescrite; légitimité administrative accomplie dans la procédure d’enregistrement sous-jacente d’un registrar en 1996; conséquences pratiques d’une mutation de base de données faisant autorité en 1995	Demandes de domaine et corrections; vérification par l’analyseur de 1993 par le demandeur initial; politique et correspondance du registrar	Aucune preuve que le WHOIS public seul ait autorisé des changements, créé une légitimité ou décidé d’un droit; les litiges dépendaient des accords, des preuves de marque, du DNS, de la correspondance et des tribunaux
Enregistrement de ressources de numéros	Numéros de réseau, ASN, allocations, assignations et contacts	Contact opérationnel et influence politique sur l’allocation supplémentaire	Demandes d’enregistrement, corrections des coordinateurs, obligations de réaffectation rapide, audits et pièces justificatives	Aucun cas antérieur à 1997 identifié montrant une ligne publique décidant d’une allocation; les preuves confidentielles, le raisonnement, les versions antérieures et les documents d’appel pouvaient rester en dehors de la consultation

Cette comparaison empêche deux fausses histoires.

La première commencerait par l’annuaire personnel de 1982 et traiterait chaque objet d’enregistrement ultérieur comme une version élargie de la même ligne de pages blanches. Cela ignore les devoirs distincts assumés par les gestionnaires d’hôtes, les administrateurs de domaine, les titulaires, les fournisseurs et les contacts de ressources.

La seconde commencerait par une mutation conséquente d’enregistrement de domaine et lirait son pouvoir rétroactivement dans chaque réponse WHOIS antérieure. Cela ignore la différence entre un affichage public et le système faisant autorité capable de modifier un enregistrement ou une délégation.

L’échelle, avec ses limites exposées

L’échelle probatoire peut maintenant être testée par rapport à des comportements datés plutôt qu’aux seuls noms de champs.

Échelon	Acteur et enregistrement datés	Décision	Source de vérité concurrente	Résultat et limite
Commodité de l’annuaire	Utilisateurs d’ARPANET et de DDN décrits dans la RFC 812 (1982) et la RFC 954 (1985), interrogeant des entrées personnelles et organisationnelles	Qui contacter ou quel enregistrement correspondait à un nom	Annuaires d’employeurs, comptes d’hôte, listes de site, confirmation directe	Le service fournissait un point de départ lisible par l’homme; aucune conséquence de droit n’est démontrée
Dépendance opérationnelle	Sites affectés et CERT/CC dans l’incident italien de décembre 1990, utilisant un enregistrement de réseau du DDN NIC	Quelle institution contacter au sujet du trafic observé	Journaux, informations de routage, administration locale, enquête directe	La consultation a orienté la réponse vers une institution
Attribution de responsabilité	Les mêmes intervenants, utilisant l’association réseau-organisation	Quelle organisation devait enquêter et agir	Contrôle de la machine réelle et autorité institutionnelle	La responsabilité a été attribuée au niveau du réseau ou de l’institution, et non de manière concluante à un administrateur de machine ou à un utilisateur
Légitimité administrative	Network Solutions le 1er février 1996, utilisant l’enregistrement CLUE.COM et le dossier de litige pour notifier Clue Computing	Quel titulaire enregistré devait répondre à la revendication de marque et pouvait contester une suspension ou un changement menacé	Preuves de marque, relation d’enregistrement, utilisation réelle, obligations contractuelles, ordonnances judiciaires	Le titulaire enregistré a reçu un avis, a intenté un procès et a obtenu une injonction; il n’est pas démontré que le WHOIS public seul ait créé cette légitimité
Inférence semblable à un droit	Network Solutions en octobre 1995, modifiant sa base de données d’enregistrement de domaine faisant autorité après une prétendue autorisation	S’il fallait mettre fin à un enregistrement, en créer un autre et restaurer plus tard l’état d’origine	Autorité authentique, correspondance originale, lettre contestée, témoignages, conclusions judiciaires	La mutation de la base de données a produit des conséquences pratiques; l’affaire ne montre pas qu’une consultation WHOIS publique ait causé le changement

L’administration des ressources de numéros a atteint un échelon supérieur connexe mais moins documenté dans la RFC 2050. Les données d’enregistrement et de réaffectation étaient des entrées prescrites pour les décisions d’allocation futures. Sans dossier de cas complet, cela reste une preuve politique de conséquence administrative attendue plutôt que la preuve qu’une ligne publique a décidé d’une demande particulière.

Le résultat est asymétrique. La commodité de l’annuaire, la dépendance opérationnelle et l’attribution de responsabilité sont bien étayées par les spécifications et un incident daté. La légitimité administrative est démontrée dans une procédure spécifique de registrar impliquant un enregistrement de domaine faisant autorité. La conséquence semblable à un droit est démontrée par la mutation de ce système faisant autorité. Les preuves disponibles ne montrent pas que le WHOIS public soit devenu une source universelle de légitimité ou de titre avant 1997.

D’où venait l’autorité

Le WHOIS n’a pas acquis de force par le seul protocole technique.

La RFC 812 indiquait que le NIC de SRI maintenait le service pour le compte de la Defense Communications Agency. Le rapport d’avril 1991 de Stahl identifie un contrat gouvernemental, le contractant responsable, le livrable, la base de données source et les fichiers dérivés. La RFC 1400 documente la transition des services non DDN vers InterNIC.

L’histoire juridique du Government Accountability Officerapporte que la National Science Foundation a conclu un accord de coopération avec Network Solutions en 1993 pour fournir des services d’information étendus et coordonnés pour l’Internet non militaire. Ces services comprenaient l’enregistrement de domaines de second niveau, tandis que Network Solutions coopérait également avec l’USC pour la gestion de la zone racine.

L’autorité pratique de la base de données provenait de ces missions institutionnelles, des services d’enregistrement exécutés dans ce cadre et de la volonté d’autres acteurs de considérer l’enregistrement tenu à jour comme actuel. L’autorité résidait dans la fonction reconnue d’une organisation et sa capacité à agir sur sa base de données, et non dans la syntaxe d’une réponse du port 43.

L’histoire du GAO comporte également un avertissement probatoire. Elle décrit ses conclusions comme limitées par un dossier incomplet et note que des documents contractuels clés des années 1970 aux années 1990 n’ont pu être obtenus. Les accords et rapports qui subsistent situent les services dans le cadre du parrainage fédéral et de l’exécution par des contractants. Ils ne soutiennent pas une affirmation générale selon laquelle un contrat aurait converti chaque champ de contact en titre légal.

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, l’IANA et les registres régionaux étaient des institutions liées, mais elles n’étaient pas interchangeables. Leurs publics, leurs fonctions assignées, leurs sources et leurs enregistrements changeaient. La continuité des données ne garantissait pas que chaque entrée héritée ait été réauthentifiée selon les procédures d’un successeur.

Confidentialité et coûts de correction dans leur contexte historique

La confidentialité entre dans cette histoire parce que les champs originaux ont été choisis pour la joignabilité.

Le service d’annuaire personnel exposait délibérément suffisamment d’informations pour trouver et contacter des individus. Les fichiers opérationnels DDN pouvaient exposer les titulaires de rôles et de nombreux canaux de contact parce que les administrateurs distants devaient pouvoir joindre quelqu’un capable d’agir. Les enregistrements de domaine reliaient des contacts identifiables à des fonctions administratives et techniques. Les enregistrements de ressources de numéros reliaient les identifiants de réseau à des contacts opérationnels.

Le glissement historique n’allait pas simplement de l’information privée à l’information publique. Il allait d’un annuaire personnel desservant une communauté relativement limitée à des enregistrements d’infrastructure consultés lors d’incidents, de changements d’enregistrement, de litiges et de décisions d’allocation.

Ce changement a accru la conséquence d’un rôle obsolète. Un ancien contact pouvait rester visible après un changement organisationnel. Un opérateur technique actuel pouvait manquer d’autorité de politique. Un représentant administratif pouvait être autorisé mais incapable de réparer une machine. La sollicitation mensuelle de corrections et la publication hebdomadaire réduisaient les retards dans certaines parties du système DDN, mais elles ne garantissaient pas que la réalité externe et chaque dérivé changeaient simultanément.

Le dossier montre également un rétrécissement de la population. La RFC 1400 indiquait que les enregistrements individuels d’InterNIC couvriraient principalement les points de contact associés aux nœuds actifs, tandis que les projets généraux d’annuaire personnel pourraient être distribués ailleurs. En 1996, la RFC 2050 distinguait les informations d’enregistrement publiques des éléments de demande sensibles que les registres étaient tenus de garder confidentiels lorsque le demandeur les marquait comme tels.

Il s’agissait de limites propres à la période. Elles ne devraient pas être réécrites comme si une architecture ultérieure des données d’enregistrement régissait déjà 1982. La question historique est plus étroite: la quantité et la forme des informations de contact sont-elles restées proportionnées après que les champs ont commencé à influencer des décisions au-delà de la découverte.

Réduire les informations publiques pourrait également imposer des coûts opérationnels. L’incident de décembre 1990 montre pourquoi une consultation centrale importait: elle donnait aux intervenants distants un point de départ institutionnel. La faiblesse de l’enregistrement n’était pas simplement qu’il exposait un contact. C’était qu’une association au niveau de l’organisation pouvait être moins précise que ce qu’exigeait un incident.

Le problème politique n’était donc pas une simple opposition entre ouverture et confidentialité. Il s’agissait de savoir comment préserver la joignabilité spécifique au rôle sans traiter la personne nommée comme l’acteur, le contrôleur, la partie contractuelle ou le titulaire légal dans tous les contextes.

Scénario contrefactuel A: des enregistrements authentifiés, versionnés et expressément non constitutifs

Supposons que les mêmes entrées d’annuaire aient été accompagnées d’une authentification procédurale plus forte, conservé les versions antérieures, des horodatages d’effet, des raisons enregistrées pour les changements et une déclaration explicite selon laquelle les champs décrivaient des contacts plutôt que de créer des droits.

Il s’agit d’une comparaison de conception limitée. Des formulaires papier contrôlés, la correspondance conservée, les procédures de rappel, les journaux datés et les contresignatures institutionnelles étaient conceptuellement disponibles durant la période. Un système d’identité cryptographique universel liant chaque contact réseau à une organisation n’était pas une exigence établie de la RFC 812. Les hypothèses ultérieures concernant l’identité fédérée, les certificats automatisés ou les services structurés de données d’enregistrement ne doivent pas être projetées rétrospectivement comme des devoirs que les concepteurs de 1982 auraient ignorés.

Dans cette limite, des contrôles plus forts auraient amélioré plusieurs décisions.

Un utilisateur pourrait distinguer quand un contact est devenu actuel et si l’entrée précédait une fusion, une démission, un changement de fournisseur ou un litige de délégation. Le personnel pourrait identifier la personne ayant demandé une mutation, l’autorité revendiquée et l’enregistrement antérieur remplacé. Une partie contestataire pourrait contester la transaction précise plutôt que de simplement se confronter à la dernière réponse publique.

La collision d’enregistrement d’octobre 1995 illustre la valeur. Si le registrar avait exigé une confirmation par un canal établi indépendamment, documenté l’autorité revendiquée par le soumettant, conservé l’enregistrement remplacé comme un état historique visible et séparé le changement d’enregistrement demandé de l’action DNS résultante, l’instruction défectueuse aurait pu être détectée plus tôt ou annulée plus efficacement.

La sauvegarde n’aurait pas converti l’annuaire en un système de titre. L’authentification prouve qu’une partie identifiée a fait une déclaration. Elle ne prouve pas nécessairement que la partie possédait l’autorité corporative, qu’un accord restait valide, qu’une relation de fournisseur se poursuivait ou qu’un tribunal reconnaîtrait le droit revendiqué.

Le versionnage a une limite similaire. Il peut montrer qu’un champ a changé et conserver ce qui le précédait. Il ne peut pas décider quel état était légalement correct. Un code de raison peut expliquer pourquoi le personnel a agi, mais la raison peut encore dépendre d’un document falsifié ou d’une interprétation contestée.

Une déclaration explicite de non-droit aurait clarifié l’intention institutionnelle. Les RFC 1032 et RFC 1591 fournissaient déjà des limites substantielles connexes en refusant d’arbitrer les droits locaux ou en séparant l’enregistrement du statut de marque. Répéter de telles limites dans la réponse publique aurait pu réduire les inférences imprudentes.

Une dérive de l’autorité se serait probablement encore produite. Les institutions favorisent les enregistrements qui sont disponibles, lisibles et tenus à jour par l’organisme responsable du service. Un annuaire bien authentifié pourrait attirer encore plus de dépendance. La différence est que les utilisateurs ultérieurs pourraient mieux distinguer une assertion de contact d’une allocation, un enregistrement d’un contrat, et un affichage actuel des preuves soutenant un changement.

Scénario contrefactuel B: pas d’annuaire, tandis que les relations sous-jacentes survivent

Supprimez maintenant l’annuaire public tout en laissant les contrats, la correspondance d’allocation, les demandes d’enregistrement, les opérations de routage, les délégations DNS, les dossiers organisationnels, les journaux et les réseaux téléphoniques intacts.

De nombreuses décisions restent possibles.

Un registre peut déterminer qui a reçu une allocation à partir de sa correspondance et de son dossier de décision. Un fournisseur peut identifier son client à partir d’un contrat de service. Un registrar peut examiner une demande et les instructions subséquentes. Un administrateur de domaine peut examiner la délégation active et les serveurs de noms faisant autorité. Un opérateur peut inspecter les informations de routage et escalader par les réseaux adjacents. Un tribunal peut évaluer le consentement, l’autorité organisationnelle, les accords, les enregistrements de marque et les témoignages.

La fonction manquante est la découverte rapide à travers les frontières institutionnelles.

Dans l’incident de décembre 1990, les sites affectés posséderaient toujours des journaux, mais le chemin d’un numéro de réseau à une institution pertinente serait plus lent. Les intervenants pourraient devoir passer par les relations de routage, les fournisseurs ou des demandes manuelles. L’annuaire n’a pas créé les journaux ni la responsabilité de l’institution. Il a réduit le coût de la recherche de l’institution qui pourrait agir.

Dans l’administration des domaines, le DNS pourrait montrer les serveurs de noms en fonctionnement, et la correspondance d’enregistrement pourrait montrer la demande initiale. Sans annuaire commun, trouver le représentant administratif serait plus difficile. Le fonctionnement du DNS ne prouverait toujours pas le consentement organisationnel.

Dans le litige CLUE.COM, Network Solutions pourrait identifier son titulaire à partir du fichier d’enregistrement faisant autorité et de la correspondance même si aucun service WHOIS public n’existait. Le registrar pourrait toujours envoyer un avis, et le titulaire pourrait toujours invoquer des recours contractuels ou judiciaires. Cela montre que la légitimité administrative dans cette affaire ne dépendait pas uniquement de la commodité de la consultation publique.

Dans l’administration des ressources de numéros, un registre pourrait évaluer une allocation supplémentaire à travers le dossier de demande et les preuves d’utilisation. Sans enregistrements standardisés d’enregistrement et de réaffectation, reconstituer les assignations antérieures et localiser les contacts en aval serait plus lent et moins cohérent.

Ce scénario contrefactuel identifie la valeur distinctive du WHOIS: il rendait les relations hétérogènes consultables à partir d’un identifiant. Il faisait apparaître la première personne ou organisation pertinente.

Il démontre également pourquoi la commodité ne doit pas être confondue avec l’autorité constitutive. La relation sous-jacente pourrait survivre à l’absence de l’annuaire. L’annuaire rendait cette relation lisible et exploitable; selon le système, la transaction d’enregistrement faisant autorité, la décision d’allocation, le contrat ou l’état opérationnel restaient ailleurs.

Le seuil de 1997

L’histoire institutionnelle d’ARINindique qu’il a été créé en décembre 1997 en tant qu’organisme à but non lucratif indépendant fournissant des services d’enregistrement IP dans sa région. Sonrapport annuel de 1999date le début des opérations au 22 décembre 1997.

Avant cette date, plusieurs propositions étaient devenues bien étayées:

une requête centrale pouvait associer des personnes et des organisations à des identifiants Internet;
les contacts spécifiques à un rôle étaient censés être joignables et capables d’agir;
les Hostmasters utilisaient les demandes, les directives, les administrateurs reconnus et les soumissions de corrections pour maintenir les enregistrements;
certains dérivés DDN étaient regénérés chaque semaine et soutenus par des sollicitations mensuelles de corrections;
les opérateurs utilisaient les enregistrements de contacts réseau pour décider où adresser les rapports d’incident;
il était demandé aux administrateurs de domaine de comparer les données WHOIS avec l’enregistrement prévu et les informations du serveur;
un titulaire de domaine enregistré pouvait recevoir un avis et occuper une position procédurale conséquente dans un litige de registrar achevé;
la mutation d’un enregistrement de domaine faisant autorité pouvait produire des conséquences pratiques;
les données de réaffectation des ressources de numéros étaient des entrées prescrites pour le contact opérationnel et l’administration des allocations ultérieures;
les décisions d’allocation pouvaient être auditées, faire l’objet d’un appel et être étayées par des éléments confidentiels en dehors du registre public.

Plusieurs propositions plus fortes restent non prouvées par les preuves examinées ici:

que chaque mise à jour personnelle, d’hôte, de domaine ou de ressource de numéros utilisait une méthode uniforme de vérification d’identité;
que chaque enregistrement public exposait un historique complet des valeurs antérieures et des raisons du changement;
qu’un contact public existant possédait automatiquement l’autorité pour confirmer ou remplacer un enregistrement;
que le demandeur initial de la RFC 1400 était reconnu en raison d’une liste de contact public antérieure;
que le WHOIS public seul a créé la légitimité administrative de Clue Computing dans le litige de 1996;
que le changement d’enregistrement de Kremen a été causé par la dépendance à une requête WHOIS publique plutôt que par la procédure de changement du registrar et la mutation de la base de données;
qu’une ligne publique de ressource de numéros seule a décidé d’une demande d’allocation documentée antérieure à 1997;
qu’un contact listé établissait de manière concluante le contrôle technique actuel, la propriété légale ou le droit contractuel;
que la délégation DNS établissait un droit sur un bloc d’adresses IP;
qu’un registre régional ultérieur maintenait ou créait des enregistrements avant de commencer à fonctionner.

La transition de la commodité à l’autorité n’a donc pas eu de date unique. Ses étapes les plus fortes se sont produites dans différentes familles d’enregistrements.

Le WHOIS d’annuaire personnel a établi une découverte commode. Les contacts d’hôtes et de réseaux DDN sont passés à la dépendance opérationnelle et à l’attribution de responsabilité. Un litige de domaine achevé en 1996 montre une légitimité administrative attachée à la relation d’enregistrement faisant autorité du registrar, tandis que la séquence Kremen de 1995 montre des conséquences pratiques de la mutation de ce système faisant autorité. La politique des ressources de numéros a rendu les données d’enregistrement pertinentes pour les décisions d’allocation futures tout en conservant les documents justificatifs, la confidentialité et l’appel en dehors de la consultation publique.

Les échelons supérieurs de l’échelle sont réels mais étroitement situés. Avant 1997, le dossier disponible ne montre pas que le WHOIS public soit devenu un instrument de titre universel. Il montre quelque chose de plus fragile et révélateur sur le plan institutionnel: une couche de contact commode devenant la première preuve consultée, le premier cadre posé autour d’un problème, et le reflet visible de décisions conséquentes dont l’autorité provenait encore de bases de données, de procédures, de contrats, de systèmes opérationnels et d’un examen au-delà de la consultation.