Mon blog

Les publications expliquant que l'Internet est foutu, que tout était mieux avant, abondent. Dans un article de la revue « Internet Histories », Kieran Hegarty se demande quand cette tendance est apparue et quelles sont ses caractéristiques.

Dans on article « When did the internet become this awful? », l'auteur appelle ces publications des IDN, les « Internet Decline Narratives ». Ces IDN sont très favorisés par les médias traditionnels, qui n'ont jamais pardonné à l'Internet d'avoir écorné leur monopole de la parole, et aussi par les politiciens qui aiment bien présenter l'Internet comme essentiellement négatif, ce qui leur permet de promouvoir ensuite contrôle et interdiction.

Ces IDN ne sont pas, en général, une critique argumentée du numérique. La critique est tournée vers le futur, vers ce qu'il faudrait changer. Au contraire, les IDN parlent du passé, un passé en général mythifié. Ils fixent de manière assez arbitraire une date à partir de laquelle les choses n'ont fait qu'aller mal (le septembre éternel ? Le Web ? L'IA générative ?).

Kieran Hegarty n'en parle pas beaucoup mais je note que ce discours « IDN », qui suppose qu'il y a eu un Internet parfait à une époque, rencontre souvent un discours réactionnaire qui estime que l'Internet, voire le numérique, a toujours été mauvais. Les IDN s'inscrivent dans la longue histoire des paniques morales qui avaient accompagné tous les nouveaux outils de communication à leurs débuts.

Et ces IDN ont des faiblesses : d'abord, ils invisibilisent complètement les utilisateurices, les réduisant au statut de victimes passives. Alors que ces utilisateurices agissent, choisissent, et ne suivent pas aveuglément (pour le cas des enfants, cf. par exemple les livres d'Anne Cordier, plutôt que les textes réactionnaires qui traitent ouvertement les utilisateurices de crétins). Oublier ces humain·es tend à écarter toute réflexion sur comment on pourrait améliorer les choses. D'accord, les utilisateurices manquent de culture numérique, et peuvent être trompés, et le sont souvent. Mais cela ne les réduit pas à de simples poupées qui feraient exactement ce que les GAFA prévoient pour eux.

Ensuite, les IDN ignorent la variété des usages de l'Internet. Politiciens et journalistes qui parlent de l'« Internet » ne connaissent en général que deux ou trois réseaux sociaux capitalistes et basent tout leur discours sur ces services, qui sont loin d'être la totalité des usages du Web, sans même parler de l'Internet en général.

Enfin, ces IDN sont souvent occidentalo-centrés, faisant comme si les usages et les phénomènes constatés dans le pays de l'auteur de l'IDN était universel. L'Internet est divers, et ses utilisateurices aussi. La technostalgie est parfois une nostalgie d'un monde passé où l'accès à l'Internet était limité à une population très homogène…

Au sujet de cet occidentalo-centrisme, l'auteur de l'article cite Payal Arora, la référence classique des tenants d'un discours techno-optimiste, s'appuyant sur un point de vue « du Sud ». Mais je trouve qu'Arora, citée ici de manière acritique, a aussi ses limites, notamment en allant franchement du côté de l'optimisme béat ; or, ce n'est pas parce qu'un paysan indien a un smartphone et est connecté qu'il devient libre et enpouvoiré. Son vécu demeure très influencé par des organisations puissantes sur lesquelles il n'a pas complètement prise.

Je rajoute aux remarques d'Hegarty que les IDN présentent souvent l'Internet comme un acteur en soi, ayant ses propres objectifs et sa propre dynamique, ce qui conduit à oublier qu'il y a des humains derrière, qui sont à l'origine des décisions. Ce n'est pas « l'Internet » qui capture des données en masse, ce sont Meta, Alphabet et les autres. Et ces entreprises ne font pas cela en raison d'idées transhumanistes fumeuses (contrairement à ce que racontent les intellectuells français, qui aiment bien se mettre dans la posture de défenseurs de l'humanité), mais parce que ce sont des entreprises capitalistes, que leurs dirigeants pilotent en fonction du profit.

Tout cela ne doit pas conduire à ignorer les critiques, qui sont parfaitement légitimes, et en général justifiées, quand on dit du mal des GAFA. Mais il faut faire attention à ne pas les inscrire dans une démarche de déclin obligatoire et inévitable.

Cet article explique le concept de « DNS menteur », terme souvent entendu, par exemple dans le contexte de la censure de l'Internet.

Si vous lisez souvent ce blog, vous n'apprendrez rien de nouveau ici. Le but de cet article est juste d'avoir une référence stable pour expliquer ce terme de « DNS menteur », sinon pour un large public, du moins pour une population plus large que les seuls experts DNS.

Donc, pour commencer, tout petit rappel sur le DNS (Domain Name System) : le DNS permet de distribuer de l'information aux machines connectées à l'Internet. (Les humain·es normaux ne regardent en général pas cette information, qui est purement technique.) La clé d'accès à cette information est un nom de domaine comme www.bortzmeyer.org ou phy.cam.ac.uk. Le point important est que quasiment toute interaction sur l'Internet commence par une utilisation du DNS, que votre machine fait pour vous. Si le DNS est en panne, c'est quasiment comme si vous n'avez plus d'Internet. Et, ce qui nous intéresse ici, si le DNS vous ment sur les informations techniques récupérées, vous n'avez guère d'autre choix que de le croire. (Avis aux expert·es : oui, je simplifie. J'ai indiqué quelques ressources plus complètes à la fin de cet article.)

Votre machine (ordinateur, ordiphone, brosse à dents connectée) fait des requêtes DNS pour vous et elle les fait à un serveur nommé résolveur DNS. C'est une machine en général gérée par l'organisation qui vous fournit l'accès à l'Internet. Normalement, en l'absence de « DNS menteur », votre résolveur ne fabrique pas d'information, il se contente de vous transmettre ce qu'il a appris d'une autre famille de serveurs DNS, les serveurs faisant autorité. Ceux-ci sont gérés par diverses organisations, par exemple les serveurs faisant autorité pour cnrs.fr sont gérés par le CNRS, alors que ceux faisant autorité pour sephora.fr sont gérés par l'hébergeur Akamai.

Donc, normalement, lorsque vous voulez envoyer du courrier à QuelqUn@cnrs.fr, une machine va demander à un résolveur DNS quel est le serveur de messagerie du CNRS et cette réponse viendra des serveurs faisant autorité pour cnrs.fr. Mais ça, c'est le comportement normal. Or, puisque presque toute interaction sur l'Internet commence par un appel au DNS, un certain nombre de gens se sont dit qu'ils pouvaient utiliser ce qui était conçu comme un service technique en outil de contrôle. Après tout, qui contrôle le résolveur, contrôle la quasi-entièreté du vécu de l'utilisateurice.

Un « DNS menteur » ou, plus rigoureusement, un « résolveur DNS menteur » est donc un résolveur qui, au lieu de relayer sincèrement les réponses des serveurs faisant autorité, invente des réponses, en général, dans le but de bloquer l'accès à un service Internet.

Notez bien que les résolveurs DNS menteurs ne sont pas tous pareils. Ils diffèrent par :

• La raison du mensonge : cela peut être la censure étatique, la censure au profit des ayants-droit, le blocage des publicités, le blocage de l'accès à des services malveillants, etc,
• la nature de l'entité qui décide : le résolveur menteur a pu être configuré pour mentir par l'utilisateurice, par quelqu'un agissant sur demande de l'utilisateurice ou par un tiers (par exemple dans le cas de la censure).

Vous noterez donc que « résolveur DNS menteur » est une simple description factuelle, les motivations et les acteurs étant variés. Des exemples d'utilisation pour la censure sont communs en Europe. Au moment de l'écriture de cet article, le gouvernement français a annoncé son intention de pouvoir bloquer les réseaux sociaux sur simple demande de sa part, et, si cela se fait, ce sera sans doute via des résolveurs DNS menteurs. (D'autres pays dans le monde utilisent d'autres techniques de censure de l'Internet.) Si vous voulez par contre un exemple dans le domaine du blocage de ces insupportables (et dangereuses) publicités , le système Pi-hole est un résolveur configuré pour mentir sur les noms de domaine utilisés par les services de publicité.

On fait souvent remarquer que, comme technique de censure, le résolveur DNS menteur n'est pas efficace car il est toujours possible de changer de résolveur. C'est techniquement exact mais il y a deux limites :

• L'opération est souvent plus complexe qu'il ne parait, par exemple certains FAI, comme Orange, ne permettent pas cette opération sur leur box. OK, on peut toujours y arriver mais tout le monde n'a pas forcément envie de se lancer dans ce genre de manipulations. (Si vous n'êtes pas technicien·ne et qu'un technicien prétentieux vous affirme que c'est trivial à faire, ne le croyez pas.)
• Et, surtout, il n'est pas normal que l'accès à l'information soit limité aux citoyen·nes qui ont la connaissance de la technique.

(Oui, je sais, on peut aussi utiliser un VPN.)

Le reste de cet article est consacré à un certain nombre de détails, en général de nature technique. D'abord, que se passe-t-il précisément quand un résolveur vous ment. Essayons avec le domaine tarjetarojatvlive.net. Ironiquement, le site Web ne marche plus (il semble rediriger vers des choses assez louches, ne l'essayez pas) mais, à une époque, une décision de justice au profit des ayants-droit exigeait sa censure. Avec les résolveurs de Free :

% dig @212.27.40.240 tarjetarojatvlive.net
…
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35658
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
;; QUESTION SECTION:
;tarjetarojatvlive.net.	IN A

;; ANSWER SECTION:
tarjetarojatvlive.net.	600 IN A 127.0.0.1

;; Query time: 5 msec
;; SERVER: 212.27.40.240#53(212.27.40.240) (UDP)
;; WHEN: Wed Oct 28 16:26:09 CET 2026
;; MSG SIZE  rcvd: 66

  

La réponse est clairement mensongère, l'adresse 127.0.0.1 étant l'adresse locale de la machine. (Les vraies adresses sont 172.104.149.86 et quelques autres.)

Ensuite, comment savoir si le résolveur que vous utilisez ment ? Une solution possible est évidemment de lire sa documentation mais, par exemple, en France, je ne connais aucun FAI qui documente les censures pratiquées. Il existe une solution technique pour que le résolveur indique qu'il a menti, les EDE (Extended DNS Error), normalisées dans le RFC 8914 mais, là encore, je ne connais pas de FAI français qui les utilise (comme vous le voyez dans la réponse de Free ci-dessus). Par contre, Google Public DNS le fait. Regardons avec dig :

% dig @8.8.8.8 tarjetarojatvlive.net
…
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 65388
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
; EDE: 16 (Censored): (The requested domain is subject to a judicial injunction or other governmental blocking order for FR (ISO country code). To learn more about this specific removal, please visit https://lumendatabase.org/notices/41939614.)
;; QUESTION SECTION:
;tarjetarojatvlive.net.	IN A

;; Query time: 6 msec
;; SERVER: 8.8.8.8#53(8.8.8.8) (UDP)
;; WHEN: Wed Oct 28 16:22:46 CET 2026
;; MSG SIZE  rcvd: 276

  

Il ne s'agit pas réellement d'un résolveur DNS menteur car Google a été franc : le domaine est censuré (code EDE 16) et Google renvoie même à la page Lumen décrivant ce cas. Mais le résultat va être le même pour l'utilisateurice, simplement plus clair. D'ailleurs, je ne sais pas pourquoi Free, dans l'exemple plus haut, renvoie une adresse bidon (le 127.0.0.1) au lieu d'un code REFUSED (comme Google) ou à la rigueur NXDOMAIN (indiquant que le domaine n'existe pas). Certains résolveurs DNS menteurs renvoient une adresse IP qui est celle d'un serveur Web contenant des explications mais c'est la pire solution de toutes, par exemple pour la vie privée.

La censure dépend évidemment du pays et, pour étudier la censure dans d'autres pays que le vôtre, vous pouvez utiliser, par exemple, les sondes RIPE Atlas (attention toutefois aux questions éthiques).

J'ai dit qu'on pouvait toujours (plus ou moins facilement) changer de résolveur. Je ne vais pas donner de liste de résolveurs, car, dès qu'ils sont largement utilisés, ils deviennent des cibles pour la censure. Il faut au contraire, dans ce cas comme dans beaucoup, plein de résolveurs un peu partout. (Et les résolveurs publics des GAFA sont évidemment à éviter.)

Et quelques lectures supplémentaires :

• Sur ce blog, le premier article que j'avais fait sur le sujet en 2009, un article plus détaillé sur le cas de la censure administrative française (ce n'est hélas pas un sujet nouveau), un autre exemple français, cette fois sur demande des ayants-droit, un article sur le fait qu'un résolveur qui refuse de mentir n'a parfois d'autre choix que d'arrêter de servir un pays, un exposé sur la difficulté du choix de la bonne solution de résolveur et un article sur la possibilité d'avoir son propre résolveur, qu'on contrôle.
• L'IETF a produit le RFC 7754 pour discuter du problème du blocage et du filtrage sur l'Internet (voir aussi le RFC 9707). Puisqu'on parle de l'IETF, notons que cette organisation a renoncé à normaliser le système RPZ qui sert à configurer certains résolveurs DNS menteurs.
• La question des résolveurs DNS menteurs est ancienne et le Conseil Scientifique de l'Afnic avait fait une excellente étude sur la question, en 2013.
• L'article de Wikipédia sur le sujet est médiocre et ancien. Si vous avez le courage de l'améliorer, vous pouvez copier-coller du contenu de cet article, les licences sont compatibles.

Vous avez sans doute déjà lu des articles sur la faille de l'AC eMudhra (sinon, vous avez des liens à la fin). Une des conséquences de cette faille est que tout le monde peut générer des vrais/faux certificats. Exemple.

La faille (depuis éclipsée par deux grosses failles PHP) venait d'un générateur de nombres aléatoire trop faibles. Un certificat est une clé cryptographique publique signée par une AC. La clé privée correspondant à cette clé publique doit être choisie de manière à être imprévisible pour l'attaquant. (On dit souvent qu'elle doit être choisie aléatoirement ce qui, en pratique, est juste un peu plus fort que de dire « imprévisible ».) Mais un générateur imprévisible est difficile à faire sur une machine déterministe comme un ordinateur. Et les logiciels ont des bogues. Une bogue frappait apparemment l'AC eMudhra : les clés générées ne faisaient qu'un octet (le reste étant toujours nul), ce qui ne faisait que 256 clés possibles, rendant triviale une énumération de toutes les clés possibles. L'une d'elles était juste le chiffre 4, que vous trouverez souvent dans les articles sur cette faille.

Le fonctionnement du système X.509 étant ce qu'il est, si on peut générer les clés d'une AC qui est largement présente dans les magasins d'AC de plusieurs systèmes d'exploitation / logiciels / langages, on peut se faire passer pour n'importe qui.

Démonstration avec le service emudhra.insecureoldshit.com:443. Il n'a pas de lien avec l'AC eMudhra mais, comme n'importe qui peut générer les clés « privées » d'eMudhra, il peut se faire passer pour elle. Ne cherchez pas forcément à vous connecter en HTTPS, c'est déjà intéressant avec juste du TLS nu. Essayons avec GnuTLS :

% gnutls-cli  emudhra.insecureoldshit.com:443     
Processed 152 CA certificate(s).
Resolving 'emudhra.insecureoldshit.com:443'...
Connecting to '2.29.115.248:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=192.134.4.66:6621,OU=You,O=Penguin Association,C=AQ', issuer `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', serial 0x00, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2026-10-22 12:35:47 UTC', expires `2026-10-22 12:36:17 UTC', pin-sha256="Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc="
	Public Key ID:
		sha1:779bc70e16304e65523397a5e1ccdc14cb673c39
		sha256:31ae0e5368eb9f27eb69532a7a1c3d02530544138675a4738808ef3c60f028a7
	Public Key PIN:
		pin-sha256:Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc=

- Certificate[1] info:
 - subject `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', issuer `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', serial 0x296926c227a3a1526392b19482a504, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2025-04-30 15:37:41 UTC', expires `2040-04-28 18:30:00 UTC', pin-sha256="Y+zv7kMdSVI7wRNsTnLQIGpHcIbK9gbNXPAlaGwQnPg="
- Certificate[2] info:
 - subject `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', issuer `CN=emSign ECC Root CA - G3,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN', serial 0x00961a3efb1359576ed04005b4684a5b, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2024-07-11 15:43:36 UTC', expires `2039-07-09 18:30:00 UTC', pin-sha256="xhnkeA7Y4KvtokrXMlZ95Dg6fqlBM49tGn0bSax5L+k="
- Status: The certificate is trusted. 
- Description: (TLS1.3-X.509)-(ECDHE-X25519)-(ECDSA-SECP256R1-SHA256)-(AES-128-GCM)
- Session ID: 8A:5F:E1:E3:6A:6D:00:01:5E:09:1E:78:5B:79:A8:BB:09:31:29:7F:9F:6B:C4:F3:6E:E0:72:F4:8E:45:7C:D2
- Options:
- Handshake was completed

Notons plusieurs choses :

• Le certificat du client (celui de numéro 0) a comme titulaire (« subject ») CN=192.134.4.66:6621,OU=You,O=Penguin Association,C=AQ. À la syntaxe du RFC 4514 (qui normalise la forme texte du modèle de données de X.500), cela veut dire que le nom est 192.134.4.66 (l'adresse IP du client du service, ici moi), l'organisation est la fictive « Penguin Association » et le pays est l'Antarctique. (Rappelez-vous que c'est un vrai/faux certificat, généré lors de ma connexion.)
• Le certificat final est signé par l'AC eMudhra (CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US)… En fait, c'est une vraie/fausse signature, faite en récupérant une des clés privées de eMudhra, grâce à l'énumération des clés possibles.
• Le certificat a été accepté sur cette machine (une Debian, où le certificat d'eMudhra était dans le magasin du système) : « The certificate is trusted. ».

Si maintenant je mets à jour mon système (les certificats des AC sont dans le paquetage Debian ca-certificates) :

% gnutls-cli  emudhra.insecureoldshit.com:443
Processed 150 CA certificate(s).
Resolving 'emudhra.insecureoldshit.com:443'...
Connecting to '2.29.115.248:443'...
- Certificate type: X.509
- Got a certificate list of 3 certificates.
- Certificate[0] info:
 - subject `CN=192.134.4.66:8801,OU=You,O=Penguin Association,C=AQ', issuer `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', serial 0x00, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2026-10-22 12:37:50 UTC', expires `2026-10-22 12:38:20 UTC', pin-sha256="Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc="
	Public Key ID:
		sha1:779bc70e16304e65523397a5e1ccdc14cb673c39
		sha256:31ae0e5368eb9f27eb69532a7a1c3d02530544138675a4738808ef3c60f028a7
	Public Key PIN:
		pin-sha256:Ma4OU2jrnyfraVMqehw9AlMFRBOGdaRziAjvPGDwKKc=

- Certificate[1] info:
 - subject `CN=EM OV TLS CA - G3C,O=eMudhra Inc,C=US', issuer `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', serial 0x296926c227a3a1526392b19482a504, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2025-04-30 15:37:41 UTC', expires `2040-04-28 18:30:00 UTC', pin-sha256="Y+zv7kMdSVI7wRNsTnLQIGpHcIbK9gbNXPAlaGwQnPg="
- Certificate[2] info:
 - subject `CN=emSign Root TLS CA - G3,O=eMudhra Technologies Limited,C=IN', issuer `CN=emSign ECC Root CA - G3,O=eMudhra Technologies Limited,OU=emSign PKI,C=IN', serial 0x00961a3efb1359576ed04005b4684a5b, EC/ECDSA key 384 bits, signed using ECDSA-SHA384, activated `2024-07-11 15:43:36 UTC', expires `2039-07-09 18:30:00 UTC', pin-sha256="xhnkeA7Y4KvtokrXMlZ95Dg6fqlBM49tGn0bSax5L+k="
- Status: The certificate is NOT trusted. The certificate issuer is unknown. 
*** PKI verification of server certificate failed...
*** Fatal error: Error in the certificate.

Vous noterez :

• Deux certificats de moins.
• Cette fois, le vrai/faux certificat est refusé, car le certificat d'eMudhra n'est plus dans le magasin.

Le certificat généré est disponible ici et voici son analyse par OpenSSL. Notez les dates de validité :

% openssl x509 -text -in ../files/emudhra-false-cert.pem
Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number: 0 (0x0)
        Signature Algorithm: ecdsa-with-SHA384
        Issuer: C=US, O=eMudhra Inc, CN=EM OV TLS CA - G3C
        Validity
            Not Before: Oct 22 13:21:32 2026 GMT
            Not After : Oct 22 13:22:02 2026 GMT
        Subject: C=AQ, O=Penguin Association, OU=You, CN=192.134.4.66:63823
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                pub:
                    04:95:61:11:86:61:1c:97:dd:0f:b5:e3:75:9b:07:
                    …
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Authority Key Identifier: 
                34:EA:EA:0C:EB:C9:0A:DA:F9:D0:C5:E2:ED:9B:78:C9:87:9E:1B:6C
            X509v3 Subject Alternative Name: 
                DNS:eXample.com, DNS:emudhra.insecureoldshit.com, DNS:*.emudhra.insecureoldshit.com, IP Address:192.134.4.66
    Signature Algorithm: ecdsa-with-SHA384
    Signature Value:
        30:66:02:31:00:bd:8a:fa:91:fc:cd:c0:af:9f:85:0b:13:16:
        …
-----BEGIN CERTIFICATE-----
MIICIzCCAaigAwIBAgIBADAKBggqhkjOPQQDAzBAMQswCQYDVQQGEwJVUzEUMBIG
…
  

Si vous tenez à faire du HTTP avec ce service, allez-y, il y a un gag.

D'autres ont utilisé cette possibilité pour permettre de générer de vrais/faux certificats, par exemple mitmproxy avec ce code.

Quelques lectures, si vous voulez apprendre ou approfondir :

• En français, un bon article de Next.
• Et en anglais, le bon article d'Ars Technica.
• L'article original (en anglais), qui n'indiquait pas encore la raison (la défaillance du générateur de nombres aléatoires).
• L'article technique de Scott Helme.
• Le rapport de bogue chez Mozilla (très détaillé, en anglais).
• Le communiqué officiel de l'AC.
• Le récit par l'équipe de développement du langage Go.

Plusieurs mathématiciens en ont profité pour faire remarquer que, contrairement à une simplification courante, 4 n'est pas « moins aléatoire » que, par exemple, 1012818637039180068205. Les deux ont la même probabilité d'être sélectionnés. Le problème vient du fait que les clés ne faisaient qu'un octet, pas spécialement du fait qu'elle avait la valeur 4.

Aujourd'hui, la racine du DNS, qui était signée avec la clé 20326 a changé, et utilise désormais la clé 38696.

Rien d'extraordinaire et aucun problème sérieux n'est attendu. Après tout, ce n'est pas le premier remplacement de la clé DNSSEC de la racine. Notez que, malgré la demande de bien des gens, la nouvelle clé est toujours du RSA (alors que les gros TLD utilisent souvent ECDSA). La nouvelle clé, 38696, a été largement publiée depuis longtemps donc est normalement connue de tous les résolveurs (en particulier grâce au RFC 5011 mais aussi à la mise à jour de paquetages comme dns-root-data sur Debian ou dnssec-anchors sur Arch).

La situation avant le remplacement peut être vue sur DNSviz, ou bien avec dig :

    
% dig . DNSKEY
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 7696
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			83906 IN DNSKEY	256 3 8 (
				AwEAAcorNxNc9t0ue1ZenPjVMRujlQ2YLBJ0pR/4XMjH
				by9vr03cRxFSKnWpxeg5PL384D9VeqdS1bjrGyTsHtoa
				gzI3NiXFd8sjHMOnZxu5pp/+UBIg7tasYgVMMdUiM1Yu
				/c+t30d1Qw/v6NYLNnOnywTu6HuUh7Y1sZRq/GZcrxLE
				NXHQoyKpOrOr8R3+qd6wK69IKB80ZBZtkX9rdEqKJk+y
				YXjEZzZ0zkAFthmNgCreAoU9PVlU66dyOsaLjf3wKUlU
				m9SNOKs+tK6LuSmRbK6+1T/tPaRaMBSEuv2G6vXfnJ1u
				yMbGvtpRn/YDcvTjrp6DzE6XyF44QdwJ3oKx4ek=
				) ; ZSK; alg = RSASHA256 ; key id = 8763
.			83906 IN DNSKEY	256 3 8 (
				AwEAAeCYD6Z7WWKVLeuWgowKP+3g+Gs1cnLKq7a3CaQx
				Qpv8bfuFVI0WnG33qaSH/Mw9IBgifrdzf4XY/DQLnyBJ
				9MfaOyAWuEaEmYJ+GQPiwVVfstGwSA1McfFJUttTgq2H
				uu74KARhtA8wPo/N3XcyYQtNhz+qCM5NBb3ecx/naw6s
				Yab9LxS6f2cU0q03++BP5Ks0Uef8WJCa/1izCYE+vMkw
				oltV+tENa3hpXiZ7jle/xdgaZrPi5ZGmyLVI34g1XVYr
				NlsCCTmNvFQIfzW5STFQFsQpizczyFn9r3LzSxxPCNwd
				lCG84bER0BmdwqbF6Tanv+FxMOavrahkj4wIy5k=
				) ; ZSK; alg = RSASHA256 ; key id = 57780
.			83906 IN DNSKEY	257 3 8 (
				AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
				iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
				7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
				LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
				efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
				pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
				A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
				9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
				) ; KSK; alg = RSASHA256 ; key id = 20326
.			83906 IN DNSKEY	257 3 8 (
				AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC
				6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeH
				spaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vr
				hbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAx
				m9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7
				CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+
				u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxP
				vYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=
				) ; KSK; alg = RSASHA256 ; key id = 38696
.			83906 IN RRSIG DNSKEY 8 0 172800 (
				20261022000000 20261001000000 20326 .
				ARGOmBDyLkr5oQdR5OaIeoeBti1KWEX/LY/jZlRRXwF0
				f0eRZaljFpyVKFuZMzpafSYVs7eLOYjVyWJ3iENn4AEh
				vX9iaKmWu3XpSSV0D6bhv5D6bk4GVPJ7NGTnA2lr4fC9
				lq9UD1kK1Q3jYJsxZSoQgjExDBfzwQUw1eYLLPPi7TQf
				+zA1wakHy2mkWnX1+bKDyrQ/p5ra4fgo/Pu7F47FXqRZ
				EJ+K9o/TwA+nJn3RMS6dPaS46ERBSWHIeJAzQvNQELI4
				pAbdVp3d3N33R2C5MxX6kUzNku8CtyXGYukSi9LK9GT3
				nrH9O97tDADq01z78aPnjl+6hLTgMkiupw== )

;; Query time: 2 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (TCP)
;; WHEN: Sat Oct 10 13:00:22 CEST 2026
;; MSG SIZE  rcvd: 1414

  

Les deux clés (KSK, Key Signing Zone) sont publiées (ainsi que les clés de signature de la zone, ZSK Zone Signing Zone, 8763, et la 57780 qui va bientôt être retirée) mais seule 20326 signe les clés.

Depuis le remplacement, DNSviz nous montre la nouvelle situation. Et avec dig, nous avons (on demande directement à un serveur faisant autorité car les résolveurs ont presque tous encore l'ancienne signature en mémoire) :

    
 % dig @k.root-servers.net . DNSKEY

; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> @k.root-servers.net . DNSKEY
; (2 servers found)
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35242
;; flags: qr aa rd; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			172800 IN DNSKEY 256 3 8 (
				AwEAAcorNxNc9t0ue1ZenPjVMRujlQ2YLBJ0pR/4XMjH
				by9vr03cRxFSKnWpxeg5PL384D9VeqdS1bjrGyTsHtoa
				gzI3NiXFd8sjHMOnZxu5pp/+UBIg7tasYgVMMdUiM1Yu
				/c+t30d1Qw/v6NYLNnOnywTu6HuUh7Y1sZRq/GZcrxLE
				NXHQoyKpOrOr8R3+qd6wK69IKB80ZBZtkX9rdEqKJk+y
				YXjEZzZ0zkAFthmNgCreAoU9PVlU66dyOsaLjf3wKUlU
				m9SNOKs+tK6LuSmRbK6+1T/tPaRaMBSEuv2G6vXfnJ1u
				yMbGvtpRn/YDcvTjrp6DzE6XyF44QdwJ3oKx4ek=
				) ; ZSK; alg = RSASHA256 ; key id = 8763
.			172800 IN DNSKEY 257 3 8 (
				AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
				iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
				7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
				LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
				efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
				pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
				A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
				9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
				) ; KSK; alg = RSASHA256 ; key id = 20326
.			172800 IN DNSKEY 257 3 8 (
				AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC
				6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeH
				spaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vr
				hbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAx
				m9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7
				CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+
				u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxP
				vYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=
				) ; KSK; alg = RSASHA256 ; key id = 38696
.			172800 IN RRSIG	DNSKEY 8 0 172800 (
				20261101000000 20261011000000 38696 .
				llXxlp+gWc4h/F9G8UPj3VXhNDQoZrco3Piivk7YMKS7
				pi8B+CBQHHPO/QNw+VfpNq7CtBDA6gxucyia1ZZx8yM0
				oLve7qJKgPuRVNnw5AOegtdxy+NKSy8rT6XNtCdM2gL9
				EmqKux+/JNATbZG2efGkVpHuirkq0Vs1bvYglVl6fvHb
				qoHpfjbnHVheuKpq+HvdsZOphoEJu74Y4lpYNBNTJijG
				gajnJ64AUMPbMfu76uLi68CcWKDGWhzCNeSwnSjK7CA6
				aKte5StW61Nuz0Nv8mvzqMX0epPQ7lXJ9Yc/685081Bd
				zAYK3yMAfTOqL4EgluNZQAtAAh9bseJVyw== )

;; Query time: 25 msec
;; SERVER: 2001:7fd::1#53(k.root-servers.net) (UDP)
;; WHEN: Sun Oct 11 16:03:26 CEST 2026
;; MSG SIZE  rcvd: 1139

  

Toujours les deux clés publiées, mais seule 38696 signe.

Vu la mémorisation des données par les résolveurs, tout va continuer à marcher comme avant. Voici la situation sur un résolveur quelconque, il reste 83 548 secondes avant l'expiration :

% dig . DNSKEY
;; Truncated, retrying in TCP mode.

; <<>> DiG 9.18.39-0ubuntu0.24.04.7-Ubuntu <<>> . DNSKEY
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30170
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
;; QUESTION SECTION:
;.			IN DNSKEY

;; ANSWER SECTION:
.			83548 IN DNSKEY	257 3 8 (
				AwEAAaz/tAm8yTn4Mfeh5eyI96WSVexTBAvkMgJzkKTO
				iW1vkIbzxeF3+/4RgWOq7HrxRixHlFlExOLAJr5emLvN
				7SWXgnLh4+B5xQlNVz8Og8kvArMtNROxVQuCaSnIDdD5
				LKyWbRd2n9WGe2R8PzgCmr3EgVLrjyBxWezF0jLHwVN8
				efS3rCj/EWgvIWgb9tarpVUDK/b58Da+sqqls3eNbuv7
				pr+eoZG+SrDK6nWeL3c6H5Apxz7LjVc1uTIdsIXxuOLY
				A4/ilBmSVIzuDWfdRUfhHdY6+cn8HFRm+2hM8AnXGXws
				9555KrUB5qihylGa8subX2Nn6UwNR1AkUTV74bU=
				) ; KSK; alg = RSASHA256 ; key id = 20326
.			83548 IN DNSKEY	257 3 8 (
				AwEAAa96jeuknZlaeSrvyAJj6ZHv28hhOKkx3rLGXVaC
				6rXTsDc449/cidltpkyGwCJNnOAlFNKF2jBosZBU5eeH
				spaQWOmOElZsjICMQMC3aeHbGiShvZsx4wMYSjH8e7Vr
				hbu6irwCzVBApESjbUdpWWmEnhathWu1jo+siFUiRAAx
				m9qyJNg/wOZqqzL/dL/q8PkcRU5oUKEpUge71M3ej2/7
				CPqpdVwuMoTvoB+ZOT4YeGyxMvHmbrxlFzGOHOijtzN+
				u1TQNatX2XBuzZNQ1K+s2CXkPIZo7s6JgZyvaBevYtxP
				vYLw4z9mR7K2vaF18UYH9Z9GNUUeayffKC73PYc=
				) ; KSK; alg = RSASHA256 ; key id = 38696
.			83548 IN DNSKEY	256 3 8 (
				AwEAAcorNxNc9t0ue1ZenPjVMRujlQ2YLBJ0pR/4XMjH
				by9vr03cRxFSKnWpxeg5PL384D9VeqdS1bjrGyTsHtoa
				gzI3NiXFd8sjHMOnZxu5pp/+UBIg7tasYgVMMdUiM1Yu
				/c+t30d1Qw/v6NYLNnOnywTu6HuUh7Y1sZRq/GZcrxLE
				NXHQoyKpOrOr8R3+qd6wK69IKB80ZBZtkX9rdEqKJk+y
				YXjEZzZ0zkAFthmNgCreAoU9PVlU66dyOsaLjf3wKUlU
				m9SNOKs+tK6LuSmRbK6+1T/tPaRaMBSEuv2G6vXfnJ1u
				yMbGvtpRn/YDcvTjrp6DzE6XyF44QdwJ3oKx4ek=
				) ; ZSK; alg = RSASHA256 ; key id = 8763
.			83548 IN DNSKEY	256 3 8 (
				AwEAAeCYD6Z7WWKVLeuWgowKP+3g+Gs1cnLKq7a3CaQx
				Qpv8bfuFVI0WnG33qaSH/Mw9IBgifrdzf4XY/DQLnyBJ
				9MfaOyAWuEaEmYJ+GQPiwVVfstGwSA1McfFJUttTgq2H
				uu74KARhtA8wPo/N3XcyYQtNhz+qCM5NBb3ecx/naw6s
				Yab9LxS6f2cU0q03++BP5Ks0Uef8WJCa/1izCYE+vMkw
				oltV+tENa3hpXiZ7jle/xdgaZrPi5ZGmyLVI34g1XVYr
				NlsCCTmNvFQIfzW5STFQFsQpizczyFn9r3LzSxxPCNwd
				lCG84bER0BmdwqbF6Tanv+FxMOavrahkj4wIy5k=
				) ; ZSK; alg = RSASHA256 ; key id = 57780
.			83548 IN RRSIG DNSKEY 8 0 172800 (
				20261022000000 20261001000000 20326 .
				ARGOmBDyLkr5oQdR5OaIeoeBti1KWEX/LY/jZlRRXwF0
				f0eRZaljFpyVKFuZMzpafSYVs7eLOYjVyWJ3iENn4AEh
				vX9iaKmWu3XpSSV0D6bhv5D6bk4GVPJ7NGTnA2lr4fC9
				lq9UD1kK1Q3jYJsxZSoQgjExDBfzwQUw1eYLLPPi7TQf
				+zA1wakHy2mkWnX1+bKDyrQ/p5ra4fgo/Pu7F47FXqRZ
				EJ+K9o/TwA+nJn3RMS6dPaS46ERBSWHIeJAzQvNQELI4
				pAbdVp3d3N33R2C5MxX6kUzNku8CtyXGYukSi9LK9GT3
				nrH9O97tDADq01z78aPnjl+6hLTgMkiupw== )

;; Query time: 2 msec
;; SERVER: 192.168.2.254#53(192.168.2.254) (TCP)
;; WHEN: Sun Oct 11 16:31:33 CEST 2026
;; MSG SIZE  rcvd: 1414

  

Au fur et à mesure que le TTL expire, les résolveurs vont récupérer la nouvelle signature des clés (et, normalement, tout se passera bien, les utilisateurs ne verront rien).

Sinon, si vous voulez une vue plus générale sur les remplacements de clés DNSSEC, je vous recommande l'article de Jan-Piet Mens (en anglais).

Hier, l'ICANN a publié la liste des candidatures pour obtenir un TLD lors du cycle d'enregistrements actuel. Quelques données.

Après un petit traitement du CSV par un script Python bâclé (mais bio) :

% python process.py
2783 applications (1614 if we exclude the replacement strings), by 480 applicants, for 1430 different strings
Longest string (17 characters) is superintelligence
27 IDNs, 13 french
 

2 783 candidatures, donc. L'ICANN annonce 1 615 car certaines candidatures sont des remplacements au cas où la candidature principale ne serait pas retenue (merci à Nicolas Pawlak pour l'explication). Il y a beaucoup de doublons (des candidatures multiples pour une même chaine de caractères, voyez le paragraphe plus loin) et il n'y a donc que 1 430 demandes différentes. (Vous pouvez récupérer la liste.)

Treize ont été déposés par des organisations françaises :

aiagent - THE BEST
airliquide - L'Air Liquide, société anonyme pour l'Étude et l'Exploitation des procédés Georges Claude
atos - ATOS GROUP SE
avocat - ORDRE DES AVOCATS COUR APPEL
bpce - BPCE
cnp - CNP ASSURANCES
cnpassurances - CNP ASSURANCES
conex - CONEX SAS
ledger - LEDGER 
mbda - MBDA
michelin - Compagnie générale des Etablissements Michelin
socialmedia - THE BEST
sodexo - SODEXO
  

Et les doublons ?

20 most demanded:
agent: 13 applications
brand: 12 applications
bit: 11 applications
hub: 11 applications
zen: 11 applications
api: 10 applications
human: 10 applications
pop: 10 applications
robot: 10 applications
connect: 9 applications
find: 9 applications
gym: 9 applications
key: 9 applications
max: 9 applications
mind: 9 applications
pod: 9 applications
vibe: 9 applications
air: 8 applications
fix: 8 applications
form: 8 applications
gen: 8 applications
  

Notez le succès de l'agent…

27 demandes sont des IDN, tous en caractères chinois à part le .québec (avec l'accent). Les chinois sont (merci à Élise Gerriet pour les traductions, mais elle a dû travailler vite et les erreurs sont de moi) :

中文网 - Internet 
人工智能 - IA
名片 - Carte de visite 
品牌 - Marque 
商标 - Marque déposée
在线 - En ligne 
地址 - Adresse 
官网 - Site Internet officiel 
抖音 - Douyin, le Tiktok chinois 
数字人
智能体 - Agent (au sens de l'agentique de l'IA)
机器人 - Robot 
株式会社 - Du japonais (société par actions)
海信
海尔
海尔兄弟
瑞幸
瑞幸咖啡
番茄 - Tomate (?)
红果 - Aubépine (???)
网络 - Internet 
购物 - Shopping
酒店 - Hôtel ou bar (c'est différent à Taïwan ou en Chine)
钱包 - Portefeuille (pour les cryptomonnaies ?)
防伪
餐厅 - Restaurant

Et quelles organisations (attention, beaucoup sont des façades comme Charleston qui est en fait Google ou Identity Digital qui a créé une boite écran par candidature) demandent le plus de TLD (ce qui représente une importante dépense, vu les frais de dossier de 227 k$) ?

20 most demanding applicants:
Link Freedom Group Ltd: 316 applications
XYZ.COM LLC: 278 applications
Registry Services, LLC: 153 applications
Intercap Registry Inc.: 140 applications
Radix Technologies Inc SEZC: 92 applications
ShortDot (Ireland) Limited: 80 applications
Oinkadot Inc: 50 applications
Suffix Inc.: 48 applications
NextGEN TLDs GmbH: 44 applications
Charleston Road Registry Inc.: 39 applications
Aruba PEC S.P.A.: 39 applications
Toddler Logic, LLC: 38 applications
Pirin Tablet, LLC: 30 applications
Squarespace Registry LLC: 30 applications
Hair Apparent, LLC: 28 applications
XRegistry Incorporated: 28 applications
Knock Knock WHOIS There, LLC: 27 applications
101130013 Saskatchewan Ltd.: 26 applications
Oyster Dream, LLC: 26 applications
ECHO Domain Co L.L.C.: 25 applications
Endpoint Domains, Inc.: 24 applications
  

Du 22 au 27 septembre, un inconnu a piraté trois registres de noms de domaine. L'occasion de rappeler, face à plusieurs commentaires erronés, que si un attaquant prend le contrôle du nom de domaine, il peut tout faire (et, non, TLS ne protège pas).

Les faits, d'abord, tels que résumés dans cet article d'Ars Technica. Un attaquant a piraté, par le biais d'une faille de sécurité dans le logiciel CoCCA, trois ccTLD, .gh, .sl et .as. Ayant apparemment le contrôle complet de la base de données, il pouvait modifier les noms qu'il voulait, notamment google.TLD. (Voir le communiqué de Google.)

On peut confirmer indépendamment cet article avec DNSDB ou un autre service présentant l'historique du DNS. Par exemple pour la Sierra Leone :

% isc-dnsdb-query rrset google.sl/NS    
;;  bailiwick: sl.
;;      count: 105533
;; first seen: 2010-07-09 12:58:00 -0000
;;  last seen: 2026-10-07 03:41:01 -0000
google.sl. IN NS ns1.google.com.
google.sl. IN NS ns2.google.com.
google.sl. IN NS ns3.google.com.
google.sl. IN NS ns4.google.com.

;;  bailiwick: sl.
;;      count: 12
;; first seen: 2026-09-25 04:37:33 -0000
;;  last seen: 2026-09-25 04:47:46 -0000
google.sl. IN NS betty.ns.cloudflare.com.
google.sl. IN NS edward.ns.cloudflare.com.
  

Notez le bailiwick montrant que c'est bien le TLD qui était piraté. On voit dans le premier groupe, les serveurs de noms normaux, chez Google, le deuxième groupe étant le piratage. Il a été très vite détecté et corrigé, les pirates devraient savoir que quand on pirate un registre, il ne faut surtout pas toucher à google.TLD, c'est le plus surveillé et Google est très réactif.

Et aux Samoa ?

% isc-dnsdb-query rrset google.as/NS
;;  bailiwick: as.
;;      count: 10000346
;; first seen: 2010-06-24 04:28:33 -0000
;;  last seen: 2026-10-08 02:20:05 -0000
google.as. IN NS ns1.google.com.
google.as. IN NS ns2.google.com.
google.as. IN NS ns3.google.com.
google.as. IN NS ns4.google.com.

;;  bailiwick: as.
;;      count: 549
;; first seen: 2026-09-27 03:18:09 -0000
;;  last seen: 2026-09-27 05:30:26 -0000
google.as. IN NS duke.ns.cloudflare.com.
google.as. IN NS mckinley.ns.cloudflare.com.

Même chose, deux jours plus tard. (Et google.com.gh, puisque ce TLD enregistre au troisième niveau de l'arbre des noms de domaine, le 22 septembre. Merci à Rémy Grünblatt du rappel.)

Certaines personnes, par exemple dans les commentaires à l'article d'Ars Technica n'ont pas compris les conséquences du piratage et se sont demandés pourquoi c'est grave puisque TLS aurait protégé de toute façon. (Notons qu'un commentaire confond registre de noms de domaine et AC… Il ne faut pas lire les commentaires si on ne veut pas devenir misanthrope.) TLS n'aurait pas protégé tout simplement parce que, quand on contrôle le DNS, on contrôle tout et on peut obtenir facilement et automatiquement un certificat (il y a bien longtemps que les certificats alloués « manuellement », avec examen par un humain, ne sont presque plus utilisés). C'est ce que dit l'article d'Ars Technica et on peut le vérifier avec les journaux Certificate Transparency (RFC 9162). Si on a la chance de tomber à un moment où https://crt.sh/ fonctionne (c'est rare), on peut trouver les certificats créés (je n'en vois pas pour google.com.gh) :

Cette difficulté de certains à comprendre l'ampleur des choses qu'on peut faire une fois qu'on a le contrôle d'un TLD est en partie liée au cliché souvent répété « Le DNS, c'est pour traduire des noms en adresses IP ». Ce n'est en fait qu'une partie de son rôle mais le DNS sert à bien d'autres choses. Par exemple, un commentaire a cité la possibilité, pour Google, de mettre un enregistrement CAA (RFC 8659), sans comprendre que cela n'aurait servi à rien pendant le détournement. (Modulo la mémorisation du CAA dans certains résolveurs.) Bref, la sécurité des TLD contre ce genre de piratage est cruciale.

Un autre bon article fait à partir du communiqué de Google est celui d'IT news. Notez que le journaliste a contacté les gérants des trois TLD concernés (et n'a évidemment eu aucune réponse). Depuis, ont été publiés le communiqué du .as et un article sur un site sierraléonais (le titre est ridiculement faux). Vous avez aussi le communiqué de la société CoCCA.

Du 30 septembre au 2 octobre, j'ai eu le plaisir de participer à la conférence Histories of Tracking à l'université du Luxembourg. Cette conférence était consacrée à la surveillance exercée sur les utilisateurices, notamment dans le contexte du numérique. Voici quelques notes sommaires.

La conférence n'était pas diffusée en ligne ni enregistrée (donc pas de surveillance possible 🤣). On y retrouvait des vieux souvenirs comme le champ de l'en-tête HTTP Do Not Track, jamais réellement respecté par les serveurs. Sebastian Gießmann a dit qu'aujourd'hui, c'était plutôt Do Always Track. (La technique de préservation de la vie privée recommandée aujourd'hui est le champ Sec-GPC, enregistré à l'IANA.)

Matthew L. Jones a commencé par une introduction sur l'histoire de la surveillance via les métadonnées. L'orateur a bien insisté sur le fait frappant que les lois sur la capture de données et la surveillance, même rejetées, finissent toujours par revenir sur la table au premier fait divers. Lutter contre ces lois est épuisant, c'est un jour de la marmotte perpétuel.

Cecilia Passanti a expliqué l'histoire de la biométrie en Afrique depuis les indépendances, lorsque des entreprises européennes comme Sinorg or Gallia profitaient de ces nouveaux marchés, sous prétexte, par exemple, de garantir l'absence de fraude aux élections, pour tester leurs produits, qu'elles allaient ensuite vendre dans le « Nord global ».

Rebecca Ciesielski a parlé entre autres de l'affirmation souvent entendue comme quoi les ordiphones écoutent en permanence et qu'on reçoit ensuite de la publicité en fonction de conversations qu'on a eu près d'un ordiphone allumé. Elle conclut que c'est techniquement possible (les applications doivent notifier qu'elles écoutent mais, si l'écran est éteint, cela ne se voit pas) mais pas prouvé, on n'a que des anecdotes (« je parlais de chaussures de sport avec ma compagne et j'ai eu tout à coup des publicités pour Nike »), et il est difficile de savoir si la régie publicitaire n'avait pas d'autre source (une utilisation d'un moteur de recherche juste avant ?).

Une partie particulièrement intéressante pour moi, car je ne connaissais pas le sujet, a été celle sur la surveillance des animaux. Christoph Borbach a décrit les systèmes de suivi de la faune sauvage, qui doivent être bien acceptés par ces « utilisateurs involontaires ». J'ai appris que les ratons laveurs sont particulièrement efficaces pour retirer leurs dispositifs de surveillance et que les pies coopèrent pour s'enlever ces exaspérants bagues et colliers. Et Vesna Schierbaum a fait un très bon exposé sur un sujet que je ne connaissais pas du tout, le « virtual fencing » ou, au lieu de mettre le bétail derrière des barrières physiques, on équipe les animaux d'un dispositif (connecté à l'Internet) qui les guide. C'est très peu utilisé en Europe mais courant en Argentine, en Nouvelle-Zélande, aux États-Unis, etc. Elle a cité deux entreprises, Monil et Halter. Le plus gros investisseur de la deuxième est Peter Thiel… Outre les questions sur le bien-être animal et sur la déshumanisation du travail des paysans, je note que ces dispositifs sont chers et enferment davantage les fermiers dans la dépendance technologique. Sans compter ce qui se passerait en cas de panne ou de piratage.

Moritz Feichtinger a présenté ses travaux sur les systèmes de surveillance militaires. (Et a rappelé qu'on pouvait déduire beaucoup de choses des métadonnées.) Saviez-vous que l'armée étatsunienne utilisait des drones de surveillance pendant la guerre du Vietnam ? Par contre, contrairement à ce qu'on voit aujourd'hui, en Ukraine, les vidéos n'étaient pas publiées. Un étudiant présent a demandé comment ils pouvaient piloter le drone à distance puisqu'il n'y avait pas encore d'Internet 😊.

La session de clôture a vu Azadeh Akbari présenter un triste bilan de la surveillance en Iran des années 1920 (sous le chah, donc) à aujourd'hui. Dans les prisons (aussi bien celles du chah que celles des mollahs), c'était souvent les prisonniers qui surveillaient, chaque groupe politique ou religieux observant en permanence les membres du groupe.

Ah, et il y a eu aussi l'intervention d'une, artiste, Clio Van Aerde, qui a notamment présenté sa curieuse performance de tour du Luxembourg en suivant strictement la frontière.

De mon côté, je présentais l'évolution, qui est loin d'être linéaire, de la réflexion sur la surveillance et la vie privée à l'IETF, depuis ses débuts. Vous pouvez accéder aux supports (et à leur source, en Typst).

Vous le savez, en ce moment, c'est la fête des fuites de données personnelles en France. Tout le monde (et son chat) a déjà été victime d'au moins une fuite. Au moins, grâce au RGPD, on est informé qu'il y a eu une fuite. Mais que s'est-il passé derrière ? En général, on ne le sait pas. Aucune enquête indépendante publiée et, souvent, rien du tout n'est publié, on doit se fier aux rumeurs propagées par des influenceurs en cybersécurité sur les réseaux sociaux, par des ministres menteurs et par des journalistes ignorants. Mais le piratage de la DGFIP, il est vrai particulièrement scandaleux, fait, lui, l'objet d'une publication assez détaillée, par l'ANSSI.

Je vous recommande fortement la lecture de ce rapport. Bien sûr, ce n'est pas une enquête indépendante (l'ANSSI, c'est l'État) mais c'est bien écrit (il y a beaucoup de sigles spécifiques à l'État mais un glossaire est présent), sérieux, modeste (l'ANSSI note bien ses propres faiblesses) et détaillé (attention, certaines parties ont été censurées par un gros pavé noir). Mais voici quelques points qui m'ont frappé (le principal étant le fait que ce rapport existe et ait été publié).

Le rapport contient un certain nombre de bons avis de sécurité. Mais beaucoup de gens l'ont interprété de manière binaire, s'indignant que le ministère n'ait pas mis en œuvre telle ou telle mesure. C'est oublier le principe de base de la sécurité (pas seulement informatique) : il n'y a pas de solution idéale, seulement des compromis. Par exemple, un EDR (mentionné par l'ANSSI) consomme des ressources informatiques importantes, a des faux positifs (j'en ai vu un protester contre du code binaire SuperH, considéré comme forcément suspect, alors que du code Sparc ou Alpha dans le même répertoire ne posait pas de problème), et peut avoir des bogues (c'était d'ailleurs le scénario du dernier exercice Remparts). Pire, ce sont souvent des logiciels privateurs. Bref, ne pas avoir d'EDR a des inconvénients, en avoir un a des inconvénients. On peut juste choisir son poison.

Le même raisonnement peut être appliqué aux autres conseils de l'ANSSI. Bien sûr, ils sont tous raisonnables mais tous ont un coût, pas seulement financier, mais aussi en gêne des employés pour leur travail. Les organisations qui déploient les mesures citées ont souvent été victimes d'une « auto-attaque par déni de service », les mesures de sécurité empêchant de travailler.

J'ai quand même trouvé que le cas cité par le rapport d'une soi-disant « authentification à deux facteurs » qui consistait en l'envoi par courrier du second facteur… alors que le courrier était traité sur la machine qui servait à se connecter, était en effet assez incroyable. Si les deux facteurs sont sur la même machine, ce ne sont pas réellement deux facteurs (le rapport insiste, à juste titre, sur ce point).

Le rapport détaille les techniques mises en œuvre mais pas l'arrière-plan organisationnel. Par exemple, au moins une partie des accès pirates ont été faits depuis le ministère de l'Éducation nationale, apparemment moins protégé, mais le rapport ne dit pas pourquoi ce ministère avait accès aux données des impôts. Même chose pour des accès par des entités privées extérieures (comme le géomètre-expert mentionné dans le rapport).

La sécurité ne dépend pas uniquement du budget (on peut avoir un budget très élevé et le dépenser essentiellement dans du théâtre sécuritaire, par exemple l'achat de dispositifs techniques très chers, opaques mais bénéficiant d'un bon marketing). Mais il ne faut pas se faire d'illusion, la sécurité aura un coût : si on déploie toutes les mesures proposées par le rapport, il faudra embaucher beaucoup de fonctionnaires (par exemple pour les investigations suite à une alarme). Les mêmes politiciens qui s'indignent « comment se fait-il qu'il n'y ait pas davantage de sécurité dans les ministères » seront peut-être les premiers à râler si on leur demande d'augmenter le budget de l'État.

Je recommande de bien lire le rapport jusqu'au bout, les annexes contiennent des détails précis, notamment chronologiques. Ils montrent que de nombreuses alarmes avaient été levées et traitées, mais que l'ampleur et le sérieux de l'attaque n'avaient pas été clairement notés (le fameux problème de « relier les points »).

GuiGui a répondu à certains points de cet article.

Le 16 septembre 2026 est sortie la version 18 d'Unicode. Une description officielle des principaux changements est disponible mais voici ceux qui m'ont intéressé particulièrement. (Il n'y a pas de changement radical.)

Pour explorer plus facilement la grande base Unicode, j'utilise un programme qui la convertit en SQL et permet ensuite de faire des analyses variées. Faisons quelques requêtes SQL :

ucd=> SELECT count(*) AS Total FROM Characters;
 total  
--------
 172873

Combien de caractères sont arrivés avec la version 18 ?

ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float;
...
 15.0    |  4489
 15.1    |   627
 16.0    |  5185
 17.0    |  4803
 18.0    | 13007

13 007 nouveaux caractères, c'est beaucoup par rapport aux précédentes versions, mais ce sont presque tous des sinogrammes du petit sceau. Autrement, quels sont ces nouveaux caractères ?

ucd=> SELECT To_U(codepoint) AS Code_point, name FROM Characters WHERE version='18.0' ORDER BY Codepoint;
 code_point |                                    name                                    
-----------+----------------------------------------------------------------------------
…
 U+20C3     | UAE DIRHAM SIGN
 U+20C4     | OMANI RIAL SIGN
 …
 U+A7E2     | LATIN CAPITAL LETTER R WITH LONG LEG
 …
 U+10EF3    | ARABIC SMALL HIGH NOON WITH FATHA
 …
 U+12477    | CUNEIFORM NUMERIC SIGN ASH TIMES ONE DISH TENU
 …
 U+18E17    | JURCHEN CHARACTER-18E17
 …
 U+1FA8B    | METEOR
 U+1FA8C    | ERASER
 U+1FA8D    | NET WITH HANDLE
 U+1FACC    | MONARCH BUTTERFLY
 U+1FADD    | PICKLE
 …
 U+3D005    | SEAL CHARACTER-3D005
 …

On y voit quelques nouveaux caractères, ainsi que les trois nouvelles écritures de cette version d'Unicode, les anciens chiffres cunéiformes, le jurchen et le petit sceau. Et il y a aussi quelques changements de comportement, qui nécessiteront un peu de mise à jour des bibliothèques logicielles.

En plus futile, il y a l'habituelle arrivée d'emojis comme le cornichon (comme dans la chanson) et le météore. Le trognon de pomme n'a toujours pas été intégré (il avait déjà été retiré d'Unicode 17).

Si vous avez les bonnes polices de caractères, vous allez pouvoir voir quelques exemples (sinon, le lien mène vers Uniview). Voici par exemple, le rial omanais ⃄, une nouvelle lettre R utilisée pour le xhosa, ꟢, une marque utilisée pour l'arabe, un chiffre cunéiforme 𒑾, une lettre jurchen 𘹂, une lettre du petit sceau 𾥉, la gomme 🪌 et le monarque 🫌.

Et sinon, en bien plus détaillé qu'ici, vous pouvez aussi lire l'article d'Ysabeau.

Hier, j'ai cherché à faire un lien symbolique « immuable » sur Linux, plus exactement un lien que son ou sa propriétaire ne risquerait pas de supprimer par accident, tout en lui permettant de créer et détruire d'autres objets dans ce répertoire. Si vous connaissez Linux, vous allez probablement crier « chattr +i, chattr +i ! ». Mais, non, cela ne marche pas.

Essayons quand même, sur le compte d'un utilisateur nommé Bob. D'abord avec un fichier ordinaire :

$ echo "Contenu sans intérêt" > myfile

$ sudo chattr +i myfile

$ ls -l myfile 
-rw-rw-r-- 1 bob bob 23 Sep  9 15:12 myfile
$ lsattr myfile 
----i---------e------- myfile

$ rm myfile 
rm: cannot remove 'myfile': Operation not permitted
  

Parfait, tout marche (une alternative à sudo aurait été la capacité CAP_LINUX_IMMUTABLE mais c'est une autre histoire). Essayons maintenant avec un lien symbolique :

$ ln -s /etc/motd mylink

$ sudo chattr +i mylink 
chattr: Operation not supported while reading flags on mylink
  

Bon, c'est raté, chattr ne marche pas sur les liens symboliques. (Le message exact dépend de votre libc ; vous aurez peut-être plutôt « Symbolic link loop ».) En tout cas, ça ne marche pas sur Linux. (Il parait que cela fonctionne sur FreeBSD.)

Comment faire, alors ? Changer le propriétaire du lien ne change rien car la suppression est une opération sur le répertoire. Le propriétaire du répertoire peut supprimer des fichiers qui ne lui appartiennent pas. Et changer le propriétaire du répertoire ne suffit pas, car on veut que Bob puisse continuer à lire et à écrire dans ce répertoire. Le sticky bit seul ne suffirait pas non plus, il empêche de supprimer les fichiers des autres, pas les siens.

ChatGPT a finalement trouvé une solution, mais à la troisième itération, après quelques idées qui ne marchaient pas (ChatGPT, comme tout utilisateur des réseaux sociaux, ne teste pas ses idées avant de les publier ; « You're right », « Yes. Your suspicion is exactly correct ») :

$ ln -s /etc/motd mylink
$ sudo chown root:bob .
$ sudo chmod +t .
$ sudo chmod g+w .
$ sudo chown --no-dereference root:root mylink

$ rm mylink 
rm: cannot remove 'mylink': Operation not permitted

$ ls -alt                                
total 8
drwxrwxr-t 2 root bob  4096 Sep  9 15:26 .
lrwxrwxrwx 1 root root    9 Sep  9 15:26 mylink -> /etc/motd
drwxr-x--- 3 bob  bob  4096 Sep  9 15:25 ..
  

Détaillons cette solution. On met root comme propriétaire du répertoire (on peut aussi utiliser un autre utilisateur que root) mais le groupe est bob, un groupe qui inclut Bob. On met ensuite le sticky bit. On donne au groupe le droit d'écriture dans le répertoire. Et enfin on change le propriétaire du lien pour que cela ne soit pas Bob (notez le --no-dereference sans lequel chown essaierait de changer la cible du lien et pas le lien). Et Bob ne peut plus supprimer le lien, tout en pouvant lire et écrire dans le répertoire.

En 1981, la société BBN a écrit pour la DARPA (ex-ARPA) un rapport de 184 pages « A history of the Arpanet - The first decade » qui faisait le bilan des dix (en fait plutôt onze et demi) premières années du réseau Arpanet. Cela reste un des meilleurs documents pour celles et ceux qui veulent comprendre comment marchait l'Arpanet, qui n'était pas du tout un Internet en plus petit, mais un réseau assez différent.

Rappelez-vous la date, 1981. Le rapport est tapé à la machine et vous ne trouverez pas de version machine-readable, vous n'aurez qu'une image.

Le rapport détaille les objectifs (vous n'y trouverez pas la légendaire « nécessité de résister à une attaque nucléaire »), l'histoire, et la technique. Arpanet était très expérimental et les débuts ont été plutôt agités.

Contrairement à l'Internet, l'Arpanet était un réseau très homogène (je parle du réseau, pas des ordinateurs qui y étaient connectés) et très centralisé. Par exemple, tout l'Arpanet était supervisé depuis un point unique (le routage, par contre, était décentralisé). Et le choix des liens entre les sites était décidé centralement, optimisé par un programme développé spécialement (dont l'histoire ne semble pas avoir gardé le code source…). La technique a évidemment beaucoup progressé et on rit aujourd'hui des efforts pour développer du matériel spécifique nécessaire pour calculer des sommes de contrôle à la vitesse ébouriffante de 50 kb/s. Bon, je rigole mais il faut se rappeler que, pour les concepteurs de l'Arpanet, presque tout était nouveau et que plein de choses ont dû être inventées. Le code des IMP (en très gros l'équivalent des routeurs) était écrit en langage d'assemblage, pour les performances, et très optimisé.

Le rapport est globalement positif mais il est intéressant de noter qu'il mentionne aussi les points où l'Arpanet a des problèmes et des limites : le problème de la congestion (qui ne sera traité que bien plus tard, le rapport parle d'ailleurs du développement de TCP), la difficulté à concevoir des protocoles pour les machines terminales (les IMP étaient tous identiques donc leur cas était plus facile) ou la difficulté de la gestion centralisée des ressources (la liste des services disponibles aurait dû être un document unique, centralisé, ce qui a craqué rapidement).

Si certains points portent la marque de leur époque et font sourire aujourd'hui, d'autres sont toujours très importants comme la constatation que « it is possible that this social feasibility demonstration is as important as the many technical feasability demonstrations », conclusion qui reste très vraie sur l'Internet aujourd'hui.

Outre son grand intérêt historique, je recommande la lecture de ce rapport à toutes celles et tous ceux qui s'intéressent à la conception de réseaux informatiques, et aux innombrables choix qu'il faut faire. Tout est intéressant dans ce rapport mais je vous signale particulièrement, vers la fin, la discussion sur pourquoi Arpanet a été un succès (en gros, des gens brillants, beaucoup d'argent, et pas trop de bureaucratie).

Les origines militaires de l'Arpanet font que ce rapport était à l'origine à diffusion restreinte mais a été déclassifié depuis. Malgré cela, il n'est pas toujours facile à trouver. Voici quelques endroits possibles :

• Dans la National Security Archive,
• Et bien sûr, sur l'Internet Archive.