Résumé

  • Le programme ZONE du RFC 1296 maintenait une liste de domaines et de serveurs, vérifiait par SOA qu'un serveur contacté faisait autorité, puis demandait AXFR afin de constituer une table à partir des enregistrements reçus. Dans l'étude, un hôte était un groupement découvert de nom(s) et d'adresse(s) IP, non une preuve d'accessibilité directe.
  • Les échecs ou refus de transfert et les hôtes absents de DNS tiraient la collecte vers le bas ; des entrées mal formées, non autoritatives ou conservées après un renommage pouvaient tirer le résultat vers le haut. Après revue manuelle, l'auteur qualifia le résultat de minimum plutôt que de chiffre effectif.

Le résultat le plus facile à retenir de RFC 1296, Internet Growth (1981-1991) est sa série de nombres. Le geste le plus important est ailleurs : le document refuse de laisser un nombre de lignes recueillies répondre sans réserve à la question « combien y avait-il d'Internet ? ». Il laisse apparaître les étapes qui séparent une réponse DNS, un enregistrement reçu, une règle de regroupement et un jugement sur une population.

ZONE, pour Zealot Of Name Edification, ne se contentait pas de parcourir des étiquettes. Le programme gardait une liste de domaines, de serveurs et un indicateur disant si les informations d'un domaine avaient déjà été chargées depuis l'un de ces serveurs. Une anomalie de BIND l'obligeait à être amorcé avec la liste des domaines de premier niveau et de leurs serveurs de noms. Pour un domaine qui n'avait pas encore été transféré, il contactait un serveur en TCP, envoyait d'abord une requête SOA afin de vérifier l'autorité de ce serveur pour le domaine demandé, puis seulement une requête AXFR pour recevoir les enregistrements de ressource.

Un NS reçu élargissait la liste de travail avec le domaine et le serveur référencés. Les enregistrements A, CNAME, HINFO et MX reçus rejoignaient une table d'hôtes en mémoire. Le programme s'arrêtait lorsqu'il avait refait un tour complet sans rien apprendre de nouveau, puis écrivait une sortie de type HOSTS.TXT. C'est une chaîne d'observation, pas une formule magique : serveur interrogé, contrôle d'autorité, tentative de transfert, données retournées, insertion dans une table, puis calcul.

Chacun de ces verbes porte une preuve plus limitée que le suivant. Une réponse SOA appuie l'idée qu'à cet instant le collecteur avait vérifié le serveur avant de demander la zone. Un AXFR réussi appuie l'idée que des enregistrements ont été rendus disponibles à ce collecteur. Une règle d'analyse peut joindre certains noms et adresses. Rien de cela ne démontre qu'une machine physique répondait depuis Internet, qu'un nom représentait une organisation déterminée, que toutes les machines avaient une entrée DNS, ni que l'objet ainsi constitué était la totalité d'Internet.

La méthode définissait l'objet avant de produire la courbe

Le RFC rapproche deux séries qui n'observent pas exactement la même chose. Pour les années antérieures à DNS, les comptes viennent de copies choisies de l'Official Host Table de SRI-NIC. DNS fut introduit autour de 1984 et demanda presque quatre ans avant d'être pleinement déployé sur Internet ; à ce moment-là, beaucoup d'hôtes n'étaient déjà plus enregistrés dans la Host Table. Écrit en 1986, ZONE devait d'abord servir pendant cette transition : marcher dans l'arbre DNS et bâtir une table pour les sites qui n'avaient pas encore basculé. Il ne fut finalement pas employé ainsi, mais comme outil statistique.

Cette biographie technique change la lecture des séries. Les premières versions de BIND avaient de graves difficultés avec les transferts de zone, et ZONE ne put recueillir des données DNS complètes qu'à partir d'environ 1988. Le temps de collecte passa d'heures à une semaine ; la table approcha 50 mégaoctets. Dans son mode alors courant, le programme ne conservait que les noms d'hôtes et les adresses IP, en ignorant les données de protocole, d'information d'hôte et de MX ; des utilitaires tels que sort, uniq et grep extrayaient ensuite les statistiques. SRI l'exécutait tous les trois mois.

Une collecte qui dure une semaine n'est pas un instantané. Une exécution trimestrielle n'est pas une connaissance continue. Une donnée volontairement ignorée ne peut pas être invoquée plus tard comme preuve. Le nombre publié dépend donc de la date de départ, de l'amorçage, des serveurs qui ont répondu, des transferts achevés, des types d'enregistrements retenus et de la règle appliquée à la sortie. La méthode ne se situe pas en note de bas de page : elle fait partie du sens du nombre.

Le RFC donne aussi une définition explicite de son unité. Pour cette étude, un hôte est un groupement [nom(s), adresse(s)-IP] découvert dans DNS. Cette règle évite de compter plusieurs fois une machine qui possède plusieurs noms ou plusieurs adresses. Elle ne décide pas si l'hôte est directement accessible. Lorsqu'il compte les domaines, ZONE inclut tous ceux auxquels renvoie un NS, y compris les sites qui ne portent qu'une fonction de relais de courrier. La normalisation fournit une unité cohérente ; elle ne transforme pas cette unité en définition universelle de la présence sur Internet.

Les absences avaient une direction

La limite la plus nette tenait à ce que le collecteur ne pouvait obtenir. Certains sites n'autorisaient pas les transferts de zone. ZONE renonçait après trop d'échecs. Lors de l'exécution du 1er janvier 1992, environ 800 domaines sur 17 000 ne purent être transférés. Le texte ajoute qu'il faut supposer que tous les hôtes d'Internet ne sont pas enregistrés dans un serveur de domaine. Ces deux faits ne sont pas de simples erreurs de bruit : ils retirent de la collecte des enregistrements qui auraient pu contribuer au total. Le RFC indique donc que les statistiques recueillies sont inférieures aux quantités effectives.

Cette affirmation reste volontairement bornée. Elle ne prétend pas connaître la taille de la part manquante. Elle ne dit pas qu'une zone indisponible contenait nécessairement beaucoup d'hôtes, ni que chaque hôte absent de DNS devait être compté sous une autre forme. Elle conserve seulement la direction du défaut connu : une méthode fondée sur les zones transférées ne voit pas ce qui refuse le transfert, échoue trop souvent ou n'est pas inscrit dans la source qu'elle utilise.

La borne basse n'est donc pas synonyme de recensement incomplet dont il suffirait d'ajouter un pourcentage. C'est un résultat conditionnel : sous la définition du RFC, avec les accès décrits et après la revue que le document rapporte, le chiffre observé ne doit pas être promu au rang de quantité réelle. Cette discipline est plus informative qu'une précision fictive.

Les doublons ne comblaient pas les manques

Le texte décrit pourtant une erreur qui va dans l'autre sens. Une revue manuelle de la table signalait de nombreuses entrées aléatoires dans DNS. Des données mal formatées pouvaient faire apparaître de faux serveurs ou hôtes. Un serveur pouvait ne pas être autoritatif pour le domaine auprès duquel il figurait. Lorsqu'un domaine était renommé, ses anciennes entrées pouvaient rester en place pendant la transition et conduire à compter deux fois chaque hôte du domaine. Ces éléments ajoutent ou répètent des observations ; ils peuvent pousser le résultat vers le haut.

La conclusion du RFC ne consiste pas à nier ce risque. Elle le compare aux absences. Après balayage manuel, l'auteur estime que les entrées additionnelles sont insignifiantes par rapport aux éléments manquants déjà décrits. C'est cette comparaison, et non la simple existence d'un programme ZONE, qui permet de parler d'un minimum. L'expression ne doit pas être retirée de son contexte pour affirmer qu'une marche DNS sous-estime toujours tout réseau, dans toute période et avec toute politique de collecte.

La distinction révèle deux travaux souvent confondus. Le premier est archivistique : conserver quel domaine a été tenté, quel serveur a été joint, quel contrôle SOA a été exécuté, quel transfert a réussi ou échoué, quels enregistrements ont été reçus et à quel moment. Le second est analytique : décider si les enregistrements représentent l'objet étudié et si le profil des erreurs autorise un sens pour l'écart.

Trier et dédupliquer réduisent certains doubles comptes ; ces opérations ne disent pas combien d'hôtes se cachent derrière un transfert refusé, si un ancien nom représente encore une machine, ni si une adresse annoncée accepte une connexion.

Un nom visible ne garantissait pas l'accessibilité

Le RFC pose lui-même le problème de périmètre. Trouver des entrées d'hôtes dans DNS n'implique pas que ces hôtes soient accessibles depuis Internet. Des entreprises pouvaient placer des passerelles de courrier entre leurs réseaux locaux et Internet, interdisant l'accès direct tout en annonçant tous les hôtes ou seulement la passerelle. Le document demande alors lesquels doivent compter. Il demande aussi si les domaines MX-only d'un site hors Internet, par exemple Usenet, appartiennent réellement à une étude de taille d'Internet.

Ce sont des problèmes de définition, non des défauts à corriger par une requête supplémentaire. Une réponse DNS peut prouver quelque chose sur un enregistrement retourné. Un AXFR achevé peut prouver ce qu'un collecteur a reçu. Une règle de regroupement peut prouver comment une table a été dédoublonnée. Pour conclure à la joignabilité, à l'appartenance, à l'identité ou à une population totale, il faut ajouter une autre définition, une autre observation ou une autre autorité.

Le coût de la collecte rend la frontière institutionnelle plus nette encore. Télécharger l'information de tous les domaines produisait beaucoup de trafic et ajoutait une charge CPU à chaque serveur contacté. RFC 1296 suggère qu'un effort organisé pourrait faire fonctionner un seul programme à intervalles réguliers, afin d'éviter plusieurs collecteurs. C'est une proposition de coordination de la mesure, non la preuve qu'un acteur détenait un droit sans limite de sonder ou de définir seul le dénominateur public.

Le projet futur ne devenait pas un résultat présent

Dans ses questions futures, le document décrit ZONE sur un DECsystem-20, écrit en assembleur, proche des limites d'espace d'adressage et gardant les données en mémoire afin de faire correspondre des surnoms avec des noms officiels avant d'écrire les enregistrements complets. Il propose une nouvelle architecture : données sur disque, transferts parallèles, cycle continu de semaines à un mois et base locale mise à jour par domaine. Le projet montre quelle croissance de charge l'auteur anticipait. Il ne prouve ni qu'un remplaçant fut construit, ni qu'une base continue exista, ni qu'un compte ultérieur devint complet.

Un collecteur plus fréquent peut réduire l'âge d'une observation. Des transferts parallèles peuvent réduire le temps écoulé pendant une marche. Un disque peut limiter les pertes après un arrêt. Aucune de ces améliorations n'efface l'écart entre enregistrement et hôte joignable, entre nom annoncé et population, entre borne observée et quantité réelle. Le RFC conserve ces écarts au lieu de les laisser disparaître sous son graphique.

Sources et limites des preuves

La seule source est RFC 1296. Elle soutient le statut Informational de janvier 1992 ; les copies de Host Table et ZONE ; la séquence SOA/AXFR ; les types d'enregistrements, le groupement d'hôte, les omissions, les doublons et la conclusion de borne basse ; les questions de périmètre ; les chiffres de janvier 1992 ; le coût et la proposition d'architecture future. Elle ne démontre pas une population DNS actuelle, un AXFR réel, une propriété contemporaine de BIND, une politique d'énumération actuelle, la joignabilité d'un hôte, l'appartenance d'une organisation, une posture de sécurité, un collecteur de remplacement déployé ou un résultat postérieur.