Résumé

  • Une collecte à la racine atteste un nom, un type de requête et une réponse dans un périmètre donné ; elle n’identifie pas, à elle seule, le logiciel, l’entreprise ou le dommage éventuel.
  • La RFC 8023 rapporte les limites d’un échantillon DITL pour fabriquer des listes de blocage et distingue les mesures réelles des explications encore spéculatives.
  • Pour le cycle 2026, l’ICANN formule la même prudence : le score de magnitude du Name Collision Observatory n’est qu’un facteur et un faible volume ne vaut pas autorisation de déléguer.

Le ticket d’incident ne contient qu’une ligne : un suffixe interne a été demandé à la racine. L’horodatage est exact, le type DNS aussi, et l’instance de collecte est connue. Quelques heures plus tard, le ticket affirme déjà qu’un ancien logiciel d’une grande entreprise est vulnérable à la délégation du suffixe.

Entre les deux formulations, aucune nouvelle mesure n’a été ajoutée.

Une requête visible à la racine peut provenir d’une liste de recherche, d’un nom codé en dur, d’un résolveur mal configuré, d’une sonde ou d’un appareil qui ne se réveille qu’une fois par mois. Un récursif, un forwarder et une traduction d’adresses séparent souvent l’adresse observée de la machine qui a construit le nom. Dix appareils bavards peuvent produire davantage de trafic que dix mille dépendances silencieuses.

C’est cette distance entre trace et explication que la RFC 8023 rend exploitable. Publiée en novembre 2016, elle est une Independent Submission de catégorie Informational, signée par Matthew Thomas, Allison Mankin et Lixia Zhang. Elle rend compte d’un atelier public tenu à Londres en mars 2014. Le comité du programme, les auteurs des communications et les participants formaient un collectif plus vaste. Ce texte n’est pas une norme IETF et sa signature ne confère à aucun des trois auteurs un pouvoir sur les décisions de l’ICANN.

La collision décrite naît du chevauchement de deux contextes. Une application utilise un suffixe dans un espace privé et suppose que le DNS public répondra NXDOMAIN. Cette hypothèse n’est parfois ni normalisée ni consignée. Si le même libellé entre ensuite dans la racine mondiale, l’échec attendu peut devenir une réponse positive. Le trafic peut être dévié, un service interne peut cesser de fonctionner, ou une donnée peut atteindre un destinataire imprévu.

La racine voit la fuite. Elle ne voit pas l’intention de l’application.

DITL était un microscope, pas une carte exhaustive

La RFC 8023 décrit Day in the Life of the Internet, ou DITL, comme une collecte coordonnée de courte durée, alimentée par un sous-ensemble variable d’opérateurs de serveurs racine. Son usage était la recherche. Elle ne constituait pas une vue opérationnelle continue de tout le système.

Cette provenance change l’interprétation d’une absence. Un nom absent pendant la fenêtre peut apparaître la semaine suivante, sur une autre instance ou lors du démarrage trimestriel d’un équipement. Une présence, elle, établit seulement que le chemin a été emprunté au moins une fois dans le périmètre observé.

Des participants ont aussi craint que la publication des chaînes candidates au programme des nouveaux gTLD influence les collectes ultérieures. Le rapport garde la bonne formulation : aucune preuve empirique concluante d’une manipulation n’a été présentée. Il faut donc enregistrer le risque d’effet de mesure sans le transformer en accusation.

Une étude de l’atelier a comparé les libellés de deuxième niveau trouvés dans DITL avec une collecte de plusieurs mois aux racines A et J. La RFC rapporte que le résultat démontrait l’inefficacité de listes de blocage bâties à partir de données échantillonnées comme DITL. Ce n’est pas un verdict contre toute liste. C’est la réfutation d’une propriété précise : l’échantillon ne garantissait pas l’exhaustivité dont ce remède avait besoin.

Une autre analyse a compté les requêtes arrivant à la racine avec le bit recursion desired. Le signal était bien présent, mais son origine technique demeurait indéterminée. Les explications sur des clients naïfs étaient hypothétiques, et aucun dommage réel ou potentiel n’avait été identifié dans cette analyse. Le bit est une observation ; le produit fautif et l’impact sont deux questions supplémentaires.

Trois colonnes au lieu d’un récit automatique

Un dossier solide sépare observation, inférence et corroboration.

L’observation conserve le nom demandé, le type, les indicateurs, la réponse, l’instance ou le point de mesure, la période et ce que le collecteur sait réellement de la source. L’inférence formule une hypothèse et ses concurrentes : expansion d’un suffixe de recherche, nom fixe d’un logiciel, erreur d’un résolveur. La corroboration arrive d’un endroit plus proche du phénomène : trace côté client, configuration d’entreprise, inventaire logiciel, dossier d’assistance ou essai reproductible.

Le risque forme une quatrième colonne. Il faut préciser comment une réponse publique modifierait le comportement, quel actif serait touché, à quelle fréquence la dépendance s’exécute et quelle conséquence suivrait. Le nombre de requêtes ne mesure directement ni les utilisateurs, ni les installations, ni la gravité.

La RFC 8023 mentionne justement une voie complémentaire : partir d’un modèle de résolution au niveau du client, puis dériver des mesures des étapes suivies par la bibliothèque. Les données de racine restent précieuses pour trouver des motifs et choisir une enquête. Le modèle local montre où chercher la cause.

Les deux directions doivent se rejoindre. L’analyse descendante repère un libellé, une période et une concentration. L’enquête ascendante retrouve l’application, l’ajout du suffixe, le récursif, le franchissement de la frontière privée et la réponse attendue. Quand elles décrivent le même chemin, l’hypothèse devient testable.

La responsabilité peut alors être nommée sans être inventée. L’entreprise maîtrise sa convention interne et ses listes de recherche ; un éditeur maîtrise un nom codé dans son logiciel ; le résolveur maîtrise certains choix de transfert ; l’opérateur de registre applique les contrôles d’activation ; l’ICANN possède le processus d’évaluation concerné ; l’IETF peut définir un mécanisme partagé. Aucun de ces acteurs ne détient toute la chaîne.

Le tableau de bord 2026 conserve la limite

Le Name Collision Observatory de l’ICANN présente, pour le cycle 2026, des données historiques de magnitude DNS sur les chaînes candidates. L’ICANN précise que cette valeur n’est qu’un facteur parmi plusieurs dans l’évaluation initiale. Des éléments quantitatifs et qualitatifs doivent être examinés, et un faible volume ne signifie pas qu’une délégation serait sûre.

La continuité avec la RFC 8023 est nette. La magnitude aide à classer les recherches, à détecter une rupture de tendance ou à comparer des fenêtres. Elle ne révèle pas automatiquement l’identité, la cause, le préjudice ou la décision légitime.

L’interruption contrôlée fournit un autre exemple de périmètre. Le dispositif historique utilisait 127.0.53.53 pour rendre une dépendance cachée visible dans les journaux. En mars 2026, l’ICANN a décidé de ne pas employer un équivalent IPv6 dans ce cycle, dans l’attente de travaux de normalisation supplémentaires. L’absence de ce signal sur IPv6 est une limite du mécanisme, pas la preuve d’une absence de collision.

La prévention possède également son contrat. La RFC 2606 réserve notamment .test, .example, .invalid et .localhost. La RFC 6761 organise le traitement des noms à usage spécial. Leur protection dépend toutefois du code en fonctionnement. Un suffixe non attribué, choisi sans réservation, peut acquérir demain une signification globale.

La contribution documentée d’Allison Mankin doit rester aussi précise. La page publique du PEARG à l’IETF la présente comme présidente et fournit la photographie de référence utilisée pour le portrait éditorial. La RFC 8023 prouve sa qualité de coautrice du rapport. Elle ne prouve ni invention solitaire ni contrôle d’une politique de délégation.

Son apport prend alors la forme d’une discipline : un chiffre exact ne doit jamais recevoir, par commodité, des attributs que la collecte ne pouvait observer.

Le reçu utile à une décision

Un reçu de collision peut tenir sur une page s’il conserve huit éléments : l’observation bornée, le périmètre de collecte, l’hypothèse causale, les explications concurrentes, la corroboration, le mécanisme d’impact, le responsable et une mesure réversible dotée d’un test d’arrêt.

La primauté du code en fonctionnement formulée par Heng Lu place le test au bon endroit. Une ligne de registre, un score et une liste sont des preuves administratives. Le comportement du client, son chemin de résolution et l’effet réel d’une réponse modifiée restent les preuves opératoires les plus fortes.

La Minimum Initial Specification fixe le seuil commun sans imposer chaque choix local. Les opérateurs de racine attestent ce qu’ils ont observé. Les analystes exposent leurs incertitudes. Les entreprises testent les dépendances qu’elles contrôlent. L’autorité compétente exige une preuve proportionnée à l’impact.

L’échantillon gagne ainsi en valeur : il cesse de prétendre tout savoir et devient le point de départ vérifiable de la prochaine enquête.

Sources