Domaine principal
DNS
Au sein de la facette Domaine principal, l'analyse DNS regroupe les articles par domaine principal afin que les lecteurs puissent suivre un périmètre précis de l'infrastructure Internet, de la gouvernance, des marchés de connectivité ou du capital numérique. Cette page rassemble les articles associés, les preuves publiques, les institutions, les entreprises, les personnes, l'exposition régionale, les dépendances opérationnelles et le contexte de marché qui pourraient sinon être répartis entre différentes pages de catégories. Elle explique le domaine, la classe d'acteurs probable, le contexte de marché ou de gouvernance, ainsi que les sources que les lecteurs devraient utiliser pour comparer les signaux. Opérateurs, analystes et lecteurs de gouvernance peuvent voir comment un même domaine se manifeste à travers les événements, les profils, les évolutions de marché, les preuves issues de sources publiques, les dépendances régionales et les décisions d'infrastructure à plus long cycle au fil du temps.
Dirigeants
Dean Pemberton voulait faire d'un bloc IPv4 pollué une adresse DNS. APNIC a dit oui, puis non.
Le préfixe 1.2.3.0/24 était en quarantaine: trop de trafic non sollicité pour une distribution ordinaire. Pemberton voulait le recycler en adresse de résolveur DNS anycast à portée locale. Accord jeudi dans le Policy SIG, absence de consensus vendredi chez les membres.
Universitaires
Giovane Moura veut des données DNS comparables ; l’historique IPv6 de .nl est perdu
SIDN publie les mesures DNS de .nl selon un format commun aux données RSSAC-002. Son dépôt signale aussi un jour absent et des comptages IPv6 anciens impossibles à recalculer.
IETF
Avec Joe Abley, DNSSEC gagne 1 ms au milieu et en perd 1 405 à p99
Au centre du test post-quantique de Cloudflare, presque rien ne bouge. Dans le centile le plus lent, le chemin signé par deux algorithmes enregistre 1 405 ms de plus que le témoin classique. Le graphique des résolveurs validateurs affiche aussi 6,0 % de « net breakage ». Le vrai…
ICANN
Chez Carlos Gañán, l’abus DNS apparaît plus souvent, puis les campagnes rétrécissent de 38 %
Sur 1 106 gTLD, les espaces de catégorie 1 affichaient une probabilité mensuelle d’abus supérieure de 3,1 points, tandis que l’ampleur attendue des campagnes était inférieure de 38 % une fois l’abus apparu. Le modèle combiné estimait 37 % de domaines malveillants enregistrés en…
Universitaires
Ginevra Fabrizio : 11 octets gagnés, des réponses NXDOMAIN toujours trop grandes
À RIPE 93, la chercheuse de l’Université de Twente a rejoué une journée de requêtes `.nl` contre deux formats Falcon-512. La signature non rembourrée avait une médiane de 655 octets, contre 666; chaque réponse NXDOMAIN testée dépassait encore les deux seuils de taille étudiés.
IETF
ML-DSA-44 a son numéro; Joe Abley s’est heurté au guichet EPP
L’IANA a inscrit l’algorithme DNSSEC 18. À RIPE 93, Joe Abley a montré l’étape que ce numéro ne règle pas: faire accepter la DS par le registre qui contrôle la zone parente.
Universitaires
Martine Sophie Lenders a repéré l’indice laissé par le DNS chiffré
Son étude sur l’IoT contraint ne lit pas la requête: elle mesure comment la forme des paquets peut encore révéler le trafic DNS, puis ce que changent le transfert par blocs et la compression d’en-têtes.
Entreprises institutionnelles mondiales
Cinq correctifs nommés, un mot vague : lire la CVE-2025-40778
Un rapport daté sur une faille d'empoisonnement du cache dans BIND 9 énumère précisément les versions qui portent le correctif et abandonne l'ensemble affecté au mot « various ». Cette asymétrie décide de ce que le document peut prouver à celui qui valide la mise à jour — et de…
Dossier
Dyn a continué de répondre. Aucun texte n'a imposé de devoir à la résolution.
Un prestataire de nommage partagé a absorbé un trafic de robots en octobre 2016, et le dossier public en a gardé l'image d'une panne. Les textes qui ont suivi racontent autre chose: un avertissement fédéral sur les appareils qui ont lancé ce trafic, puis une loi sur le matériel…
Dirigeants
Ray Bellis : là où le texte publié s'arrête et où le réseau commence
Un sous-série documentaire d'un seul RFC d'un côté, une table de registre qui distribue des points de code de l'autre. Entre les deux, la même signature d'ingénieur — et une frontière d'autorité qu'on confond presque toujours.
ICANN
Le refus du .org : un droit d’approbation sans critère publié
En novembre 2019, l’Internet Society a conclu un accord pour céder Public Interest Registry, l’exploitant du domaine de premier niveau .org, à la société de capital-investissement Ethos Capital. Le 30 avril 2020, le conseil d’administration de l’ICANN a refusé son consentement au…
IETF
Un numéro d’algorithme ne crée pas une chaîne de confiance
RFC 9563 donne à la signature SM2 et au condensat SM3 des identifiants DNSSEC stables. Ce progrès rend les formats désignables; il ne vaut ni consensus de l’IETF, ni évaluation cryptographique, ni preuve de prise en charge par les validateurs.
IETF
Le serveur de secours a répondu. La clé en cache ne convenait pas : RFC 8901
Un second fournisseur DNS peut continuer à répondre après la panne du premier sans pour autant livrer une réponse acceptable aux résolveurs validateurs. RFC 8901 montre que la redondance DNSSEC est un contrat de synchronisation entre signataires, et non un simple nombre de…
Histoire d'Internet
Gihan Dias, quand l’Internet sri-lankais a appris deux écritures
Un pays peut être relié au réseau mondial tout en restant mal nommé par celui-ci. Le parcours de Gihan Dias montre comment le Sri Lanka a dû prolonger la construction de ses liaisons par un autre chantier: faire une place au cingalais et au tamoul dans la racine du DNS.
Dossier
Quand un correctif DNS ne suffit pas : la chaîne de réparation après les vulnérabilités BIND
Les vulnérabilités qui frappent un résolveur DNS ne se mesurent pas seulement au nombre de versions corrigées. Elles se mesurent à la capacité d’une organisation à repérer son exposition, déployer la correction et démontrer que le service résiste encore au mécanisme qui l’a…
IETF
James Gould et le signal de masquage qui ne prouve pas la règle
Un logiciel compare deux réponses RDAP et découvre qu’un numéro de téléphone a disparu. La tentation est immédiate: le champ aurait été supprimé pour des raisons juridiques. Mais la différence ne dit encore ni si la donnée existait, ni qui pouvait la voir, ni quelle règle a été…
Dossier
Le coût discret d’une exception DNS
Accorder à un résolveur local un périmètre stable évite de rouvrir un dossier à chaque nouveau service interne. Encore faut-il savoir ce que cette commodité délègue et ce qu’elle révèle. Le RFC 9704 permet de rendre l’autorisation vérifiable sans publier tout l’annuaire privé.
IETF
Suzanne Woolf et l’étiquette de serveur qui n’est pas une identité machine
Lorsqu’un serveur DNS renvoie un identifiant avec sa réponse, la tentation est forte d’y lire le nom certain d’une machine. L’anycast et les répartiteurs de charge rendent cette lecture dangereuse. Les exigences formulées par Suzanne Woolf dans le RFC 4892 conduisent à une…
IETF
Sara Dickinson et la promesse du résolveur que le chiffrement ne peut pas prouver
Le cadenas affiché à côté d’un résolveur DNS dit une chose juste: entre le client et un service identifié, la conversation est protégée. L’erreur commence lorsqu’on lui demande de témoigner sur la suite. Le RFC 8932, cosigné par Sara Dickinson, accompagne la requête au-delà du…
ICANN
Allison Mankin et l’échantillon de collision de noms qui ne prouvait pas sa cause
Un nom observé mille fois à la racine du DNS paraît raconter une histoire complète. Il ne livre pourtant ni l’application qui l’a formé, ni l’organisation responsable, ni la population exposée. Le rapport RFC 8023 cosigné par Allison Mankin apprend à ne pas confondre cette trace…