Ce blog n'a d'autre prétention que de me permettre de mettre à la disposition de tous des petits textes que j'écris. On y parle surtout d'informatique mais d'autres sujets apparaissent parfois.
Date de publication du RFC : Septembre 2025
Auteur(s) du RFC : J. Stenstam (The Swedish Internet
Foundation), P. Thomassen (deSEC, Secure Systems
Engineering), J. Levine (Standcore
LLC)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF dnsop
Première rédaction de cet article le 5 octobre 2025
Vous le savez, le protocole DNS permet plusieurs sortes de messages, identifiés par un code d'opération. Si le classique QUERY, pour demander à résoudre un nom en informations pratiques, est le plus connu, il y a aussi le UPDATE (modifier les données), le DSO (DNS Stateful Operations) et quelques autres. Et puis il y a le NOTIFY, qui sert à indiquer à un serveur DNS qu'il y a quelque chose de nouveau et d'intéressant. NOTIFY est surtout connu pour son utilisation afin de… notifier un serveur secondaire que le primaire a une nouvelle version de la zone (c'est dans le RFC 1996). Ce nouveau RFC généralise le concept et permet d'utiliser NOTIFY pour d'autres choses comme un changement dans la liste des serveurs faisant autorité ou un changement de clé DNSSEC.
Si vous avez oublié à quoi servait initialement NOTIFY, relisez le RFC 1996. Il permettait de donner une indication (uniquement une indication, le NOTIFY ne fait pas autorité) comme quoi il faudrait envisager un nouveau transfert de zone (RFC 5936) pour mettre à jour un serveur. Cela permettait des mises à jour plus rapides qu'avec le système traditionnel où chaque serveur esclave devait de temps en temps demander à son maître s'il y avait du nouveau. Mais il y a d'autres cas où un serveur DNS voudrait dire à un autre qu'il y a quelque chose à regarder, par exemple si une nouvelle clé doit être utilisée. D'où l'extension d'utilisation que permet notre RFC 9859. Elle ne change pas le protocole, elle se contente d'utiliser plus largement une fonction existante.
Bon, mais c'est bien joli de dire qu'on peut notifier pour bien
des choses mais on notifie qui ? Dans le cas traditionnel d'une
nouvelle version de la zone, le primaire savait qu'il devait
notifier ses secondaires, qu'il connait (après tout, il doit leur
autoriser le transfert de zone et, dans le pire des cas, il peut
toujours regarder l'ensemble d'enregistrements NS de sa zone). Mais
si on généralise le NOTIFY, on peut ne pas savoir qui notifier (les
autres mécanismes de notification, comme une API ou comme la mise à
jour dynamique du RFC 2136, ont d'ailleurs le
même problème). La section 3 du RFC couvre ce problème. La méthode
recommandée est de publier un enregistrement de type DSYNC, normalisé
dans notre RFC, section 2. Il se place sous le nom
_dsync
de la zone :
sousdomaine._dsync IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net.
Notez qu'un joker est possible, par exemple :
*._dsync IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net. *._dsync IN DSYNC CSYNC NOTIFY 5359 cds-scanner.example.net.
Ce nom _dsync
a été ajouté dans le registre
des noms précédés d'un trait bas (RFC 8552).
Voici un autre exemple
d'enregistrement DSYNC :
_dsync.example.net. IN DSYNC CDS NOTIFY 5359 cds-scanner.example.net.
Que dit-il ? Qu'example.net
, a priori un
hébergeur DNS, voudrait que ses clients, lorsqu'ils ont un nouvel
enregistrement CDS (indiquant l'activation d'une nouvelle clé
DNSSEC, cf. RFC 8078),
notifient cds-scanner.example.net
sur le
port 5359. Ce nouveau type DSYNC a été ajouté
au registre des types, avec la valeur 66.
La section 4.1 détaille comment on trouve le serveur à qui
envoyer la notification en utilisant
_dsync
. Imaginons qu'on gère
extra.sub.exodus-privacy.eu.org
et qu'on
veuille notifier la zone parente. On insère le composant
_dsync
après le premier composant (cela donne
extra._dsync.sub.exodus-privacy.eu.org
) et on
fait une requête pour ce nom et le type DSYNC. Si ça marche, c'est
bon, sinon, on utilise le SOA dans la réponse pour trouver la zone
parente, et on met le _dsync
devant. Si ça ne
donne toujours rien, on retire les composants avant la zone parente
et on recommence. Donc, on interrogera successivement (jusqu'au
premier succès),
extra._dsync.sub.exodus-privacy.eu.org
,
extra.sub._dsync.exodus-privacy.eu.org
et
_dsync.exodus-privacy.eu.org
.
Et le NOTIFY dans l'enregistrement DSYNC d'exemple plus haut ? C'est le plan (scheme, à ne pas confondre avec le code d'opération - opcode - NOTIFY) car DSYNC, dans le futur, pourra servir à autre chose que les notifications. Pour l'instant, dans le nouveau registre des plans, il n'y a que NOTIFY mais dans le futur, d'autres pourront être ajoutés (suivant la politique « Examen par un expert » du RFC 8126).
Comment utiliser ce mécanisme de notification généralisé pour
traiter les enregistrements CDS et CDNSKEY des RFC 7344, RFC 8078 et RFC 9615 ? Ces enregistrements servent à signaler à la zone
parente la disponibilité de nouvelles clés DNSSEC. La section 4 de
notre RFC détaille comment le mécanisme de notification permet
d'indiquer qu'un CDS ou un CDNSKEY a changé. Cela évite au
gestionnaire de la zone parente de balayer toute la zone ce qui,
pour un TLD
de plusieurs millions de noms comme
.fr
serait long et
pénible. La solution de ce RFC 9859 est donc de
chercher les DSYNC puis d'envoyer les NOTIFY, au moins deux, un pour
le type CDS et un pour le type CDNSKEY (on ne sait pas forcément à
l'avance lesquels utilisent la zone parente). La zone parente doit
effectuer les mêmes vérifications que lorsqu'elle a détecté un
nouveau CDS (ou CDNSKEY) : RFC 9615 si on
active une zone signée pour la première fois et RFC 7344 et RFC 8078 autrement.
Les messages utilisant le code d'opération NOTIFY sont censés produire une réponse (RFC 1996, section 4.7). Si aucune réponse n'arrive avant l'expiration du délai de garde, on réessaie. Si on a trop réessayé, on peut signaler le problème avec la technique du RFC 9567.
Il est important de se souvenir qu'une notification n'est pas sérieusement authentifiée, et que le récepteur doit donc, s'il choisit d'agir sur une notification, être prudent. Dans le RFC 1996, rien de grave ne pouvait arriver, le récepteur du NOTIFY demandait juste le SOA de la zone puis, si nécessaire, un transfert de zone. Mais avec les CDS et CDNSKEY, des attaques plus sérieuses sont possibles et le destinataire de la notification doit donc effectuer davantage de vérifications (par exemple, si la zone est déjà signée, faire une requête pour le CDS ou le CDNSKEY et vérifier que la réponse est valide et sécurisée, si elle ne l'est pas, faire tous les contrôles du RFC 9615). La notification elle-même n'est pas un problème de sécurité (elle dit juste « tu devrais regarder cela »), c'est l'action qui en résulte qui doit être bien réfléchie. Voilà pourquoi les notifications, même généralisées, ne sont pas plus sécurisées que cela. (Voir aussi la section 5 du RFC, qui insiste sur ce point ; la notification peut accélérer les choses mais ne doit pas à elle-même changer quelque chose.) Il est quand même préférable de limiter le nombre de notifications qu'on traite, au cas où un client malveillant vous bombarde de notifications.
Ces notifications généralisées pourront aussi s'utiliser pour les CSYNC du RFC 7477.
Qui met en œuvre ce RFC à l'heure actuelle ? Des opérateurs comme
deSEC ont annoncé que c'était
en cours, côté client. Côté serveur, les registres de
.ch
et
.se
ont annoncé que
c'était en cours, ou bien prévu.
Voici un exemple d'un client en Python (utilisant dnspython) qui notifie pour un nouveau CDS :
import dns.message import dns.query import dns.opcode notify = dns.message.make_query("bortzmeyer.fr", "CDS") notify.set_opcode(dns.opcode.NOTIFY) response = dns.query.udp(notify, "192.0.2.211") print(response)
Et en C ? Vous pouvez
utiliser le programme d'exemple
, qui utilise l'excellente
bibliothèque ldns. Compiler
et exécuter :
generalized-notify.c
% gcc -o generalized-notify -Wall generalized-notify.c -lldns % ./generalized-notify bortzmeyer.fr 192.0.2.211 Reply code: NOERROR
Je note à ce sujet que certains serveurs faisant autorité, lorsqu'ils ne font pas autorité pour le domaine signalé, répondent REFUSED, ce qui est logique, mais on voit aussi des FORMERR ou NXDIOMAIN (!), sans doute parce que le type CDS ne leur plait pas.
L'annexe A du RFC prend de la hauteur et décrit plus en détail le
problème du balayage DNS. Comment savoir qu'il y a du nouveau, sans
tout examiner (dans le cas du SOA, au rythme indiqué par le champ
Refresh ; mais il n'y a pas de telle solution pour les CDS et
CDNSKEY). Le DNS traditionnel ne marchait que sur un modèle
pull (et c'est pour cela qu'il est faux de parler
de propagation DNS) mais les
NOTIFY du RFC 1996 introduisaient un peu de
push. Heureusement car balayer
.com
à la recherche de
nouveaux enregistrements serait lent (et attirerait probablement
l'attention des IDS). Pour les CDS et CDNSKEY, cela serait
d'autant plus agaçant qu'ils seront a priori peu nombreux et que la
plupart des requêtes ne donneront donc rien.
Date de publication du RFC : Septembre 2025
Auteur(s) du RFC : S. Hollenbeck (Verisign Labs), W. Carroll (Verisign), G. Akiwate (Stanford University)
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 5 octobre 2025
Dans un registre de noms de domaine, il existe une classe d'objets pour les domaines et parfois une pour les serveurs de noms (hosts). C'est en se basant sur les objets de ces classes que des informations sont ensuite publiées dans le DNS. Que se passe-t-il si on retire un objet de ces classes, alors que d'autres objets en dépendaient ? Va-t-on scier une branche sur laquelle quelqu'un est assis ? Ce RFC fait le point sur les solutions existantes, notant que certaines sont moins bonnes que d'autres, notamment pour la sécurité.
Prenons un exemple simple : le domaine
monbeaudomaine.example
est enregistré auprès du
registre
du TLD .example
. Ses
serveurs de noms sont ns1.domaine-d-un-copain.example
et
ns1.hébergeur.example
et on va supposer que le
registre de .example
traite les serveurs de
noms comme une classe distincte dans sa base de données. Maintenant,
supposons que le domaine
domaine-d-un-copain.example
soit supprimé parce
que son titulaire n'en voit plus l'utilité. Que va devenir le
serveur de noms
ns1.domaine-d-un-copain.example
? Il existe de
nombreuses façons de traiter ce problème, et c'est le rôle de ce RFC
de les analyser toutes.
Ainsi, la section 3.2.2 du RFC 5731 dit que
ce n'est pas bien de détruire un domaine si des objets de type
serveur de noms sont sous ce domaine. Dans l'exemple précédent, le
registre de .example
aurait refusé la
suppression de
domaine-d-un-copain.example
. Mais cela laisse
le problème entier : si le titulaire ne veut plus payer et donc veut
supprimer le domaine, que faire ?
Un cas similaire se produit si on veut supprimer un serveur de
noms. Si le client EPP demande au serveur EPP
du registre de .example
la suppression de
l'objet ns1.domaine-d-un-copain.example
, que
doit faire le registre, sachant que ce serveur de noms est utilisé
par monbeaudomaine.example
? La section 3.2.2
du RFC 5732 dit que le registre devrait
refuser la suppression. C'est d'autant plus gênant que, dans le
modèle RRR (Registrant-Registrar-Registry), domaine et serveur(s) peuvent
être gérés par des BE différents, n'ayant
pas le droit de toucher aux objets des autres BE.
Vous pouvez trouver des bonnes explications et des exemples réels dans les supports d'une présentation qui avait été faite à l'IETF.
Quelles sont donc les recommandations concrètes de ce RFC ? La section 6 les résume. Au choix :
sacrificial.invalid
,
utilisant un TLD existant,
est recommandé.Le protocole EPP permet de changer le nom
d'un serveur de noms (section 3.2.5 du RFC 5732). Une pratique déjà observée est donc de renommer les
serveurs de noms. Dans l'exemple ci-dessus, recevant la demande de
suppression de domaine-d-un-copain.example
, le
registre (ou le BE s'il le peut) renommerait
ns1.domaine-d-un-copain.example
en, mettons,
ns1.domaine-d-un-copain.renamed.invalid
. Ici,
.invalid
, TLD réservé
par le RFC 6761, ne poserait pas vraiment de
problème mais renommer dans un domaine ouvert à l'enregistrement
pourrait créer un risque de sécurité, si le domaine de destination
n'existe pas, un méchant pouvant alors l'enregistrer et être ainsi en
mesure de répondre aux requêtes DNS.
La section 3 du RFC explique brièvement pourquoi les RFC 5731 et RFC 5732 déconseillent fortement de permettre la suppression d'un domaine tant que des serveurs de noms dans ce domaine existent. Il y a deux risques de sécurité si on détruisait le domaine en laissant les serveurs de noms tels quels dans la base de données du registre : un de déni de service (le nom ne se résout plus et le serveur va donc être inutile) et un de détournement (si un méchant peut ré-enregistrer le nom de domaine supprimé). Il y a aussi le problème de la colle orpheline, décrit dans le rapport du SSAC, « Comment on Orphan Glue Records in the Draft Applicant Guidebook ».
Si la clé qui identifie un serveur de noms est un numéro quelconque et pas son nom, on peut renommer le serveur sans changer les délégations, ce qui est particulièrement utile si le client EPP n'a pas le droit de changer des délégations qui appartiennent à un autre client du registre. Le nouveau nom ne va en général pas être associé à un serveur opérationnel : on sacrifie un serveur pour pouvoir supprimer le domaine parent. Mais cela entraine quelques risques (section 4 du RFC et l'article d' Akiwate, G., Savage, S., Voelker, G., et K. Claffy, « Risky BIZness: Risks Derived from Registrar Name Management »). Si on renomme vers un nom actuellement inexistant, le domaine peut être détourné si un malveillant enregistre ensuite ce domaine.
Compte tenu de tout cela, la section 5 du RFC étudie les différentes pratiques possibles, leurs avantages et leurs inconvénients. Pour les illustrer, je vais utiliser une base de données simple, décrite en SQL (les essais ont été faits avec PostgreSQL). Voici par exemple une création d'une telle base :
CREATE TABLE Domains (name TEXT UNIQUE); -- Ici, la table Nameservers n'offre aucune valeur ajoutée par rapport -- au fait de tout mettre dans Domains. Mais ce ne sera pas le cas par -- la suite. CREATE TABLE Nameservers (name TEXT UNIQUE); CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name), server TEXT REFERENCES Nameservers(name)); INSERT INTO Domains VALUES ('monbeaudomaine.example'); INSERT INTO Domains VALUES ('domaine-d-un-copain.example'); INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example'); INSERT INTO Nameservers VALUES ('ns1.hébergeur.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example');
Dans ce premier cas très simple, la suppression du domaine
domaine-d-un-copain.example
est triviale :
registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example'; DELETE 1
Mais elle laisse la possibilité de colle
orpheline et surtout d'un détournement de monbeaudomaine.example
si
quelqu'un ré-enregistre
domaine-d-un-copain.example
. Ce premier essai
n'est pas conforme aux exigences des RFC 5731
et RFC 5732. On va essayer de
faire mieux.
Si on interdit (à juste titre) la suppression d'un domaine lorsque des serveurs de noms sont nommés dans ce domaine, on peut arriver à supprimer un domaine en supprimant d'abord les serveurs de noms qui sont nommés dans ce domaine (section 5.2) :
CREATE TABLE Domains (name TEXT UNIQUE); -- Ajout d'une dépendance au domaine parent, pour éviter les suppressions. CREATE TABLE Nameservers (name TEXT UNIQUE, parent TEXT REFERENCES Domains(name)); CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name), server TEXT REFERENCES Nameservers(name)); INSERT INTO Domains VALUES ('monbeaudomaine.example'); INSERT INTO Domains VALUES ('domaine-d-un-copain.example'); INSERT INTO Domains VALUES ('hébergeur.example'); -- Pour une vraie base, on écrirait du code SQL qui extrait le parent -- automatiquement. INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example'); INSERT INTO Nameservers VALUES ('ns1.hébergeur.example', 'hébergeur.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example'); registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example'; ERROR: update or delete on table "domains" violates foreign key constraint "nameservers_parent_fkey" on table "nameservers" DETAIL: Key (name)=(domaine-d-un-copain.example) is still referenced from table "nameservers". -- Ce comportement est ce que recommandent les RFC 5731 et 5732. -- Cela oblige le client à supprimer les serveurs de noms d'abord, ce qui à -- son tour nécessite potentiellement de changer les délégations : registry=> DELETE FROM Delegation WHERE server = 'ns1.domaine-d-un-copain.example'; DELETE 1 registry=> DELETE FROM Nameservers WHERE name='ns1.domaine-d-un-copain.example'; DELETE 1 registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example'; DELETE 1
Ici, il y a eu suppression explicite des serveurs de noms par le
client (section 5.2.2.1). Cela peut poser des problèmes de permission, dans le cadre du
système RRR, si tous les objets ne sont pas
chez le même BE. Mais la suppression explicite est
une des trois solutions recommandées, notamment si on ajoute la
possibilité de rétablir l'état précédent (commande EPP
<restore>
, RFC 3915).
On peut aussi envisager une suppression implicite (section 5.2.1.1), le registre se
chargeant du nettoyage (c'est le rôle
de la directive SQL ON DELETE
CASCADE
) :
CREATE TABLE Domains (name TEXT UNIQUE); CREATE TABLE Nameservers (name TEXT UNIQUE, parent TEXT REFERENCES Domains(name) ON DELETE CASCADE); CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name) ON DELETE CASCADE, server TEXT REFERENCES Nameservers(name) ON DELETE CASCADE); INSERT INTO Domains VALUES ('monbeaudomaine.example'); INSERT INTO Domains VALUES ('domaine-d-un-copain.example'); INSERT INTO Domains VALUES ('hébergeur.example'); -- Pour une vraie base, on écrirait du code SQL qui extrait le parent -- automatiquement. INSERT INTO Nameservers VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example'); INSERT INTO Nameservers VALUES ('ns1.hébergeur.example', 'hébergeur.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.domaine-d-un-copain.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', 'ns1.hébergeur.example'); registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.name; name | name ------------------------+--------------------------------- monbeaudomaine.example | ns1.domaine-d-un-copain.example monbeaudomaine.example | ns1.hébergeur.example (2 rows) registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example'; DELETE 1 -- Serveur de noms et délégation ont été détruits en cascade. Ce n'est -- pas déraisonnable mais c'est quand même un peu effrayant. registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.name; name | name ------------------------+----------------------- monbeaudomaine.example | ns1.hébergeur.example (1 row)
Cette solution est simple et efficace mais détruire implicitement des objets de la base de données peut inquiéter les responsables de cette base. Et cela peut laisser un domaine avec trop peu de serveurs de noms pour assurer sa continuité de service voire, dans le pire des cas, sans serveurs du tout. Et il serait bon de prévenir le client de cette suppression implicite, par exemple par le mécanisme de poll d'EPP (RFC 8590).
Si on interdit (à juste titre, le RFC le recommande) la suppression d'un
domaine lorsque des serveurs de noms sont nommés dans ce domaine, une
solution possible est de
renommer les serveurs avant de supprimer le domaine (section 5.1). Le nouveau nom
permet d'indiquer clairement la raison du renommage. Mais ce
renommage laisse dans la base des « déchets » qu'il faudra nettoyer
un jour. Cette catégorie
contient de nombreuses variantes. Par exemple, on peut renommer dans
un TLD spécial (RFC 6761), ici, .invalid
:
CREATE TABLE Domains (name TEXT UNIQUE); -- On introduit un identificateur du serveur de noms qui n'est *pas* -- son nom, pour permettre le renommage. CREATE TABLE Nameservers (id SERIAL UNIQUE, name TEXT UNIQUE, parent TEXT REFERENCES Domains(name)); CREATE TABLE Delegation (domain TEXT REFERENCES Domains(name), server INTEGER REFERENCES Nameservers(id)); INSERT INTO Domains VALUES ('monbeaudomaine.example'); INSERT INTO Domains VALUES ('domaine-d-un-copain.example'); INSERT INTO Domains VALUES ('hébergeur.example'); -- Pour le renommage, un nom qui indique clairement le but : INSERT INTO Domains VALUES ('renamed.invalid'); -- Pour une vraie base, on écrirait du code SQL qui extrait le parent -- automatiquement. INSERT INTO Nameservers (name, parent) VALUES ('ns1.domaine-d-un-copain.example', 'domaine-d-un-copain.example'); INSERT INTO Nameservers (name, parent) VALUES ('ns1.hébergeur.example', 'hébergeur.example'); INSERT INTO Delegation VALUES ('monbeaudomaine.example', (SELECT id FROM Nameservers WHERE name='ns1.domaine-d-un-copain.example')); INSERT INTO Delegation VALUES ('monbeaudomaine.example', (SELECT id FROM Nameservers WHERE name='ns1.hébergeur.example')); registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.id; name | name ------------------------+--------------------------------- monbeaudomaine.example | ns1.domaine-d-un-copain.example monbeaudomaine.example | ns1.hébergeur.example (2 rows) registry=> UPDATE Nameservers SET name='ns1.domaine-d-un-copain.example.renamed.invalid', parent='renamed.invalid' WHERE id=1; UPDATE 1 registry=> DELETE FROM Domains WHERE name='domaine-d-un-copain.example'; DELETE 1 registry=> SELECT Domains.name,Nameservers.name FROM Domains,Delegation,Nameservers WHERE Delegation.domain=Domains.name AND Delegation.server=Nameservers.id; name | name ------------------------+------------------------------------------------- monbeaudomaine.example | ns1.domaine-d-un-copain.example.renamed.invalid monbeaudomaine.example | ns1.hébergeur.example (2 rows)
Par contre, il ne faut pas utiliser .alt
, qui
est explicitement réservé aux protocoles non-DNS (RFC 9476). Notez que certains serveurs EPP peuvent tester le
nom des serveurs de noms et refuser des TLD « inconnus ».
Dans la nature, on a pu observer d'autres pratiques, comme de
renommer dans un sous-domaine de as112.arpa
, nom
garanti ne pas exister (RFC 7535), mais qui
n'est pas censé servir à cela (RFC 6305). On a
vu aussi des renommages vers des résolveurs DNS publics, ce qui est
également une horreur, la délégation doit être faite vers des serveurs faisant
autorité, pas des résolveurs.
Certains clients EPP maintiennent des serveurs de noms actifs qui
servent pour le renommage. Cela fait davantage de travail mais cela
protège contre le détournement. Le DNS va continuer à fonctionner
normalement. On pourrait aussi imaginer des serveurs de noms actifs, répondant
NXDOMAIN (« ce domaine n'existe pas »), qui soient
gérés collectivement (section 5.1.4.4) ; un tel service serait
certainement utile. On pourrait même créer un nom de domaine pour ce
service (sacrificial.arpa
?) mais personne ne
l'a encore fait. Pour l'instant, la solution des serveurs maintenus
par le client EPP (section 5.1.3.4) fait partie des trois solutions
recommandées. Le client prudent doit bien verrouiller le domaine dans
lequel ces serveurs sont nommés (enregistrement multi-années,
verrouillage par le registre, etc).
On peut aussi renommer les serveurs de noms vers un nom
non-existant dans un TLD existant. Ça s'est déjà vu mais il ne faut
surtout pas faire cela : un attaquant pourrait enregistrer le nom et
capter ainsi le trafic (.invalid
n'a pas ce
problème). Idem si le nom n'est pas sous votre contrôle. Un exemple
est donné par le domaine lenvol.re
: ses
serveurs de noms étaient ns.hostin.io
,
ns.hostin.mu
et
ns.hostin.re
. Lors de la suppression de
hostin.re
en octobre 2024, le dernier serveur
de noms a été renommé
host1.renamedbyregistry.com
(et, en dépit du
nom, pas par le registre). Ce domaine
renamedbyregistry.com
étant enregistré, et par
un autre BE, on voit le risque.
% whois lenvol.re domain: lenvol.re status: ACTIVE … nserver: host1.renamedbyregistry.com nserver: ns.hostin.io nserver: ns.hostin.mu
D'autres noms qui utilisaient ce même serveur ont également le problème :
% dig @d.nic.fr savanna.re. NS … ;; AUTHORITY SECTION: savanna.re. 3600 IN NS host1.renamedbyregistry.com. savanna.re. 3600 IN NS ns.hostin.mu. savanna.re. 3600 IN NS ns.hostin.io. ;; Query time: 8 msec ;; SERVER: 2001:678:c::1#53(d.nic.fr) (UDP) ;; WHEN: Tue Jun 24 14:33:32 CEST 2025
En lecture supplémentaire, notre RFC recommande le rapport « SSAC 125 "Report on Registrar Nameserver Management" », ainsi que l'article « Risky BIZness: Risks Derived from Registrar Name Management ».
Première rédaction de cet article le 4 octobre 2025
Bon, c'est un article d'ultra-niche. Mais, comme j'ai eu du mal à faire fonctionner cette configuration, je me dis que je peux la décrire, et que peut-être quelqu'un·e trouvera cet article un jour via un moteur de recherche, et que cela lui servira. Donc, le problème était : soit un ensemble de machines Debian configurées via Ansible. Un paquetage dont j'avais besoin n'était que dans la version Debian unstable. Comment l'installer via le module Ansible apt ?
D'abord, je détaille le problème. Pour une formation DNSSEC, je gère N machines virtuelles tournant sous Debian. Le paquetage d'OpenDNSSEC, qui était dans les précédentes versions de Debian, a été retiré de l'actuelle version stable, la version 13, alias « trixie ». La configuration que j'utilisais d'habitude avec Ansible et son module apt n'est donc pas utilisable telle quelle pour installer OpenDNSSEC.
Il y a bien sûr plusieurs solutions à ce problème (mais pas celle des backports, OpenDNSSEC n'y est pas) :
dpkg -i
. À la réflexion,
c'est sans doute ce que j'aurais dû faire, mais il n'est pas
garanti que cela aurait bien marché.
J'ai finalement choisi une autre voie : utiliser
stable mais permettre l'installation de
paquetages qui existent dans unstable. Bien que
déconseillée
par Debian, cette méthode est assez banale et on trouve en
ligne plein d'instructions sur comment la réaliser. Une
configuration simple est, dans
/etc/apt/sources.list.d/unstable.sources
:
Types: deb deb-src URIs: mirror+file:///etc/apt/mirrors/debian.list Suites: sid Components: main Signed-By: /usr/share/keyrings/debian-archive-keyring.gpg
(sid
est le petit nom de la version
unstable. Si vous avez vu Toy
Story, vous savez pourquoi.)
Avec cela, vous pouvez maintenant installer des paquetages
d'unstable mais attention, vous ne voulez pas que
ces paquetages remplacent vos paquetages stable
existants ! Il faut donc aussi donner une basse priorité à
unstable, avec un /etc/apt/preferences.d/99unstable
:
Package: * Pin: release a=unstable Pin-Priority: 1
Désormais, après le prochain apt update
, un apt install quelquechose
installera bien la version stable du paquetage
« quelquechose », qui a une priorité supérieure. Et apt
install opendnssec
installera la version
d'unstable puisqu'il n'y en a pas dans stable.
Tout cela est classique et bien connu, et ça marche. Mais depuis Ansible, patatras. Le module apt d'Ansible prétend qu'il n'existe pas d'OpenDNSSEC, alors que ça marche en ligne de commande avec apt. Voici la configuration du module :
tasks: … - name: install packages apt: # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html name: [truc, machin, opendnssec] state: present
C'est apparemment parce que Ansible ajoute à apt une option qui lui dit de n'utiliser que stable et je n'ai pas trouvé le moyen de couper cette option.
La solution est donc de faire deux tâches Ansible, une pour
stable et une pour unstable,
en utilisant le paramètre
default_release
. Voici ma configuration
complète et qui marche :
tasks: … - name: "Copy apt sources" copy: src: apt-unstable.sources dest: /etc/apt/sources.list.d/unstable.sources - name: "Copy apt preferences" copy: src: apt-preferences.txt dest: /etc/apt/preferences.d/99unstable - name: "Update Repository cache" apt: # https://docs.ansible.com/ansible/latest/collections/ansible/builtin/apt_module.html update_cache: true upgrade: dist cache_valid_time: 3600 force_apt_get: true - name: install packages apt: name: [truc, chose, machin] state: present - name: install unstable packages apt: name: [opendnssec, softhsm2] default_release: sid state: latest
Notez le state: latest
. Si on laisse à la
valeur par défaut, present
, Ansible produit un
message d'erreur incohérent prétendant que sid
n'est pas dans les sources.
Première rédaction de cet article le 4 octobre 2025
Le site Web « MonLycée.net » a été souvent mentionné dans la
presse française il y a deux semaines, suite à l'annonce que la région Île-de-France
allait remplacer certains logiciels Microsoft
par des logiciels français. Mais la communication était mal faite,
seul
marchait, pas http://monlycee.net/
(avec l'accent sur le
E). C'est désormais réparé.http://monlycée.net/
L'essentiel de la communication en français utilisait en effet le
nom de domaine
monlycée.net
, ce qui est logique, le
lycée prend en effet un accent. Mais, depuis
très longtemps, le nom de domaine à utiliser était
monlycee.net
, le nom correct n'étant pas
configuré.
Cette copie d'écran du site Web montre bien que l'orthographe
correcte est utilisée depuis longtemps :
Mais, en septembre 2025, au moment où ce site était beaucoup
mentionné dans les médias, le domaine
monlycée.net
existait bien mais n'était pas correctement configuré dans le
DNS, aucun des deux
serveurs de noms ne répondait. Voici ce qu'on voyait avec dig le 29 septembre
(si vous utilisez un dig compilé sans IDN, vous devrez utiliser
xn--monlyce-gya.net
au lieu de
monlycée.net
) :
% dig @l.gtld-servers.net. monlycée.net NS … ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14466 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 4, ADDITIONAL: 1 … ;; AUTHORITY SECTION: monlycée.net. 172800 IN NS dns1.namebay.com. monlycée.net. 172800 IN NS dns2.namebay.com. ;; Query time: 41 msec ;; SERVER: 2001:500:d937::30#53(l.gtld-servers.net.) (UDP) ;; WHEN: Mon Sep 29 09:14:57 CEST 2025 ;; MSG SIZE rcvd: 244 % dig @dns1.namebay.com. monlycée.net. NS … ;; ->>HEADER<<- opcode: QUERY, status: REFUSED, id: 32749 ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1 … ; COOKIE: e359c164d9f8ced10100000068da31fe1b539adeb5eee54e (good) ; EDE: 18 (Prohibited) ; EDE: 20 (Not Authoritative): (recursion disabled) … ;; Query time: 20 msec ;; SERVER: 2a01:c8:ff00:201::133#53(dns1.namebay.com.) (UDP) ;; WHEN: Mon Sep 29 09:15:09 CEST 2025 ;; MSG SIZE rcvd: 106
Le serveur faisant autorité pour
.net
annonce que les
deux serveurs faisant autorité pour
monlycée.net
sont
dns1.namebay.com
et
dns2.namebay.com
mais aucun des deux ne veut
répondre. (L'EDE - Extended DNS Error, cf. RFC 8914 indique que le serveur ne fait pas autorité pour ce
nom.) Le domaine ne marche donc pas du tout.
De telles erreurs de communication et/ou de configuration avec les noms de domaine internationalisés sont hélas fréquentes.
Voulant signaler le problème, j'ai utilisé whois :
% whois monlycée.net … Creation Date: 2016-06-27T11:07:12Z … Tech Name: Communication Direction Tech Organization: CONSEIL REGIONAL ILE DE FRANCE Tech Street: 2, rue Simone Veil Bon de commande 81236 Numero d'engagement Chorus 792650 Tech City: SAINT-OUEN … Tech Email: https://www.validname.com/whoiscontact/?id=4377E185-08DF-4351-91A9-D02B507D3806&c=T
Zut, on n'a pas l'adresse du contact technique, juste un
formulaire Web pénible. Bon, j'ai écrit. Le message de confirmation
disait « E-Mail routed to the contact. Thank you for using
our services. Best regards. A-Bot, in charge of routing anonymous
[sic] e-mails. ». Je n'ai évidemment jamais eu de réponse
mais peut-être que quelqu'un a fait quelque chose puisque, le 1
octobre, un certificat Let's Encrypt a été
obtenu pour ce nom, prouvant que le domaine remarchait. Bienvenue à
.https://monlycée.net
Dans son effort louable de progression vers l'autonomie
numérique, le Conseil régional a aussi
installé un PeerTube, ce qui est une
excellente idée. Mais il annonce « PeerTube de Monlycée.net » alors
que seul
fonctionne, pas
https://peertube.monlycee.net/
(nom non existant). On retombe dans le problème de communication
cité plus haut.https://peertube.monlycée.net/
Et quelques petits détails techniques pour finir. D'abord,
X.509 ne permettant pas apparemment
l'Unicode (ou bien c'est
l'AC qui ne le fait pas ?), le certificat
utilise la forme Punycode,
xn--monlyce-gya.net
:
% gnutls-cli monlycée.net … Resolving 'xn--monlyce-gya.net:443'... Connecting to '185.65.56.149:443'... - Certificate type: X.509 … - subject `CN=xn--monlyce-gya.net', issuer `CN=E7,O=Let's Encrypt,C=US', serial 0x06f5adb213041273640f32f866068a400090, EC/ECDSA key 256 bits, signed using ECDSA-SHA384, activated `2025-10-01 09:39:17 UTC', expires `2025-12-30 09:39:16 UTC', pin-sha256="iDBvNYX0tCBtaAEMSv5m2AknA+bFcLX3WCWtCA33S0U="
J'ai vu que ce certificat du 1 octobre est le plus ancien, par une recherche sur crt.sh. Ce service, par ailleurs très utile, ne permet pas de recherche sur le nom en Unicode, mais je crois que c'est une limite de X.509.
Enfin, monlycée.net
est signé avec
DNSSEC mais n'a pas
(encore ?) publié de lien dans le domaine parent.
Première rédaction de cet article le 9 septembre 2025
Le 9 septembre 2025 est sortie la version 17 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 -------- 159866
Combien de caractères sont arrivés avec la version 17 ?
ucd=> SELECT version,count(version) FROM Characters GROUP BY version ORDER BY version::float; ... 14.0 | 838 15.0 | 4489 15.1 | 627 16.0 | 5185 17.0 | 4803
4 803 nouveaux caractères, c'est pas mal, mais moins que la précédente version. Quels sont ces nouveaux caractères ?
ucd=> SELECT To_U(codepoint) AS Code_point, name FROM Characters WHERE version='17.0' ORDER BY Codepoint; code_point | name -----------+---------------------------------------------------------------------------- U+FDCC | ARABIC LIGATURE SALLALLAHU ALAYHI WA-ALAA AALIHEE WA-SALLAM … U+10940 | SIDETIC LETTER N01 U+10941 | SIDETIC LETTER N02 U+10942 | SIDETIC LETTER N03 … U+11DB0 | TOLONG SIKI LETTER I U+11DB1 | TOLONG SIKI LETTER E U+11DB2 | TOLONG SIKI LETTER U U+11DB3 | TOLONG SIKI LETTER O … U+16EA0 | BERIA ERFE CAPITAL LETTER ARKAB U+16EA1 | BERIA ERFE CAPITAL LETTER BASIGNA U+16EA2 | BERIA ERFE CAPITAL LETTER DARBAI … U+1CEC8 | EUNOMIA U+1CEC9 | PSYCHE U+1CECA | THETIS U+1CECB | MELPOMENE … U+1F6D8 | LANDSLIDE … U+1FAC8 | HAIRY CREATURE …
Cette version amène en effet quatre nouvelles écritures. Si l'écriture sidétique n'est connue que par une douzaine d'inscriptions, le zaghawa (Beria Erfe), lui, est toujours en usage. On voit aussi arriver le Tolong Siki et le Lai Tay (Tai Yo). Vous noterez aussi les symboles astronomiques pour les plus gros astéroïdes, comme Victoria.
Il y a d'autres nouveautés que l'addition de caractères. Par exemple les propriétés pour la coupure de mots de la cédille, malgré l'ancienneté de ce caractère, ont été changées pour se conformer aux règles du saanich. Ou bien une nouvelle classe pour les tirets a été créée, Unambiguous_Hyphen, pour des caractères comme le ‐ (regardez bien, c'est le tiret Unicode, U+2010, pas le tiret ASCII, U+002D, qui peut être un tiret ou bien le signe moins).
En plus futile, il y a l'habituelle arrivée d'emojis comme le trombone ou le coffre au trésor. Par contre, le trognon de pomme a finalement été retiré et n'apparaitra pas avant Unicode 18.
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, la troisième lettre de l'alphabet sidétique , le caractère Zaghawa Kobo , l'astéroïde Psyche , le yéti et le glissement de terrain .
Vous voulez davantage de détails ? Vous en trouverez plein dans l'article d'Ysabeau.
Auteur(s) du livre : Fiona M. Alexander, Laura
DeNardis, Nanette
S. Levinson, Francesca Musiani
Éditeur : Palgrave Macmillan Cham
978-3-031-89477-0
Publié en 2025
Première rédaction de cet article le 29 août 2025
Ce livre parle de géopolitique de l'Internet. Banal, vous allez me dire, plein de livres ont déjà été écrits sur ce sujet. Mais celui-ci parle bien de l'Internet, pas des services qui tournent dessus, comme le font la très grande majorité des livres qui prétendent parler de l'Internet, mais ne connaissent que de ce qu'on voit sur l'écran. Ici, au contraire, c'est bien l'infrastructure, le cœur de l'Internet, qui est étudiée par les auteures.
Car l'infrastructure n'est pas neutre et les questions politiques liées à l'Internet ne concernent pas que les trois ou quatre réseaux sociaux centralisés étatsuniens que mentionnent la plupart des auteurs. Ce livre va donner de nombreux exemples, du choix et du déploiement d'IPv6 à la gestion des serveurs racine du DNS, en passant par la censure ou les demandes de blocage des réseaux russes suite à l'invasion de l'Ukraine, ainsi que des sujets très peu traités quand on parle de « gouvernance de l'Internet » comme la distribution d'adresses IP, avec l'exemple des attaques contre Afrinic. Mais pas d'Instagram (cité uniquement à propos d'un problème BGP) ou de Twitch.
De nombreux autres sujets d'infrastructure sont traités, montrant à chaque fois les conséquences politiques de choix que l'on pourrait croire plutôt techniques. Et ce sont aussi bien des sujets déjà largement décrits (la « guerre des protocoles » entre TCP/IP et OSI), que des sujets un peu plus rares comme la normalisation technique ou dont les conséquences politiques sont vraiment très peu discutées, comme la sécurisation de BGP ou les certificats (mais DANE n'est pas mentionné dans cette section, ce qui est dommage).
En prime, le livre est correct techniquement, ce qui n'est pas le cas de tous les textes parlant des aspects sociaux ou politiques de l'Internet, par exemple il ne reprend pas le cliché « les adresses IPv4 sont composées de quatre groupes de chiffres », expliquant même leur format binaire.
Par contre, je regrette que le livre ait un biais très étatsunien. Cela se voit dans des clichés comme parler de « constitutional protections of free expression » (alors que le fameux premier amendement ne s'applique qu'à l'État, et qu'il laisse les entreprises privées s'attaquer à la liberté d'expression tant qu'elles veulent), dans une présentation peu critique de l'ICANN (création du gouvernement étatsunien et qui ne représente pas du tout la mythique « communauté Internet »), ou lorsque des termes juridiques étatsuniens sont utilisés sans être expliqués (sans être lecteur de Grisham, savez-vous ce qu'est un amicus curiae ?). De même, l'Internet Society est présentée en termes vraiment acritiques. Un autre exemple est la place excessive donnée à New IP, projet qui a été beaucoup plus mis en avant par les Étatsuniens, en termes chauvins (« Mon Dieu, les Chinois veulent faire un nouveau protocole »), que par les Chinois eux-mêmes (qui se sont contentés de quelques PowerPoint).
La préface de Fiona Alexander pose un autre problème : elle a été un des acteurs principaux du feuilleton de la « privatisation » de l'ICANN. D'un côté, c'est bien d'avoir comme auteure quelqu'un qui connait le dossier de l'intérieur. De l'autre, elle se donne le beau rôle et fait une présentation très unilatérale (le politicien de droite extrême Ted Cruz étant bien pratique comme repoussoir).
Bref, sur un sujet aussi complexe, il y a plusieurs points de vue, ce qui est logique en politique, donc n'hésitez pas à demander à votre institution de se procurer ce livre (très cher à l'achat, malheureusement ; on peut avoir toutes les conneries qu'on veut en ligne gratuitement mais l'information sérieuse est souvent payante).
(Au passage : j'ai reçu un exemplaire gratuit de l'ouvrage.)
Première rédaction de cet article le 25 août 2025
Dernière mise à jour le 31 août 2025
Du 21 au 23 août 2025, c'était Pas Sage En Steïr. C'était très intéressant, très sympa, et je me suis permis d'y parler d'IA.
Pas Sage En Steïr est l'héritier des réunions Entrée Libre (qui se tenait à Quimper) et Pas Sage En Seine (qui se tenait à Choisy-le-Roi). Pas Sage En Seine a dû être annulé en raison d'une campagne de harcèlement contre les organisateur·rices, d'où Pas Sage En Steïr (car le Steïr coule à Quimper, où se tenait la conférence, au Centre des Abeilles).
Comme dit plus haut, j'ai parlé d'IA, sous le titre un peu sensationnaliste « L'IA n'existe pas ». Vous pouvez récupérer le support (et son source).
Mais il y avait plein d'autres choses intéressantes ! (Le programme est en ligne.) Tout a été enregistré et les vidéos sont disponibles (cf. la mienne). Et il y a aussi une transcription de mon intervention.
Par exemple, « Le testament numérique : que faire de mes données après moi », par Natouille, un « sujet d'après-repas » (non, en fait, c'est un sujet triste mais qu'il faut regarder en face). Il y a aussi bien le problème de données qui disparaissent involontairement que celui de données qui restent en ligne involontairement. Les gros machins (GAFA) ont tous des fonctions (« contact légataire » ou équivalent). Il faut juste leur faire confiance. Il existe des boites privées qui permettent de gérer ses données post-mortem. Faut juste leur faire confiance (honnêteté et pérennité). Dans les conférences, il y avait aussi la place des femmes dans l'informatique, par Isabella Vanni. Ou bien le concept de « Jardinage numérique », par Mindiell, qui présente son jardin, contre les « 5M » : Mondialisation / Monopolisation / Minitelisation / Monétisation / Merdification. Ou le classique mais toujours indispensable « Quelles alternatives pour se libérer des GAFAM », par Bookynette, qui note que la partie n'est pas égale « Les GAFAM peuvent avoir vingt rendez-vous par jour avec des ministres, et l'April zéro ».
Mais il y avait aussi des ateliers passionnants. Les Petits Débrouillards pratiquaient la science participative en guidant les participant·es dans le projet [Plantes] Sauvages de ma rue (on trouve désormais de nombreuses photos des plantes de Quimper). Une sortie bien agréable sous le beau soleil breton, et une découverte. Autre excellent atelier, celui sur l'installation et l'utilisation de Thunderbird (pour échapper aux gros webmails dominants). À noter qu'un des problèmes rencontrés était dû à Orange : IMAP n'est pas activé par défaut sur les comptes de courrier Orange, il faut le faire via son espace client sur le Web mais c'est refusé si on n'est pas sur sa connexion à la maison (cf. la documentation). Mais, bon, Proton Mail fait payer pour la même opération.
Et, comme d'habitude au Centre des Abeilles, mille mercis pour Brigitte et son rôle crucial.
First publication of this article on 25 August 2025
July 2025? Among many other events in the world, this was the IETF meeting, the 123rd, in Madrid. Before the meeting, there was the now traditional hackathon. I worked on the future protocol RPP (RESTful Provisioning Protocol), which may be the successor of EPP.
EPP (RFC 5730) is the current
standard for provisioning, specially domain names. When you register
a domain name, the registrar you use
probably talks to the registry with EPP. EPP
has some limits and the IETF is working (in the rpp working group)
on another protocol, RPP
(for RESTful Provisioning Protocol). Such a REST API is already
done, for
instance at Afnic (the domain name registry of
.fr
).
At the time of the IETF hackathon, RPP was far from done, there was not even a consensus on some basic aspects. So, unlike many hackathon projects, there was no attempt to test interoperability of different implementations of a protocol. The idea was instead to explore various things related to a REST provisioning protocol.
OK, so my specific work (the code is on GitHub):
Let's do a demo first:
% createdb registry % psql -f ./create.sql registry % ./test-server.py
Then let's get information about a domain with curl (one of the goals of a RESTful protocol like RPP is to be able to use regular HTTP clients):
% curl --header @headers.txt http://localhost:8080/domains/nic.example {"result": "Domain nic.example exists", "holder": 1, "tech_contact": 1, "admin_contact": 1, "registrar": 1, "created": "2025-08-25T14:04:18.271586", "status_code": 200, "status_message": "OK"}
And create a domain (note we have to authentify this time):
% curl --header @headers.txt --request PUT --user 2:qwerty --data '{"holder": 2, "tech": 2, "admin": 2}' http://localhost:8080/domains/durand.example {"result": "durand.example created", "status_code": 201, "status_message": "Created"}
OK, you get the idea, the README.md
file will give you some examples.
The registry is a PostgreSQL database. The server is written in Python, uses the WSGI framework, depends on several modules from the Python standard library and on psycopg2 and jsonschema. We use JSONschema for the validation of the incoming JSON (remember that RPP is far from being standardized and no schema language have been chosen yet). The test client, as you saw, is regular curl.
I added a (very small) test suite written in Zig:
% cd tests % zig build test
(I took the opportunity of the hackathon to post a sample HTTP client written in Zig to the Ziggit forum.)
The work done at the RPP table of the hackathon is presented here. All the live presentations are on YouTube and ours is at 1:19:08. Now, the rpp working group continues its work… (See the development on Github.)
Auteur(s) du livre : William Blanc, Justine
Breton, Jonathan Fruoco
Éditeur : Libertalia
9-782377-293513
Publié en 2024
Première rédaction de cet article le 10 juillet 2025
Dans ce livre, William Blanc, avec Justine Breton et Jonathan Fruoco, poursuit son exploration des mythes nés de héros de fiction. Car, si Robin des Bois n'a probablement jamais existé, le mythe, lui, est bien réel, et a été repris par d'innombrables créateurs, bien différents.
Ce livre commence par creuser les racines du mythe. Au Moyen Âge, il était suffisamment connu pour que les premières mentions écrites du héros, au détour d'autres ouvrages, ne soient pas expliquées : tous les lecteurs connaissaient la référence, grâce à la tradition orale. Puis Robin des Bois a eu droit à ses propres livres et pièces de théâtre, après le Moyen Âge, et a commencé une carrière médiatique que le cinéma, au XXe siècle, a puissamment relancé. Je rappelle que ce livre ne porte pas sur le personnage historique (qui est sans doute imaginaire) mais sur sa reprise par les créateurs. C'est l'histoire du mythe, pas l'histoire de Robin.
Comme avec tous les mythes, Robin des Bois a été utilisé par de nombreux courants artistiques et politiques. Si le roi Arthur, sujet d'un précédent livre du même auteur, est plutôt « de droite » (après tout, c'est un roi), Robin des Bois, proscrit caché dans la forêt, qui affronte les autorités, serait plutôt « de gauche ». Mais attention, c'est bien plus compliqué que cela et les auteurices du livre montrent que Robin des Bois a été présenté de nombreuses façons différentes, et parfois en allié du roi, ou, au XXe siècle, en libertarien partisan des esclavagistes. De même, Robin a souvent changé de classe sociale, parfois yeoman (paysan propriétaire), parfois noble. Bien des bandits et des rebelles ont été qualifiés de « Robin des Bois moderne » (y compris les plus contestables).
Le livre analyse aussi un certain nombre de points spécifiques : le rôle des femmes dans la légende, Robin des Bois en France, les questions que se posent les médias pour enfants (présenter un voleur comme personnage positif…), l'importance du déguisement dans la légende (et, de manière plus générale, de l'inversion), bref, un livre d'une grande richesse où vous découvrirez plein de choses.
Première rédaction de cet article le 8 juillet 2025
Dernière mise à jour le 15 juillet 2025
J'ai reçu trois messages de menaces d'une société nommée Cloud Innovation, car j'avais relayé un article qui dénonçait, à juste titre, leur rôle dans les attaques contre Afrinic. Je crois utile de rendre publiques ces menaces.
Un peu de contexte : Afrinic est le RIR pour l'Afrique. Le plus petit et le moins riche des RIR, le moins doté en ressources humaines et en appuis politiques, il est aussi le seul à avoir encore beaucoup d'adresses IPv4, ce qui aiguise des convoitises. Une entreprise chinoise, Cloud Innovation (elle utilise d'autres noms comme Larus ou Number Resource Society) a ainsi obtenu des adresses IP via une société-écran aux Seychelles, adresses ensuite utilisées pour des activités sans lien avec l'Afrique. Afrinic a tenté de récupérer au moins une partie de ces adresses, ce à quoi Cloud Innovation a réagi par une série de procès. Afrinic, victime de décisions mal réfléchies de la justice du pays de son siège social, a été privé des moyens de se défendre et est entré, depuis plusieurs années, dans une crise dont on ne voit pas le bout. (Le registre n'a, actuellement, ni directeur, ni conseil d'administration, les dernières élections, en juin 2025, ont été annulées.)
Tout ceci est bien décrit dans un excellent article d'Emmanuel Vitus (en anglais, mais il y a aussi la version en français). Et c'est la cause immédiate des messages que j'ai reçus de Cloud Innovation. J'ai tweeté sur cet article. Je reçois donc, sur une adresse personnelle et une professionnelle, un message en anglais signé de Cloud Innovation, m'enjoignant de « IMMEDIATELY remove and cease and desist from further sharing, disseminating, or promoting the Article through your X (formerly known as Twitter) profile, which disparage Cloud Innovation Limited and its officers, and further invite and open the floodgate for defamatory commentary regarding the same ». (Vous avez le mesage complet ici ; notez qu'il mentionne mon employeur - qu'on trouve facilement en ligne - mais que celui-ci n'y est pou rien.) Et le message me donne 24 heures et se termine par d'autres menaces, citant par exemple un procès en cours au Ghana (pourquoi le Ghana ???). Quelques jours après, un autre message de menace me relance puis un troisième.
J'ai hésité à partager cette information car je craignais d'aider Cloud Innovation dans sa politique d'intimidation (certaines personnes ont cédé mais en relançant publiquement la diffusion de l'information). Mais il me semble qu'il serait pire de ne pas faire connaitre les méthodes de cette entreprise. Comme vous le voyez, je n'ai pas supprimé mon tweet, que j'assume totalement. (Dans des cas comme ceci, il est important d'archiver les articles cités, car il y a toujours un risque d'une action d'effacement. Voici les archives, faites par Seb Sauvage.) D'autres personnes ont fait le même choix de publication, comme Joe Hall (voir aussi son tweet).
(Notez que j'ai cité Wikipédia, comme je le fais souvent sur ce blog, mais ne vous fiez pas à la page Wikipédia sur Afrinic : sans doute modifié par Cloud Innovation, elle - aussi bien en version francophone qu'anglophone - reprend des accusations mensongères contre Afrinic. Le compte à l'origine de ces modifications a d'ailleurs été bloqué.)
Sur ce même sujet, vous pouvez lire :
Date de publication du RFC : Juin 2025
Auteur(s) du RFC : Q. Misell (AS207960)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 27 juin 2025
Le protocole ACME,
normalisé dans le RFC 8555, permet
d'automatiser le processus de création et de renouvellement de
certificats utilisables, par exemple, pour
TLS. L'extension normalisée dans ce nouveau
RFC permet
d'obtenir et de renouveler des certificats pour un service utilisant
le .onion
de
Tor. Si vous voulez passer à la télévision en
disant « j'ai obtenu un certificat pour le Dark Web », ce RFC est la
bonne lecture.
Ces services en
.onion
sont décrits dans
la spécification de
Tor. Le nom .onion
a été enregistré
comme « nom spécial » (RFC 6761) par le RFC 7686. Ces noms en .onion
ne sont pas résolvables via le DNS et on ne peut donc pas utiliser les défis
ACME (RFC 8555, section 8) classiques avec une
AC habituelle.
La norme ACME, le
RFC 8555, définit dans sa section 9.7.7 des
types d'identificateurs. Pour les
.onion
, ce sera le type
dns
, même si Tor
n'utilise pas le DNS. J'aurais préféré que ce type se nomme
domainname
, ça aurait été plus cohérent (voir
l'annexe A du RFC, qui discute ce choix, qui prend place dans un
cadre très embrouillé, avec beaucoup de gens qui confondent noms de
domaine et DNS). L'identificateur est le nom dans
.onion
, éventuellement avec des
sous-domaines. Par exemple, le JSON envoyé par ACME, pour la version en .onion de ce blog,
serait :
{ "type": "dns", "value": "sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion" }
Reste à permettre au serveur ACME (l'AC)
de le valider. Le forum AC/Navigateur permet les
.onion
(annexe B.2 de ses « Baseline
Requirements for the Issuance and Management of Publicly-Trusted
Certificates »). ACME utilise le concept de
défi pour ces validations. Le client ACME
demande un certificat pour un certain identificateur, le serveur lui
renvoie un défi, une tâche à accomplir, du genre « prouve-moi que tu
peux mettre ces données que je t'envoie dans un endroit accessible
en HTTP
via le nom pour lequel tu veux un certificat ». Il existe plusieurs
défis utilisables avec les .onion
:
http-01
(section 8.3 du RFC 8555), notre RFC dit qu'il faut suivre les redirections
HTTP, même si elles mènent à un serveur HTTP qui n'est pas en
.onion
; c'est ce défi que j'ai utilisé pour
mon blog.tls-alpn-01
(RFC 8737).onion-csr-01
, qui, contrairement aux
deux précédents, est spécifique aux .onion
et
normalisé dans ce RFC 9799. C'est aussi le seul des
trois défis utilisables qui permettre des jokers dans
l'identificateur
(*.bbcweb3hytmzhn5d532owbu6oqadra5z3ar726vq5kgwwn6aucdccrad.onion
). Je
le décris en détail plus loin. Cette méthode de validation figure
désormais dans le registre
des types de défis.dns-01
(section 8.4 du RFC 8555), par contre, ne peut pas être
utilisé pour les .onion
, ceux-ci ne se
servant pas du DNS.
Le défi onion-csr-01
consiste à demander au
client de générer une CSR (RFC 2986) signée avec la clé privée du
nom en .onion
(je rappelle qu'un nom en
.onion
est une clé publique, plus exactement
est dérivé d'une clé publique). Pour cela, le serveur ACME envoie un
numnique et sa clé publique
Ed25519, qu'il utilise pour Tor. Le client
doit répondre avec le CSR, signé avec sa clé privée, CSR contenant
parmi ses attributs le numnique choisi par le serveur, et un autre
choisi par le client. Le serveur vérifie alors ce CSR (le nom en
.onion
, et bien sûr la signature).
Notez qu'on peut imaginer une AC qui ne soit elle-même accessible
que via un nom en .onion
, ce qui serait
cohérent (section 5 du RFC). Par contre, en sortie, une AC doit
utiliser Tor pour se connecter aux .onion
(je
veux dire l'utiliser directement, pas en passant par une passerelle,
cf. section 8.8) mais une AC ne doit
pas utiliser Tor pour se connecter à des
domaines non-onion
(section 8.4) car il y a des
nœuds
de sortie méchants.
Et les enregistrements de type CAA, normalisés dans le RFC 8659, et qui augmentent la sécurité du système
en indiquant à quelles AC le client ACME a recours ? On ne peut pas
utiliser le CAA traditionnel puisqu'il dépend du DNS. La solution,
décrite dans la section 6 du RFC, est de mettre cette information
dans le descripteur de service Tor (celui que le serveur en
.onion
envoie aux serveurs d'annuaire Tor).
Passons à la pratique. Il existe une AC
expérimentale (et qui ne prétend pas offrir les
garanties de sécurité d'une « vraie »), par l'auteure du RFC,
documentée sur le site Web du
projet. Je m'en suis servi pour obtenir un certificat pour
mon blog. Vous pouvez donc
désormais vous connecter en HTTPS, à
(votre navigateur va sans doute râler car il ne connait pas cette
AC). Attention, l'AC a enregistré ce certificat via
Certificate Transparency (RFC 9162) et est donc publiquement visible. Ne
demandez pas de certificat à une AC qui utilise Certificate
Transparency si ça vous dérange (section 8.9 du RFC).
https://sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/
Quelle est la marche à suivre pour obtenir un tel certificat ? D'abord, configurer Tor pour accepter le port de HTTPS :
HiddenServiceDir /var/lib/tor/blogv2/ HiddenServicePort 80 127.0.0.1:80 HiddenServicePort 443 127.0.0.1:443
Ensuite, configurer son serveur HTTP, Apache dans mon cas :
# Pour le client ACME (qui écoutera sur le port 8080) : ProxyPass /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge ProxyPassReverse /.well-known/acme-challenge http://localhost:8080/.well-known/acme-challenge ProxyPreserveHost on # Ne pas oublier d'activer mod_proxy *et* mod_proxy_http. # HTTPS : <VirtualHost _default_:443> ServerName sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion # Liens symboliques vers les certificats obtenus par ACME, dans mon # cas /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/… SSLCertificateFile /etc/apache2/server.pem SSLCertificateKeyFile /etc/apache2/server.key
On lance ensuite le client ACME. J'ai utilisé certbot :
% sudo certbot certonly -v --server https://acme.api.acmeforonions.org/directory \ --standalone --http-01-port 8080 --http-01-address 127.0.0.1 \ -d sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion … Performing the following challenges: http-01 challenge for sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion Waiting for verification... Cleaning up challenges Successfully received certificate. Certificate is saved at: /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/fullchain.pem Key is saved at: /etc/letsencrypt/live/sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion/privkey.pem This certificate expires on 2025-05-28. …
(Et pensez à configurer le renouvellement automatique du certificat, normalement, certbot l'a fait tout seul, mais vérifiez.)
Un tcpdump montre le trafic échangé entre Apache (qui a reçu le défi de l'AC, via Tor) et certbot (qui avait envoyé la demande et stocké le défi du serveur ACME), sur ma machine :
127.0.0.1.60978 > 127.0.0.1.8080: Flags [P.] … HTTP, length: 376 GET /.well-known/acme-challenge/G4JwaWsRDG42H_FAESGCQrY7ZYk3D3mY9Ob_j458z6M HTTP/1.1 Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion X-Forwarded-For: 127.0.0.1 X-Forwarded-Host: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion X-Forwarded-Server: sjnrk23rmcl4ie5atmz664v7o7k5nkk4jh7mm6lor2n4hxz2tos3eyid.onion 127.0.0.1.8080 > 127.0.0.1.60978: Flags [P.] … HTTP, length: 92 HTTP/1.0 200 OK Server: BaseHTTP/0.6 Python/3.11.2 Date: Thu, 27 Feb 2025 17:04:53 GMT
Si vous voulez ajouter cette AC (mais rappelez-vous qu'elle est
expérimentale et sans garanties de sécurité) au Tor
Browser, vous devrez sans doute, dans
about:config
, configurer,
avant d'importer l'AC :
security.nocertdb false browser.privatebrowsing.autostart false security.ssl.enable_ocsp_stapling false
Mais je répète mon avertissement : cela peut affecter votre vie privée. Ne le faites pas si vous ne comprenez pas en détail les conséquences.
J'ai utilisé le défi http-01
, avec un
certbot ordinaire. Le défi onion-01
nécessite
un certbot modifié (du code est disponible).
Petite anecdote : l'auteure du RFC travaille pour l'AS 207960, dont l'objet RIPE annonce :
aut-num: AS207960 as-name: AS-TRANSRIGHTS descr: Trans Rights! Hell Yeah!
Et le site Web montre d'ailleurs le drapeau correspondant. Il est assez rare de voir des prises de position politiques dans la base des RIR.
Date de publication du RFC : Juin 2025
Auteur(s) du RFC : A. Gable (Internet Security Research
Group)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF acme
Première rédaction de cet article le 18 juin 2025
Si vous utilisez Let's Encrypt (et tout le monde l'utilise, de nos jours), vous avez sans doute reçu les messages « Let's Encrypt Expiration Emails Update » qui vous préviennent que cette AC n'enverra plus de rappels que vos certificats vont bientôt expirer. C'est parce qu'un meilleur système est maintenant disponible, ARI (ACME Renewal Information). ARI permet à une AC utilisant le protocole ACME d'indiquer à ses clients des suggestions sur le renouvellement des certificats. Il est décrit dans ce RFC.
ACME est normalisé dans le RFC 8555 et est surtout connu via le succès de Let's Encrypt. Les certificats sont de courte durée (aujourd'hui trois mois mais ça va diminuer) et il faut donc les renouveler souvent. On peut le faire automatiquement via cron, ou bien analyser le certificat et renouveler quand sa date d'expiration approche. L'un des problèmes est que cela peut mener à ce que plusieurs demandes de renouvellement arrivent en même temps sur l'AC. Le pic d'activité qui en résulterait pourrait charger l'AC inutilement. L'idée est donc que ce soit le serveur ACME, l'AC, qui planifie les renouvellements, et pas le client ACME. Cela permettrait aussi des changements de planning, comme une réduction des durées de validité, ou bien une révocation.
Donc, ARI ajoute un nouvel URL à la description d'une AC,
renewalInfo
. Voici celui de Let's Encrypt (qui
met
en œuvre ARI depuis deux ans) :
% curl https://acme-v02.api.letsencrypt.org/directory { "keyChange": "https://acme-v02.api.letsencrypt.org/acme/key-change", "meta": { "caaIdentities": [ "letsencrypt.org" ], "profiles": { … }, "termsOfService": "https://letsencrypt.org/documents/LE-SA-v1.5-February-24-2025.pdf", … }, "newAccount": "https://acme-v02.api.letsencrypt.org/acme/new-acct", "newNonce": "https://acme-v02.api.letsencrypt.org/acme/new-nonce", "newOrder": "https://acme-v02.api.letsencrypt.org/acme/new-order", "renewalInfo": "https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo", "revokeCert": "https://acme-v02.api.letsencrypt.org/acme/revoke-cert"
Ce nouveau membre a été ajouté au registre IANA.
Et comment on obtient quelque chose à cet URL
https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo
?
On doit passer un identificateur du certificat. Il est formé par la
concaténation de l'identifiant de l'AC et du numéro de série du
certificat (pour garantir qu'il soit unique). Je passe sur les
détails de construction (lisez la section 4 du RFC pour cela) mais
ce petit script Python
vous fait le
calcul. Utilisons-le sur l'actuel certificat de ce blog :
ari-make-path.py
% openssl x509 -text -in cert.pem [Notez les valeurs] % python ari-make-path.py 93:27:46:98:03:A9:51:68:8E:98:D6:C4:42:48:DB:23:BF:58:94:D2 00:06:7d:03:91:c6:49:b8:83:ba:e5:c6:da:8a:dc:be:4d:33:78 kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA % curl -i https://acme-v02.api.letsencrypt.org/draft-ietf-acme-ari-03/renewalInfo/kydGmAOpUWiOmNbEQkjbI79YlNI.AAZ9A5HGSbiDuuXG2orcvk0zeA … retry-after: 21600 … { "suggestedWindow": { "start": "2025-06-23T03:50:00Z", "end": "2025-06-24T23:00:50Z" } }
Voilà, on a fait un URL en concaténant la valeur de
renewalInfo
avec celle obtenue à partir du
certificat et on sait désormais quand est-ce que Let's Encrypt
suggère de renouveler ce certificat. Le format de sortie est clair
mais vous avez les détails dans la section 4.2. Les dates sont
évidemment au format du RFC 3339. Au passage,
la date d'expiration est le 24 juillet 2025 donc Let's Encrypt
n'attend pas le dernier moment. (Comme le dit un commentaire dans le
code source du serveur, « calculate a point 2/3rds of the
way through the validity period (or halfway through, for short-lived
certs) ».)
Le RFC précise qu'un membre explanationURL
peut être ajouté mais Let's Encrypt ne le fait pas. Les membres
possibles figurent dans un
nouveau registre IANA, auquel on pourra ajouter de nouveaux
membres, en fournissant une spécification (« Spécification
nécessaire » du RFC 8126).
Et on utilise cet intervalle entre deux dates comment ? Le RFC
recommande de choisir une date au hasard dans l'intervalle. Le
client ACME ne doit pas dormir jusqu'à la date sélectionnée, il doit
réessayer de temps en temps car l'AC a pu changer la date (c'est
tout le principe d'ARI). Mais attention à respecter le
Retry-After:
(six heures, ici), cf. RFC 9110, section 10.2.3.
Notre RFC ajoute également un membre à la description d'une
commande de certificat : replaces
indique quel
certificat on est censé remplacer. (En utilisant le même
identificateur de certificat qu'indiqué plus haut.) Il a été ajouté
au
registre IANA.
ARI est mis en œuvre dans le serveur ACME de Let's Encrypt, Boulder. Regardez
core/objects.go
et notamment la fonction
RenewalInfoSimple
. Côté client, Lego, acmez et le CertMagic
de Caddy ont ARI mais
certbot ou dehydrated
ne gèrent pas ARI. Si vous voulez vous y mettre, Let's Encrypt a
écrit un guide
d'intégration d'ARI.
Date de publication du RFC : Juin 2025
Auteur(s) du RFC : K. Smith (Vodafone)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF httpapi
Première rédaction de cet article le 14 juin 2025
Les API réseau, c'est très bien. Tout le monde en fait aujourd'hui, typiquement bâties au-dessus de HTTP. Mais il est parfois difficile de s'y retrouver parmi toutes les API. « Je suis sûr que l'INSEE avait une API pour faire ça mais où est-elle exactement et où est sa documentation ? La solution pour cela ? Les catalogues d'API, rassemblant nom, description, URL, etc, des API. Il ne reste plus qu'à trouver le catalogue… Ce RFC fournit pour cela un URL standard et un mécanisme de lien. Il fournit également un format standard pour écrire ce catalogue, bâti sur Linkset (RFC 9264, section 4.2).
Comme disait M. de la Palice, et comme le rappelle la section 1 du RFC, pour utiliser une API, il faut d'abord la découvrir. Cela veut dire apprendre son existence, quel va être l'URL à appeler (le endpoint), les paramètres à passer, quelles sont les conditions d'utilisation (gratuite ? nombre maximal de requêtes par jour ?), etc. Il existe des formats pour cela (le plus connu étant celui d'OpenAPI) mais il reste à trouver les fichiers de ce format. Pour faciliter cette tâche du développeur ou de la développeuse qui utilisera l'API, l'éditeur (publisher dans le RFC) qui publie l'API va fabriquer un joli catalogue, et le rendre lui-même découvrable. Un catalogue est une liste organisée des API offertes par une organisation donnée.
Première solution décrite par notre RFC (section 2) : un URL bien
connu, et donc prévisible,
https://www.example.net/.well-known/api-catalog
(si l'éditeur est en www.example.net
). Ces URL
bien connus sont normalisés dans le RFC 8615. Évidemment, une redirection HTTP est
possible. api-catalog
a été ajouté au registre
des URL bien connus.
Deuxième solution, un lien (section 3)
api-catalog
. Les liens, vous connaissez, et ils
sont normalisés dans le RFC 8288. Ils peuvent
se représenter de plusieurs façons, en HTML :
<!DOCTYPE HTML> <html> <head> <title>Welcome to Example Publisher</title> </head> <body> <p> <a href="my_api_catalog.json" rel="api-catalog"> Example Publisher's APIs </a> </p> <p>(remainder of content)</p> </body> </html>
Ou bien en HTTP, dans la réponse :
HTTP/1.1 200 OK Content-Type: text/html; charset=UTF-8 Location: /index.html Link: </my_api_catalog.json>; rel=api-catalog Content-Length: 356
Désormais, api-catalog
figure dans le registre
des types de liens.
Cette norme concerne la découverte du catalogue, mais aussi la syntaxe de son contenu. La section 4 du RFC donne des indications sur le contenu du catalogue, sa sémantique (inclure la politique d'utilisation, lien vers une spécification formelle, etc) et sa syntaxe, le format Linkset du RFC 9264. Des exemples figurent dans l'annexe A du RFC mais vous pouvez aussi regarder le catalogue des mes API (en construction). Voici le premier exemple de catalogue donné dans le RFC, utilisant les relations du RFC 8631 :
{ "linkset": [ { "anchor": "https://developer.example.com/apis/foo_api", "service-desc": [ { "href": "https://developer.example.com/apis/foo_api/spec", "type": "application/yaml" } ], "service-doc": [ { "href": "https://developer.example.com/apis/foo_api/doc", "type": "text/html" } ], "service-meta": [ { "href": "https://developer.example.com/apis/foo_api/policies", "type": "text/xml" } ] }, { "anchor": "https://developer.example.com/apis/bar_api", "service-desc": [ { "href": "https://developer.example.com/apis/bar_api/spec", "type": "application/yaml" } ], "service-doc": [ { "href": "https://developer.example.com/apis/bar_api/doc", "type": "text/plain" } ] } ] }
D'autres formats que Linkset sont possibles (mais Linkset doit être présent), par exemple via la négociation de contenu. Quelques formats possibles cités par le RFC :
Ce catalogue peut, et ce serait souhaitable, être écrit automatiquement par le cadriciel qu'on utilise pour développer ses API.
Et, sinon, où est-ce qu'on publie cette API ? La méthode
recommandée (section 5) est de la publier à plusieurs endroits. Si
on gère www.example.net
et que les URL des API
sont en api.example.com
, le RFC recommande de
les publier aux deux endroits. Rappelez-vous que les redirections
HTTP sont permises, donc vous pouvez n'avoir qu'un seul exemplaire
du catalogue, ce qui simplifie sa maintenance. Car, puisqu'on parle
de maintenance, un gros défi sera clairement de garder ce catalogue
à jour au fur et à mesure de l'évolution des API… (La section 8, sur
la sécurité, revient sur ce problème.)
Je n'ai pas trouvé d'exemple réel dans le Web, même chez
Vodafone, où travaille l'auteur. Mais j'ai fait un catalogue pour mes propres
API. En l'absence d'outils de test et de validation pour les
catalogues, il a peut-être quelques erreurs. (Si vous lisez la
section 2 du RFC, vous verrez que mon serveur HTTP ne répond pas aux
requêtes HEAD avec un lien dans
l'en-tête, un Link:
. Il devrait.)
Date de publication du RFC : Juin 2025
Auteur(s) du RFC : F. Driscoll, M. Parsons (UK National
Cyber Security Centre), B. Hale (Naval Postgraduate School)
Pour information
Réalisé dans le cadre du groupe de travail IETF pquip
Première rédaction de cet article le 14 juin 2025
La cryptographie post-quantique vise à développer des algorithmes de cryptographie qui résistent à des ordinateurs quantiques. Mais ces algorithmes sont relativement récents et peuvent avoir des faiblesses, voire des failles, que la cryptanalyse classique pourra exploiter. La tendance actuelle est donc aux protocoles et formats hybrides, combinant algorithmes classiques et post-quantiques. Ce RFC spécifie la terminologie de ces protocoles hybrides.
On peut aussi dire AQ, pour après-quantique car le sigle anglophone PQ de post-quantum peut faire drôle en France. D'ailleurs, les termes à utiliser (post-quantique ? résistant au quantique ?) ont fait l'objet de chaudes discussions dans le groupe de travail IETF.
Le point de départ de tout le tintouin autour de l'après-quantique, c'est l'algorithme de Shor. Conçu pour les calculateurs quantiques, et donc inutilisable encore aujourd'hui, il permet de résoudre des problèmes mathématiques qu'on croyait difficiles, comme la décomposition en facteurs premiers (qui est derrière RSA) ou le logarithme discret (qui est derrière ECDSA). Le jour, qui n'est pas encore arrivé, où on aura des CRQC (Cryptographically-Relevant Quantum Computer, un calculateur quantique qui puisse s'attaquer à des problèmes de taille réelle, et pas juste faire des démonstrations), ce jour-là, la cryptographie classique, ou traditionnelle, aura un problème.
Les CRQC sont loin dans le futur, un lointain dont il est très difficile d'estimer la distance. Comme on ne sait pas quand les CRQC seront disponibles, et que certains secrets qu'on chiffre maintenant devront rester secrets pendant de nombreuses années, il est prudent de travailler dès maintenant aux algorithmes AQ, après-quantique, ceux pour lesquels on ne connait pas d'algorithme (quantique ou classique) pour les casser. Ce travail a effectivement commencé depuis des années et on a déjà des algorithmes AQ normalisés comme ML-KEM (ex-Kyber). Notez toutefois qu'aucune norme IETF n'a encore été publiée en intégrant ces algorithmes, mais le travail est en cours, entre autres au sein du groupe de travail pquip.
Mais remplacer complètement les algorithmes traditionnels par les
algorithmes AQ n'est pas forcément satisfaisant. Au contraire de
RSA et
ECDSA, testés au feu depuis longtemps et qui
ont toujours résisté, les algorithmes AQ peuvent sembler un peu
jeunes. Que se passerait-il si un·e
cryptanalyste cassait un de ces algorithmes ?
Pour limiter les dégâts, on envisage d'utiliser des mécanismes
hybrides, combinant cryptographie classique
(pré-quantique) et après-quantique. Ainsi, un chiffrement hybride
verrait le texte en clair chiffré par un mécanisme classique puis
par un mécanisme après-quantique. Une signature hybride se ferait en
mettant deux signatures et en vérifiant ensuite que les deux sont
valides. Cette méthode « ceinture et bretelles » est utilisée par
exemple dans le RFC 9370 ou dans les
Internet-Drafts
draft-ietf-tls-hybrid-design
,
draft-ietf-lamps-pq-composite-kem
ou draft-ietf-lamps-cert-binding-for-multi-auth
. On
peut aussi consulter la FAQ
du NIST (« A hybrid key-establishment mode is
defined here to be a key establishment scheme that is a combination
of two or more components that are themselves cryptographic
key-establishment schemes. ») ou bien le document
ETSI TS 103 744 nommé « Quantum-safe Hybrid Key
Exchanges ». Attention toutefois avec
cette terminologie car l'adjectif « hybride » est également souvent
utilisé en cryptographie pour désigner la combinaison d'un
algorithme de cryptographie asymétrique avec
un algorithme de cryptographie symétrique
(quand on crée une clé de session échangée via de la cryptographie
asymétrique puis qu'on chiffre les données avec cette clé et de la
cryptographie symétrique ; c'est ce que font TLS et
OpenPGP, par exemple). C'est le sens
qu'utilisent les RFC 4949 et RFC 9180, par exemple. Notre RFC 9794 note que
ces deux usages du terme « hybride » vont certainement prêter à
confusion mais qu'il n'y avait pas trop le choix : chaque usage
était déjà solidement installé dans un milieu particulier. Essayer
de promouvoir un autre terme pour la cryptographie après-quantique,
comme « double algorithme » ou « multi algorithme » était sans doute
voué à l'échec.
Passons maintenant aux définitions. Je ne vais pas les reprendre toutes mais donner quelques exemples. La section 2 du RFC commence par les mécanismes de base et d'abord, mécanisme hybride traditionnel / post-quantique (post-quantum traditional hybrid scheme, ou PQ/T), un mécanisme qui combine la cryptographie existante et celle du futur. On peut aussi simplifier en disant juste mécanisme hybride. Il y a aussi :
Ensuite, on grimpe d'un niveau (section 3 du RFC), avec les
éléments, qui sont les données en entrée ou en sortie d'un processus
cryptographique. Quand on dit « l'algorithme X prend en entrée un
texte en clair et une clé secrète et produit un texte chiffré », le
texte en clair, la clé et le texte chiffré sont des éléments. Dans
le mécanisme hybride décrit dans draft-ietf-tls-hybrid-design
,
il y a deux clés publiques, qui sont deux éléments. Un élément peut
à son tour être composé de plusieurs éléments.
On peut maintenant utiliser tout cela pour faire des protocoles
(section 4). Un protocole hybride PQ/T est, comme vous vous en
doutez, un protocole qui utilise au moins deux algorithmes, un
classique et un après-quantique. C'est ce qui est proposé dans
draft-ietf-tls-hybrid-design
. Ce
dernier est même composé (dans le mécanisme de désignation de la
clé, le KEM). Alors que le mécanisme du RFC 9370 est hybride mais pas composé (on fait un échange de
clés classique et un KEM après-quantique).
Les noms des services de sécurité qu'on souhaite utiliser vont de soi (section 5) : confidentialité hybride PQ/T (confidentialité assurée par un mécanisme hybride traditionnel/après-quantique) et authentification hybride PQ/T.
Idem pour les certificats (section 6). Un
« certificat hybride PQ/T » contient au moins deux clés publiques,
une pour un algorithme traditionnel et une pour un algorithme
après-quantique (alors que le certificat traditionnel et le
certificat après-quantique ne contiennent qu'un seul type de clé
publique, comme c'est le cas du certificat décrit dans
draft-ietf-lamps-dilithium-certificates
).
Et merci à Magali Bardet pour sa relecture mais, bien sûr, les erreurs sont de moi et moi seul.
Date de publication du RFC : Juin 2025
Auteur(s) du RFC : G. Brown (ICANN)
Chemin des normes
Réalisé dans le cadre du groupe de travail IETF regext
Première rédaction de cet article le 14 juin 2025
Traditionnellement, les registres de noms de domaine publiaient toutes les informations des sous-domaines avec la même durée de vie maximale (TTL : Time To Live). Certain·es client·es demandent à pouvoir choisir un TTL plus court (ou, parfois, plus long) et ce RFC décrit comment faire cela avec le protocole EPP.
Cet EPP, normalisé dans les RFC 5730 et suivants, est aujourd'hui le plus utilisé par les
gros registres pour recevoir les commandes de
leurs BE. (Cf. cet
article de l'Afnic.) Tel que normalisé dans le RFC 5731, EPP ne permet pas, lors de la création
d'un nom de domaine, de spécifier le
TTL des
enregistrements NS
(NameServer) qui seront publiés. Prenons
l'exemple de l'enregistrement d'un
.fr
. Le ou la titulaire
va sur l'interface Web de son BE, réserve le nom
cyberstructure.fr
, le BE transmet la demande de
création en utilisant EPP et le registre publie ensuite dans le
DNS les
informations de délégation, ici récupérées avec dig :
% dig @d.nic.fr cyberstructure.fr NS … ;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1 … ;; AUTHORITY SECTION: cyberstructure.fr. 3600 IN NS puck.nether.net. cyberstructure.fr. 3600 IN NS fns2.42.pl. cyberstructure.fr. 3600 IN NS ns2.bortzmeyer.org. cyberstructure.fr. 3600 IN NS ns4.bortzmeyer.org. cyberstructure.fr. 3600 IN NS ns2.afraid.org. cyberstructure.fr. 3600 IN NS fns1.42.pl. cyberstructure.fr. 3600 IN NS ns1.bortzmeyer.org. …
À aucun moment, la·e titulaire ou le BE n'a spécifié de TTL (les 3 600 secondes), il a été choisi par le registre seul. Certain·es titulaires peuvent pourtant avoir des préférences différentes. (Je rappelle que la notion de TTL est définie rigoureusement dans le RFC de terminologie DNS, le RFC 9499, voir sa section 5.)
Si vous voulez creuser ce concept de délégation, l'article de l'Afnic sur DELEG l'explique dans sa première partie.
L'exemple ci-dessus montrait les enregistrements NS (NameServer) mais ce problème concerne aussi les DS (RFC 9364), la colle et les éventuels DNAME (par exemple pour mettre en œuvre le RFC 6927).
Ce RFC normalise une extension à EPP pour permettre au client (le BE) d'indiquer le TTL souhaité pour la délégation. (Ce qui ne signifie pas que le registre satisfera ce souhait, lisez plus loin.) Plus précisément, il étend les classes (mappings) EPP pour les noms de domaine (RFC 5731) et pour les serveurs de noms (RFC 5732), les seules classes dont les données se retrouveront dans le DNS (rappelez-vous qu'EPP n'est pas limité aux noms de domaine, c'est un protocole d'avitaillement générique).
La section 1.2 du RFC contient les informations
essentielles. D'abord, l'espace de noms
urn:ietf:params:xml:ns:epp:ttl-1.0
(enregistré
à
l'IANA), qui identifie cette extension (le RFC utilise
l'alias ttl
mais rappelez-vous qu'en XML, c'est l'espace de
noms qui compte, l'alias est choisi par l'auteur du document
XML). Ensuite, l'élément <ttl:ttl>
(donc,
en complet,
{urn:ietf:params:xml:ns:epp:ttl-1.0}ttl
), qui
peut être ajouté aux demandes EPP ou aux réponses. Parmi ses
attributs :
for
(le seul qui soit obligatoire)
indique le type de données DNS auxquelles l'élément s'applique
(uniquement des types qui jouent un rôle dans la délégation, NS, DS, DNAME,
A et AAAA, ainsi que la valeur spéciale
custom
, qu'il faut compléter avec un attribut
custom
qui suit l'expression
rationnelle de la section 3.1 du RFC 6895, et évidemment utilise un type
enregistré),min
(uniquement dans les réponses) qui
indique la valeur minimale que le serveur (donc le registre)
accepte (le registre est toujours libre de sa politique et peut
refuser une valeur trop basse ou trop haute, répondant avec le
code d'erreur EPP 2004, Parameter value range error),max
, la contrepartie de
min
, avec les mêmes propriétés,default
, qu'on ne trouve également que
dans les réponses, et qui permet de connaitre la valeur
qu'utiliserait le serveur si le client ne demande rien de spécifique.
L'élément <ttl:ttl>
a pour contenu une
valeur en secondes. Si cette valeur est vide, le serveur prendra la
valeur par défaut (mais autant ne pas mettre d'élément
<ttl:ttl>
dans ce cas).
L'extension de ce RFC décrit des possibilités mais le registre,
qui gère le serveur EPP, reste libre de ne pas tout accepter. Par
exemple, il peut refuser l'utilisation de l'attribut
custom
, ou bien la restreindre à certains types
(et, si le client demande quand même, répondre avec le code d'erreur
EPP 2306 Parameter value policy error). Les types
qui ont une syntaxe privilégiée (pas besoin de l'attribut XML
custom
) sont ceux qu'on peut actuellement
trouver au-dessus de la coupure de zone (section 7 du RFC 9499).
Vous avez noté que, dans les types qui ont une syntaxe privilégiée dans ce RFC, il y a les types pour les adresses IP. Ils sont utilisés pour la colle DNS (section 7 du RFC 9499), si le serveur EPP met en œuvre la classe EPP pour les serveurs de noms (RFC 5732).
Un deuxième élément XML est spécifié par ce RFC,
<ttl:info>
, qui sert à demander ou à
indiquer des informations sur la politique du serveur (voir des
exemples plus loin).
La section 2 décrit dans quelles commandes EPP on peut ajouter
les nouveaux éléments. Je ne vais pas toutes les détailler, juste
montrer quelques exemples du XML envoyé et des réponses. Ainsi, ici, le
client va utiliser la commande <epp:info>
pour se renseigner sur la politique du serveur :
… C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: </domain:info> C: </info> C: <extension> C: <ttl:info C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0" C: policy="false"/> C: </extension> …
Et la réponse du serveur :
… S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> … S: <domain:name>example.com</domain:name> S: <domain:status s="ok"/> … S: </resData> S: <extension> S: <ttl:infData S: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> S: <ttl:ttl for="NS">172800</ttl:ttl> S: <ttl:ttl for="DS">300</ttl:ttl> S: </ttl:infData> … S: </response> …
Le serveur indique que le TTL des enregistrements NS sera
de deux jours. Sinon, vous avez repéré le
policy="false"
? S'il avait été à
true
, le serveur aurait renvoyé l'information
sur sa politique pour tous les types d'enregistrements DNS
(section 2.1.1.2).
Créons maintenant un nom de domaine en spécifiant un TTL :
C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>example.com</domain:name> C: <domain:ns> C: <domain:hostObj>ns1.example.com</domain:hostObj> C: <domain:hostObj>ns1.example.net</domain:hostObj> C: </domain:ns> C: </domain:create> C: </create> C: <extension> C: <ttl:create C: xmlns:ttl="urn:ietf:params:xml:ns:epp:ttl-1.0"> C: <ttl:ttl for="NS">172800</ttl:ttl> C: <ttl:ttl for="DS">300</ttl:ttl> C: </ttl:create> C: </extension> C: </command> C: </epp>
Cela marcherait aussi dans un
<domain:update>
, pour changer les TTL.
Je l'ai déjà dit plusieurs fois, la demande du client ne va pas
forcément être honorée par le serveur. La section 3 de notre RFC
détaille l'interaction entre cette demande et la politique du
serveur (donc du registre). Ainsi, le serveur peut limiter les types d'enregistrement DNS auxquels
ces commandes s'appliquent, par exemple en n'acceptant de changer
le TTL que pour les DS (d'où l'intérêt des demandes avec
policy=…
, pour savoir à l'avance).
D'autre part, le TTL des enregistrements publiés peut changer en dehors d'EPP, par une action du registre. Auquel cas, le registre (section 4) peut gentiment prévenir ses clients par le système de messagerie du RFC 8590.
La possibilité pour le client d'indiquer un TTL souhaité a aussi des conséquences opérationnelle (section 5). Ainsi, des TTL courts vont accroitre la charge sur les serveurs faisant autorité puisque les résolveurs auront besoin de demander plus souvent, les expirations se rapprochant. Souvent, les utilisateurs veulent des TTL courts, pour la réactivité, et n'ont pas conscience des conséquences, notamment en terme d'accroissement du trafic, d'autant plus que l'utilisation des serveurs DNS faisant autorité est gratuite pour eux. C'est pour cela que le registre peut fixer des valeurs minimales (et maximales, pour traiter d'autres problèmes) aux TTL souhaités par le client.
Une erreur parfois commise est de penser qu'un changement du TTL
(via une commande EPP <epp:update>
) va se
voir instantanément. Mais, en fait, les informations, avec l'ancien
TTL, sont encore dans la mémoire de plusieurs résolveurs. Il est
donc recommandé de planifier les changements à
l'avance, en tenant compte de cette mémorisation (section 5.2 du
RFC). D'ailleurs, la politique du registre aussi peut changer, et
les TTL par défaut, ainsi que les valeurs maximales et minimales,
sont susceptibles d'être modifiées (un registre sérieux va informer
ses utilisateurices de ces changements mais parfois, c'est
oublié).
Un gros morceau de notre RFC est consacré à la sécurité (section 6) car les TTL ont une influence sur ce sujet. Premièrement, le fast flux (changement rapide des données de délégation DNS, cf. RFC 9499, section 7). Des malveillants utilisent cette technique pour rendre l'investigation numérique plus difficile et pour échapper à certaines règles de filtrage (voir le rapport SAC-025 du SAAC). Un TTL court peut faciliter ce changement rapide. Le rapport du SAAC suggère un TTL minimum de 30 minutes et/ou de limiter le nombre de changements qu'on peut faire par jour.
Si un malveillant réussit à obtenir les secrets qui lui permettent de soumettre des demandes de modification (au passage, pensez à activer l'authentification à plusieurs facteurs), il mettra sans doute des TTL très élevés pour que son détournement dure plus longtemps. D'où l'intérêt d'une valeur maximale pour les TTL.
Notre extension à EPP pour les TTL figure désormais dans le registre IANA des extensions et sa syntaxe complète, si vous êtes curieux·se, figure dans la section 8 (au format des schémas XML). Question mises en œuvre, vous en trouverez au moins deux, dans le SDK de Verisign et dans le logiciel Pepper (plus exactement dans la bibliothèque qu'il utilise, Net::EPP).
Première rédaction de cet article le 11 juin 2025
Le dispositif de censure de l'Internet en Chine comprend de nombreux composants. L'un d'eux est une injection de fausses réponses DNS par des équipements réseau (et pas, comme c'est courant en Europe, par un résolveur menteur). Comme tout logiciel, il a des bogues, et même des bogues menant à des failles de sécurité. C'est le cas de Wallbleed, une intéressante bogue, étudiée dans un article détaillé. Cette bogue permet d'observer plusieurs choses sur le système de censure chinois, par exemple ses pratiques de correction des bogues.
Prenons l'article dans l'ordre et sautons l'avertissement éthique ajouté par les organisateurs de la conférence NDSS (nous y reviendrons plus tard). D'abord, un petit rappel sur le fonctionnement du GFW, le Great Firewall of China. En dépit de ce que pourrait faire croire ce terme journalistique, il n'y a pas un dispositif unifié mais un ensemble de dispositifs visant à empêcher le citoyen de base de s'informer ou de témoigner. C'est techniquement très efficace : si un des dispositifs est contournable, les autres pourront quand même censurer. Un de ces dispositifs est la génération de fausses réponses DNS. Rien à voir avec les résolveurs menteurs. Ici, la fausse réponse est générée par un équipement du réseau qui, observant une requête DNS pour un nom censuré, envoie une réponse mensongère, avant celle du vrai serveur. Pas besoin d'aller en Chine pour tester ce dispositif, il suffit d'écrire à une adresse IP située en Chine, même si elle n'a pas de serveur DNS actif (puisque la réponse est fabriquée par le réseau). Essayons un nom non censuré, puis un nom censuré :
% dig @113.113.113.113 coca-cola.com ;; communications error to 113.113.113.113#53: timed out … ;; no servers could be reached % dig @113.113.113.113 rsf.org ; <<>> DiG 9.18.30-0ubuntu0.24.04.2-Ubuntu <<>> @113.113.113.113 rsf.org … ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10926 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1 … ;; ANSWER SECTION: rsf.org. 73 IN A 108.160.162.98 ;; Query time: 209 msec ;; SERVER: 113.113.113.113#53(113.113.113.113) (UDP) ;; WHEN: Wed Jun 11 10:38:28 CEST 2025 ;; MSG SIZE rcvd: 52
On le voit, bien qu'aucun serveur DNS n'existe sur
113.113.113.113
(qui est chez
China Telecom), la censure a fabriqué une fausse
réponse pour rsf.org
(l'adresse IP renvoyée,
qui est chez Dropbox, n'a
aucun rapport avec RSF et ne répond pas).
C'est dans le code de la machine qui génère cette fausse réponse
que se situe la bogue Wallbleed. Pour la comprendre, un petit mot
sur le format des paquets DNS (vous avez tous les détails dans le
RFC 1034, section 3.1 et le RFC 1035, section 4.1). Les noms de domaine dans le paquet ne sont
pas représentés avec des points mais sous la forme d'un
octet indiquant la taille du composant qui
suit. rsf.org
va être représenté par {3, r, s,
f, 3, o, r, g, 0}. La forme texte n'est que pour les
humains. Conséquences pratiques : on peut mettre des points
ou bien l'octet nul dans un nom de domaine, et c'est là-dessus que
repose l'exploitation de la faille. (Il y a d'autres pièges dans
l'analyse d'un paquet DNS, comme le fait que le nombre d'entrées
dans chaque section peut être différent de la valeur indiquée dans
l'en-tête DNS. Faites attention si vous écrivez du code. Les
sections 3 et 4 du RFC 9267 détaillaient déjà
des failles analogues à Wallbleed. Si un programme comme Drink a de nombreux
tests d'analyse du paquet, ce n'est pas pour rien.)
Car les auteurs du dispositif de censure n'ont pas lu le RFC 9267. Comme le montre les expériences des
auteurs de l'article, leur logiciel commence par traduire la forme
binaire du nom de domaine en texte, puis la teste contre les noms
censurés, apparemment stockés sous forme d'une expression
rationnelle (l'article explique bien comment les
chercheurs ont découvert cela). Si on envoie un nom écrit sous la
forme {3, r, s, f, 4, o, r, g, 0, 120…}, il va être traduit sous
forme d'une chaine de caractères
rsf.org\000…
, interprétée par le programme
comme étant rsf.org
(le caractère nul étant
pris comme la fin de la chaine dans leur programme, apparemment
écrit en C) et va donc
déclencher la génération de la réponse mensongère. Le programme va
alors copier le nom demandé dans la réponse mais, pour cela, il se
fiera à la longueur du nom en binaire, plus de 120 caractères
(l'octet indiquant une longueur 120, mis par le client, donc
l'attaquant). Et il copiera donc dans la réponse bien plus d'octets
qu'il n'y en avait dans rsf.org
, prenant ces
octets dans sa mémoire et faisant ainsi fuiter ce qu'elle
contenait. Le nom de la faille fait évidemment référence à
Heartbleed, qui permettait également de
récupérer des informations contenues dans la mémoire du serveur
bogué. Si vous êtes programmeuse ou programmeur en C, l'article contient d'ailleurs une
mise en œuvre du système de réponse, avec sa bogue, écrite par
rétro-ingénierie, et qui permet de bien voir
le problème.
Une fois cette faille découverte, les auteurs ont pu étudier plein de choses intéressantes. Par exemple, le fait que toutes les requêtes DNS passant par la Chine n'étaient pas vulnérables, cela dépendait du chemin suivi. Il y a donc apparemment plusieurs mises en œuvre du dispositif de censure par réponses DNS mensongères et toutes n'avaient pas la faille. De même, les auteurs ont pu étudier la correction de la bogue, en continuant à envoyer des paquets truqués : les responsables de la censure ont détecté la faille, et l'ont corrigé (en deux fois, la première correction ayant été insuffisante). À noter que certains réseaux chinois ont gardé la version boguée pendant plus longtemps, montrant que l'administration du dispositif de censure n'est pas centralisée.
Autre étude, qu'il y avait-il dans la mémoire de la machine de censure ? Apparemment du trafic réseau sans lien avec le DNS, indiquant que la machine de censure observait tout.
Cette étude est passionnante mais soulève plusieurs questions éthiques, que l'article détaille :
On l'a dit, ces questions éthiques ont mené à l'ajout dans l'article d'un avertissement très long (et qu'on voit très rarement dans ce genre d'articles), mis par les organisateurs de la conférence où la faille était publiée. Personnellement, je trouve que les auteurs de l'article ont très bien traité les problèmes éthiques et que ces organisateurs exagéraient beaucoup :
Auteur(s) du livre : Pascal Froissart
Éditeur : PUF
978-2-13-084728-1
Publié en 2024
Première rédaction de cet article le 11 juin 2025
C'est un passionnant livre d'histoire de la communication et des médias que le résultat de la recherche menée par l'auteur sur la rubrique « La clinique des rumeurs », publiée par le Boston Herald pendant la Deuxième Guerre mondiale. Ce premier essai de fact-checking, comme on ne disait pas encore à l'époque, posait déjà toutes les questions liées à la vérification des informations, et à l'attitude à avoir face à la propagande de l'adversaire.
Le contexte est rude : les États-Unis sont en guerre. On fait des recherches actives sur les meilleurs moyens de propagande (cf. le livre « Le cercle démocratique »). Le pays est divisé (les relais de la propagande nazie comme Lindbergh s'exprimaient encore librement il y a peu), le racisme est fort et limite l'enthousiasme de certains à combattre. La guerre est un terrain fertile pour la paranoïa. On voit des espions partout et certains estiment que l'Axe pourrait sérieusement affaiblir ses ennemis en lançant des rumeurs. Un groupe de gens a l'idée de créer une rubrique dans un journal peu connu, le Boston Herald, et la baptise Rumor clinic, opération qui aura un certain succès et suscitera des imitateurs. Chaque article suit le plan {exposition d'une rumeur, démenti officiel}. Par exemple, une rumeur dit que des milliers de cadavres de marins étatsuniens ont été retrouvé sur une plage de Long Island, victimes des sous-marins allemands. Une autre que le sang donné par les citoyens noirs pour les hôpitaux militaires faisait que, une fois donné à des soldats blancs blessés, les receveurs auraient des enfants noirs. L'auteur du livre a épluché les numéros du journal et retrace l'histoire de cette « clinique des rumeurs » et des innombrables débats qui ont accompagné cette expérience, avant que la « clinique » ne soit fermée, avant même la fin de la guerre, victime de ses propres défauts et de rivalités bureaucratiques entre services étatiques, certains soutenant le projet et d'autres le combattant.
Pascal Froissart n'est pas tendre avec la clinique des rumeurs (comparez avec l'article bien plus favorable de Wikipédia). Rumeurs non sourcées (peut-être même inventées par les journalistes ?), indifférence face au risque que citer une rumeur pourrait lui donner de l'importance, vérification des faits limitée à citer des autorités, souvent militaires (pas la source la plus fiable pendant une guerre !), zéro enquête journalistique, appels à la vigilance citoyenne, malgré le risque que cela tourne à la chasse aux sorcières (surtout quand on sait ce qui s'est produit après la guerre…), vision binaire des faits (il n'y a que le mensonge et la vérité et rien entre les deux), absence de recherche sérieuse sur le phénomène social de la rumeur (bien qu'un des plus ardents promoteurs du projet soit un chercheur en psychologie). Ces défauts sont d'ailleurs toujours d'actualité dans certains discours anti « fake news », qui considèrent que seule la parole officielle est valable et que la vérité est forcément binaire.
On croise dans ce livre de nombreux personnages fascinants, dont le rôle réel était souvent masqué par le brouillard de la propagande. Ainsi, je ne connaissais pas la journaliste et militante antiraciste Frances Sweeney dont l'auteur estime qu'elle n'a pas eu de rôle réel dans la clinique des rumeurs.
Je divulgâche : on ne sait pas réellement si ces rumeurs étaient organisées par l'Axe. La clinique des rumeurs donnait souvent dans le complotisme, affirmant que tout propagateur de rumeur était un agent ennemi, et cela s'étendait aux ouvrières dénonçant les profits des industries de l'armement. Mais cela n'a jamais été prouvé. De façon amusante, l'OSS a recruté un ancien de la clinique des rumeurs pour aller propager des rumeurs chez l'ennemi (avec un succès mitigé).
Une lecture passionnante et très utile, dans un monde où les guerres et les menaces de guerre servent souvent, comme d'habitude, à faire taire les voix dissidentes, et où le mensonge est largement propagé, aussi bien par le ridicule complotiste de comptoir que par le président des États-Unis.
First publication of this article on 6 June 2025
I manage a small API to get information from the BGP routing protocol. This is its documentation.
The service allows you to find the current origin AS for a given
IP
address. The data comes from the RIS, which does not have apparently a ultra-simple
API. You get more or less what can be seen by any
router located on the DFZ. Here, the API is very
frugal: you call
https://bgp.bortzmeyer.org/IP-ADDRESS
and you
get a plain text reply. This is an example
with curl:
% curl -i https://bgp.bortzmeyer.org/2001:500:2f::f HTTP/2 200 content-type: text/plain … 2001:500:2f::/48 3557
So, the IP address 2001:500:2f::f
is part of
the prefix 2001:500:2f::/48
and is originated
by AS 3557
(ISC).
If the reply is empty, it typically means the service does not have information about this address.
You can also add a prefix length at the end, after a slash.
Of course, it also works with the old version of IP:
% curl https://bgp.bortzmeyer.org/185.71.138.138 185.71.138.0/24 14907
(originated by AS 14907, Wikimedia).
You can access information about the current knowledge of the service with a special request:
% curl https://bgp.bortzmeyer.org/info OK: 1038593 IPv4 prefixes, 231512 IPv6 prefixes, 84914 AS
The service exists for some time now, but did not have its own
documentation before june 2025. Note it can also be accessed on the
fediverse by sending an IP address to
@bgp@mastodon.gougere.fr
(here is an
example).
Source code and a bit more documentation are available at
.https://framagit.org/bortzmeyer/whichasn
Première rédaction de cet article le 5 juin 2025
On n'y croyait plus mais le résolveur DNS public DNS4EU est désormais disponible. Il ne présente pas d'intérêt pratique (il y a déjà beaucoup de résolveurs, y compris publics, y compris européens) mais c'est toujours bien d'élargir le parc. La diversité est une bonne chose.
Leur page
d'accueil donne les adresses
IP à utiliser, après des années d'attente. Comme tous
les résolveurs sérieux, il a, en plus des traditionnels UDP et TCP, les transports
DoT et DoH (mais pas DoQ mais,
bon, ce dernier est nettement moins fréquent aujourd'hui). Comme
tous les résolveurs sérieux, il a une adresse
IPv4 et une IPv6. En
fait, il a même plusieurs adresses dans chaque famille,
correspondant à des niveaux de filtrage différents. Aucune de ces
adresses n'est spécialement mémorisable, contrairement à
dns.sb
.
Premier test simple, avec l'adresse mise en avant, Protective Resolution (tiens, le site Web ne semble exister qu'en anglais, ce qui est curieux pour un projet européen) :
% kdig +tls @2a13:1001::86:54:11:1 frnog.org ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 39597 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1400 B; ext-rcode: NOERROR ;; PADDING: 410 B ;; QUESTION SECTION: ;; frnog.org. IN A ;; ANSWER SECTION: frnog.org. 86400 IN A 213.186.34.12 ;; Received 468 B ;; Time 2025-06-04 20:14:45 CEST ;; From 2a13:1001::86:54:11:1@853(TLS) in 190.0 ms
OK, tout marche, on s'en doutait, mais c'est bien de vérifier.
Ce premier service ment pour les noms qui sont utilisés à des fins malveillantes. Je n'ai pas de tels noms sous la main tout de suite alors j'ai regardé dans ma boite aux lettres de spams mais les noms testés sont tous acceptés.
D'autres services sont proposés, par exemple Protective resolution with child protection & ad-blocking. Si je l'essaie sur un site porno :
% kdig +tls @2a13:1001::86:54:11:11 pornhub.com ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 679 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 0 ;; QUESTION SECTION: ;; pornhub.com. IN A ;; ANSWER SECTION: pornhub.com. 1 IN A 51.15.69.11 ;; Received 45 B ;; Time 2025-06-04 20:22:52 CEST ;; From 2a13:1001::86:54:11:11@853(TLS) in 17.9 ms
L'adresse renvoyée n'a rien à voir avec
Pornhub et elle héberge un serveur HTTP qui
redirige ensuite vers… localhost
. Bon, ça
protège du porno, mais j'avoue ne pas comprendre le comportement du
serveur HTTP.
Bien que ce service soit censé protéger de la pub, il dit la
vérité (malheureusement) pour des noms comme
google-analytics.com
. Pour
googletagmanager.com
, il renvoie un amusant
0.0.0.0
. Aucune utilisation n'est faite des EDE
du RFC 8914, hélas, contrairement à ce que
fait Google Public DNS quand il ment. Je n'ai
pas encore vu de signe de censure étatique (par exemple au profit
des ayant-droits).
Regardons maintenant son hébergement. Il utilise des adresses IP allouées à Whalebone, leader du consortium, ou bien à l'opérateur KCOM (mais elles restent à l'ancien nom, Mistral, les bases des RIR ne sont pas toujours bien fraiches). Voyons combien il y a d'instances différentes, avec Blaeu :
% blaeu-resolve --requested 200 --nsid --nameserver 2a13:1001::86:54:11:1 www.bortzmeyer.org Nameserver 2a13:1001::86:54:11:1 [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eiu-mil-01;] : 40 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-fra-01;] : 35 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-ams-01;] : 55 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-prg-01;] : 5 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-par-01;] : 33 occurrences [TIMEOUT] : 9 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-mad-01;] : 7 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-sto-01;] : 7 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: ;] : 2 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-waw-01;] : 2 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-sof-01;] : 1 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: None;] : 1 occurrences Test #107704910 done at 2025-06-04T18:31:21Z
À part les quelques cas où un relais transparent interceptait les requêtes DNS et renvoyaient un NSID (RFC 5001) trompeur, on voit qu'il y a actuellement neuf instances. (On voit un peu plus d'instances en utilisant l'adresse IPv4 du résolveur.) L'affichage du temps de réponse est compatible avec des serveurs entièrement en Europe (ce qui est logique pour un service européen, le résolveur indien a fait un choix analogue) :
% blaeu-resolve --old-measurement 107705432 --nsid --displayrtt --nameserver 86.54.11.1 www.bortzmeyer.org Nameserver 86.54.11.1 [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-par-01;] : 113 occurrences Average RTT 136 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-fra-01;] : 22 occurrences Average RTT 152 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eiu-mil-01;] : 10 occurrences Average RTT 137 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-prg-01;] : 5 occurrences Average RTT 138 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-ams-01;] : 31 occurrences Average RTT 117 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: None;] : 4 occurrences Average RTT 14 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-mad-01;] : 2 occurrences Average RTT 123 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: 90m8;] : 1 occurrences Average RTT 156 ms [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: ;] : 3 occurrences Average RTT 1 ms [TIMEOUT] : 5 occurrences [2001:4b98:dc0:41:216:3eff:fe27:3d3f 2602:fbb1:1:245b::42 NSID: dns4eu-bud-01;] : 3 occurrences Average RTT 251 ms Test #107705867 done at 2025-06-04T18:41:34Z
(Une première mesure, la 107705432, avait servi à remplir la mémoire
des résolveurs, afin que le temps de réponse dépende surtout du
résolveur, pas des serveurs faisant autorité interrogés. Elle avait
indiqué --area West
, donc
l'Amérique.) Le temps de réponse permet de
voir que le résolveur n'est pas sur le continent américain. Pour un résolveur censé
servir essentiellement au public européen, c'est logique.
Curieusement, alors que le cahier des charges de DNS4EU prévoyait explicitement la mise en œuvre de la censure des 27 États membres de l'UE, je n'ai pas trouvé de domaine censuré. Même Sci-Hub marche :
% kdig +nsid +tls @2a13:1001::86:54:11:11 sci-hub.se ;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(ECDSA-SECP256R1-SHA256)-(AES-256-GCM) ;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 14949 ;; Flags: qr rd ra; QUERY: 1; ANSWER: 1; AUTHORITY: 0; ADDITIONAL: 1 ;; EDNS PSEUDOSECTION: ;; Version: 0; flags: ; UDP size: 1400 B; ext-rcode: NOERROR ;; NSID: 646E733465752D7061722D3031 "dns4eu-par-01" ;; PADDING: 392 B ;; QUESTION SECTION: ;; sci-hub.se. IN A ;; ANSWER SECTION: sci-hub.se. 60 IN A 186.2.163.219 ;; Received 468 B ;; Time 2025-06-04 20:44:22 CEST ;; From 2a13:1001::86:54:11:11@853(TLS) in 58.3 ms
Sinon, je l'ai dit, avoir juste un autre résolveur DNS public n'est pas super intéressant. Parmi ceux qui existent en Europe :
Et il existe d'autres résolveurs européens, sans compter ceux de Wikipédia.
Sinon, sur les prétentions de DNS4EU à la souveraineté, vous pouvez lire l'article « How much EU is in DNS4EU? ». Une très bonne analyse technique détaillée de DNS4Eu figure dans « DNS4EU – a bit EU, a bit secure, a bit pointless », dont le titre résume bien la conclusion (avec laquelle je suis d'accord). Ce dernier article analyse notamment la réactivité de DNS4EU pour intégrer les nouveaux noms « dangereux ».
Première rédaction de cet article le 4 juin 2025
Les 24 et 25 mai 2025, à Lyon, c'étaient les Journées du Logiciel Libre. Comme toujours, deux jours passionnants avec plein de gens bien. J'y ai fait une conférence sur le projet de réforme de la délégation DNS, DELEG.
Ma conférence portait sur un projet IETF en cours, projet de réforme fondamentale du mécanisme de délégation dans le DNS. Vous pouvez trouver en ligne mon support, son source et la vidéo de la conférence. Notez que, sur ce sujet (le projet DELEG), j'avais déjà fait un article sur le blog de l'Afnic. D'autre part, si vous voulez suivre le projet DELEG, le meilleur point de départ est le Datatracker de l'IETF.
Parmi les autres activités du week-end (je n'ai pas tout fait, le programme était riche !), il y avait (très vaguement dans un ordre d'intérêt décroissant pour moi) :
Comme l'année précédente, les JDLL se sont tenues à l'ENS. Le parc
intérieur est superbe, et entretenu par des animaux consciencieux et des jardiniers
talentueux.
Et bien sûr mille mercis aux nombreux·ses bénévoles qui ont
travaillé pour cette édition des JDLL, très réussie comme
d'habitude. Et, sinon, une image qui n'a rien à voir avec les JDLL,
à part qu'elle a été prise au Musée des
Confluences, à courte distance du site des JDLL (c'est
le mammouth de
Choulans) :
Articles des différentes années : 2025 2024 2023 2022 2021 2020 2019 Précédentes années
Syndication : Flux Atom avec seulement les résumés et Flux Atom avec tout le contenu.