Mon blog

Ce matin, si vous avez testé, un de mes domaines personnels, bortzmeyer.fr, présentait des problèmes DNSSEC. Que s'est-il passé ? Était-ce de ma faute ? Va t-on tous mourir ?

Le signalement a été fait par un collègue (via Matrix puisqu'il était en télétravail et pas moi) : son résolveur DNS répondait SERVFAIL (SERver FAILure) pour l'enregistrement de type TXT de bortzmeyer.fr. C'est le type utilisé pour SPF donc c'est ennuyeux (le domaine principal, bortzmeyer.org, avait le même problème) :

% dig bortzmeyer.fr TXT    

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> bortzmeyer.fr TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 28082
;; flags: qr rd ra; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 6 (DNSSEC Bogus)
;; QUESTION SECTION:
;bortzmeyer.fr.		IN TXT

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Nov 06 08:17:48 UTC 2025
;; MSG SIZE  rcvd: 48

  

On voit que c'est un problème DNSSEC puisque l'EDE (Extended DNS Error, cf. RFC 8914) nous le dit (« 6 (DNSSEC Bogus) ») et aussi parce que, si on désactive la validation (cd = Checking Disabled), ça marche :

% dig +cd bortzmeyer.fr TXT

; <<>> DiG 9.20.15-1~deb13u1-Debian <<>> +cd bortzmeyer.fr TXT
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44332
;; flags: qr rd ra cd; QUERY: 1, ANSWER: 5, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 1232
; EDE: 6 (DNSSEC Bogus)
;; QUESTION SECTION:
;bortzmeyer.fr.		IN TXT

;; ANSWER SECTION:
bortzmeyer.fr.		45 IN TXT "DNS is innocent"
bortzmeyer.fr.		45 IN TXT "v=spf1 mx -all"
bortzmeyer.fr.		45 IN TXT "BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax"
bortzmeyer.fr.		45 IN RRSIG TXT 13 2 86400 (
				20251113173453 20251030142433 32088 bortzmeyer.fr.
				J1arZUBP+G5nc54zetyD45rqDyURJeZyFjRRkixQrPok
				BPxNkyt1RHzdH78a0rM93Zzu0q+N/zzxMQScl0KVHw== )
bortzmeyer.fr.		45 IN RRSIG TXT 13 2 86400 (
				20251113215344 20251030142433 32088 bortzmeyer.fr.
				bWAlKMSQPDALOeEmwwfh47qGjloBK3YRH3rGydVJBis4
				lFIsIsE09bkqviBiGyjNqpS/loFaiMS4FRIeh06jwg== )

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1) (UDP)
;; WHEN: Thu Nov 06 08:17:51 UTC 2025
;; MSG SIZE  rcvd: 372

  

Le résultat de dig donne aussi une première explication : il y a deux signatures DNSSEC, faites avec la même clé, la 32088. Ce n'est pas normal. (Les enregistrements des autres types, comme SOA ou MX, n'avaient pas de problème.)

Le test avec Zonemaster montrait que les enregistrements NSEC3, qui servent à prouver la non-existence d'un nom ou d'un type d'enregistrement, étaient également cassés. Le test avec DNSviz donne une idée du problème : « RRSIG bortzmeyer.fr/TXT alg 13, id 32088: The cryptographic signature of the RRSIG RR does not properly validate. ».

Un test avec les sondes RIPE Atlas montre que le problème n'est pas local. Toutes les sondes utilisant un résolveur DNS validant voient le problème (les seules où ça marche sont celles qui ne valident pas) :

%  blaeu-resolve --displayvalidation --requested 200 --type TXT bortzmeyer.fr
[ERROR: SERVFAIL] : 147 occurrences 
["btc" "1htnj6zfuc9yu9u2qawb4tgdgwpqasqgax" "dns is innocent" "v=spf1 mx -all"] : 31 occurrences 
Test #136108974 done at 2025-11-06T08:24:58Z
  

L'explication du problème a été trouvée en examinant les fichiers de zone, avant et après la signature. Dans le fichier non signé, celui que j'édite, on trouve cette ligne :

; Type WALLET, enregistré à l'IANA, mais pas encore connu des logiciels
@ IN    TYPE262 \# 39 03425443 223148744E4A365A465563397975397532714177423474476447775051617351476178
  

Mais dans le fichier signé par OpenDNSSEC, on trouve :

bortzmeyer.fr.	86400	IN	TXT	"BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax"
  

Le type 262 (WALLET) est devenu un type 16 (TXT). Ce n'est pas du tout normal, c'est clairement une bogue du signeur d'OpenDNSSEC. Creusons un peu. Le type WALLET est un type d'enregistrement, et ce type est officiellement enregistré à l'IANA. Cela fait plus d'un an qu'il est annoncé dans mes domaines personnels. Comme, à l'époque, il n'était pas connu des logiciels, j'ai utilisé la syntaxe des types inconnus, syntaxe normalisée depuis plus de vingt ans, dans le RFC 3597. La traduction en TXT n'a pas de sens, car, si l'enregistrement de type WALLET a bien des données structurées comme le TXT, c'est un type différent. Le signeur a apparemment calculé une signature pour les TXT, une pour le WALLET, puis traduit le WALLET en TXT, cassant tout (les signatures s'appliquent à un ensemble d'enregistrements, pas à un enregistrement unique, donc deux TXT n'ont qu'une signature) :

bortzmeyer.fr.	86400	IN	TXT	"v=spf1 mx -all"
bortzmeyer.fr.	86400	IN	TXT	"DNS is innocent"
bortzmeyer.fr.	86400	IN	RRSIG	TXT 13 2 86400 20251113215344 20251030142433 32088 bortzmeyer.fr. bWAlKMSQPDALOeEmwwfh47qGjloBK3YRH
3rGydVJBis4lFIsIsE09bkqviBiGyjNqpS/loFaiMS4FRIeh06jwg==
bortzmeyer.fr.	86400	IN	TXT	"BTC" "1HtNJ6ZFUc9yu9u2qAwB4tGdGwPQasQGax"
bortzmeyer.fr.	86400	IN	RRSIG	TXT 13 2 86400 20251113173453 20251030142433 32088 bortzmeyer.fr. J1arZUBP+G5nc54zetyD45rqDyURJeZyF
jRRkixQrPokBPxNkyt1RHzdH78a0rM93Zzu0q+N/zzxMQScl0KVHw==

C'est ce fichier erroné (l'erreur cassait aussi les chaines NSEC3) qui a été produit et distribué aux serveurs faisant autorité, provoquant les problèmes détectés. La rupture des NSEC3 se voyait lorsqu'on demandait un nom non existant (ici avec les sondes Atlas) :

% blaeu-resolve --displayvalidation --requested 200 --type TXT doesnotexist.bortzmeyer.fr
[ERROR: SERVFAIL] : 144 occurrences 
[ERROR: NXDOMAIN] : 28 occurrences 
Test #136110101 done at 2025-11-06T08:35:32Z
  

Ce problème a été signalé sur la liste de diffusion d'OpenDNSSEC. Notez que ce logiciel est en fin de vie (son successeur, Cascade, est actuellement en version alpha) donc je ne sais pas encore si la bogue sera traitée.

Pour réparer le problème, j'ai retiré l'enregistrement WALLET et tout remarche. Ça va mieux (ici, certains résolveurs avaient encore les données erronnées dans leur mémoire) :

% blaeu-resolve --displayvalidation --requested 200 --type TXT
bortzmeyer.fr ["dns is innocent" "v=spf1 mx -all"] : 65 occurrences [
(Authentic Data flag) "dns is innocent" "v=spf1 mx -all"] : 128
occurrences [ERROR: SERVFAIL] : 4 occurrences [] : 1 occurrences Test
#136145680 done at 2025-11-06T14:29:36Z 

Le plus curieux est que cette bogue se soit déclenchée en l'absence de tout changement. Douze jours auparavant, il y avait le même fichier de zone (l'enregistrement WALLET datait de plus d'un an) et tout allait bien.

Quelle(s) leçon(s) à en tirer ? Que l'informatique, c'est compliqué, que les logiciels ont des bogues et que, si on est très intolérant aux problèmes, il ne faut pas chercher les cas exotiques. Et que le bon fonctionnement de l'Internet ne repose pas sur des règles bureaucratiques et des processus mais sur la réactivité, à la fois pour signaler les problèmes (merci à Marc van der Wal pour cela), et pour les traiter lorsqu'ils sont signalés.

Puisque je suis occupé à transférer beaucoup de noms de domaine vers un autre Bureau d'Enregistrement (BE), c'est l'occasion de se demander « et si c'est un nom de domaine internationalisé, que se passe-t-il ? ».

Sur les transferts d'un BE à un autre, j'ai déjà commis un article sur ce sujet. Mais j'ai dû, depuis, transférer un IDN, potamochère.fr. Vous savez que les IDN sont, pour des raisons complexes (et non, ce n'est pas parce que le DNS est limité à ASCII, essayez vous-même, vous verrez) encodés en Punycode (RFC 3492). potamochère.fr est donc encodé en xn--potamochre-66a.fr. Normalement, ce n'est qu'un détail technique, invisible aux utilisateurs mais, hélas, dix-neuf ans après la sortie du premier RFC sur les IDN (RFC 3490), certains logiciels continuent à présenter à l'utilisateur la forme en Punycode, en violation du RFC 2277.

Ainsi, le BE gagnant permet de commander le transfert en utilisant la forme en joli Unicode lisible mais, lors de l'affichage de la liste des serveurs actuels, le BE gagnant montre du Punycode :

Même chose pour la configuration des serveurs :

Ce qui est amusant est que les courriers de ce même BE respectent tous le bon encodage et sont donc lisibles :

Subject: [potamochère.fr] Notification de transfert
From: support@netim.com
Date: Sun,  2 Nov 2025 12:19:26 +0100 (CET)

02/11/2025
Cher client,

Ceci est une notification au sujet du transfert de votre domaine potamochère.fr vers NETIM.

Alors qu'en général, le courrier est moins internationalisé que le Web.

D'un BE à l'autre, les choses sont différentes. Par exemple, chez le BE perdant :

Subject: [GANDI] IMPORTANT: Transfert sortant vers un autre prestataire du  domaine xn--potamochre-66a.fr
From: no-reply@gandi.net
Date: Sun, 02 Nov 2025 11:20:29 -0000

A l'attention de : Stéphane Bortzmeyer
Transfert du nom de domaine: xn--potamochre-66a.fr
Registrar demandeur: <NETIM SARL>

Et idem sur leur serveur Web :

Corriger tous les endroits où l'IDN n'est pas traité proprement va prendre du temps…

J'ai déjà parlé de Cascade, un logiciel actuellement en développement, qui automatise un certain nombre de tâches nécessaires pour DNSSEC, comme la re-signature ou le remplacement des clés. Le projet avance vite donc voyons quelques nouveaux essais.

D'abord, puisque Cascade tire son nom du traitement en plusieurs étapes d'une tâche, avec la possibilité d'insérer des validations à chaque étape, essayons la validation manuelle (j'ai déjà montré la validation automatique dans mon précédent article). Comme pour la validation automatique, vous pouvez valider la zone avant la signature et/ou après. Comme pour la validation automatique, vous devez indiquer, dans le fichier qui décrit une politique de gestion, que des examens (review) sont obligatoires :

% cat /etc/cascade/policies/default.toml
…
[loader.review]
required = true
…
[signer.review]
required = true
…

Par contre, et contrairement à ce qui se passe pour la validation automatique, vous n'indiquez pas de programme à exécuter (hook). Cela signifiera, pour Cascade, qu'il faut une validation manuelle. Vous rechargez alors les politiques (cascade policy reload) et (c'est une bogue de la version de développement), vous redémarrez le serveur. Lorsqu'une nouvelle version d'une zone est prête, et que vous l'indiquez au serveur (cascade zone reload example.org), vous voyez ceci :

% cascade zone status example.org                                                      
Status report for zone 'example.org' using policy 'default'
✔ Waited for a new version of the example.org zone
✔ Loaded version 2025102700
  Loaded at 2025-10-27T08:47:38+00:00 (13s ago)
  Loaded 243 B and 4 records from the filesystem in 0 seconds
• Waiting for approval to sign version 2025102700
! Zone will be held until manually approved
  Approve with: cascade zone approve --unsigned example.org 2025102700
  Reject with:  cascade zone reject --unsigned example.org 2025102700

La zone n'est pas encore signée, vous devez la valider. (Rappelez-vous qu'on peut imposer une validation de la zone non signée, de la zone signée, ou bien des deux.) Et Cascade vous indique comment faire, mais pas comment récupérer la zone à signer. Pour cela, le plus simple est un transfert de zones (RFC 5936) depuis le serveur indiqué par les directives .servers dans la configuration de Cascade.

% cat /etc/cascade/config.toml 
…    
[loader]
review.servers = ["127.0.0.1:4541", "[::1]:4541"]

[signer]
review.servers = ["127.0.0.1:4542", "[::1]:4542"]
…
% dig @127.0.0.1 -p 4541 example.org AXFR
…

On peut alors examiner la zone. Mettons qu'elle nous satisfasse. On va alors suivre les instructions qu'affichait cascade zone status :

% cascade zone approve --unsigned example.org 2025102700
Approved unsigned zone 'example.org' with serial number 2025102700

Personnellement, je ne vois pas trop l'intérêt d'examiner manuellement la zone non signée (on pourrait aussi examiner le fichier de zone qu'on a donné à Cascade) et je vais plutôt regarder la zone signée, qui est servie sur un autre port.

Autre activité, Cascade permet également d'automatiser une opération délicate : le remplacement des clés. Cette opération est nécessaire si on découvre qu'une clé privée a été compromise. Et on peut aussi estimer que le remplacement est utile, même en l'absence de compromission, pour pratiquer les procédures et vérifier que tout se passera bien lorsqu'on aura vraiment besoin d'un remplacement. Supposons une politique avec deux clés, la KSK (Key Signing Key, qui ne signe que les clés) et la ZSK (Zone Signing Key, qui signe le reste). D'abord, l'état initial :

% dig +multi +dnssec internautique.fr DNSKEY
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 30159
;; flags: qr rd ra; QUERY: 1, ANSWER: 3, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
internautique.fr.	3600 IN	DNSKEY 257 3 15 (
				IDypc2j/kbE3iHtnbry715I6jwgVEPMLz1+QV9GNgMA=
				) ; KSK; alg = ED25519 ; key id = 33113
internautique.fr.	3600 IN	DNSKEY 256 3 15 (
				K+sBrJFESzsLwD6AFGW+zZrydRjk5QRtbshG4AKV/jI=
				) ; ZSK; alg = ED25519 ; key id = 56167
internautique.fr.	3600 IN	RRSIG DNSKEY 15 2 3600 (
				20251109195246 20251025195246 33113 internautique.fr.
				ARucHmrIB8ivtduHEzphj2SJEGRZ7BlP5c7686dD2DTy
				TDJpZc9Rcerrh5okki3rKKOsFMqOwXunlNl+cgGcBA== )
…
;; WHEN: Mon Oct 27 09:06:13 CET 2025

Nous avons dans le DNS la KSK, d'identification 33113, et la ZSK, d'identification 56167. C'est aussi ce que nous dit Cascade :

% cascade zone status --detailed internautique.fr           
…
✔ Published version 2025102612
  Published zone available on 127.0.0.1:8053
DNSSEC keys:
  ZSK tagged 56167:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+56167.key
    Actively used for signing
  KSK tagged 33113:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key
    Actively used for signing
  Details:
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+56167.key expires at 2025-11-02T14:51:53Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key expires at 2025-12-26T14:51:53Z
  

Et c'est aussi ce qu'on peut voir avec DNSviz. Maintenant, commençons le remplacement de la ZSK :

%  cascade keyset internautique.fr zsk start-roll 
Manual key roll for internautique.fr successful
  

Et voici le résultat, une nouvelle ZSK est apparue, la 30906 :

% cascade zone status --detailed internautique.fr 
Status report for zone 'internautique.fr' using policy 'default'
✔ Waited for a new version of the internautique.fr zone
✔ Loaded version 2025101721
  Loaded at 2025-10-26T14:51:53+00:00 (17h 16m 7s ago)
  Loaded 333 B and 7 records from the filesystem in 0 seconds
✔ Waited for approval to sign version 2025101721
✔ Approval received to sign version 2025101721, signing requested
✔ Signed version 2025101721 as version 2025102701
  Signing requested at 2025-10-27T08:07:36+00:00 (24s ago)
  Signing started at 2025-10-27T08:07:36+00:00 (24s ago)
  Signing finished at 2025-10-27T08:07:36+00:00 (24s ago)
  Collected 8 records in 0s, sorted in 0s
  Generated 6 NSEC(3) records in 0s
  Generated 8 signatures in 0s (8 sig/s)
  Inserted signatures in 0s (8 sig/s)
  Took 0s in total, using 1 threads
  Current action: Finished
✔ Waited for approval to publish version 2025102701
✔ Published version 2025102701
  Published zone available on 127.0.0.1:8053
DNSSEC keys:
  KSK tagged 33113:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key
    Actively used for signing
  ZSK tagged 30906:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key
  ZSK tagged 56167:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+56167.key
    Actively used for signing
  Details:
    ZskRoll: CacheExpire1(3600)
    Wait until 2025-10-27T09:07:36Z to let caches expire
    For the next step run:
    	cascade keyset internautique.fr zsk cache-expired1
    	automation is enabled for this step.
    
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key expires at 2025-12-26T14:51:53Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key expires at 2025-11-03T08:07:27Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+56167.key expires at 2025-11-02T14:51:53Z
  

À la fin, c'est bon, le remplacement s'est fait sans autre intervention, et en respectant les durées nécessaires pour que, à tout moment, tous les résolveurs DNS de la planète aient un chemin de validation complet, depuis la racine :

% cascade zone status --detailed internautique.fr
Status report for zone 'internautique.fr' using policy 'default'
✔ Waited for a new version of the internautique.fr zone
✔ Loaded version 2025101721
  Loaded at 2025-10-26T14:51:53+00:00 (23h 45m 37s ago)
  Loaded 333 B and 7 records from the filesystem in 0 seconds
✔ Waited for approval to sign version 2025101721
✔ Approval received to sign version 2025101721, signing requested
✔ Signed version 2025101721 as version 2025102705
  Signing requested at 2025-10-27T12:07:56+00:00 (2h 29m 34s ago)
  Signing started at 2025-10-27T12:07:56+00:00 (2h 29m 34s ago)
  Signing finished at 2025-10-27T12:07:56+00:00 (2h 29m 34s ago)
  Collected 8 records in 0s, sorted in 0s
  Generated 5 NSEC(3) records in 0s
  Generated 8 signatures in 0s (8 sig/s)
  Inserted signatures in 0s (8 sig/s)
  Took 0s in total, using 1 threads
  Current action: Finished
✔ Waited for approval to publish version 2025102705
✔ Published version 2025102705
  Published zone available on 127.0.0.1:8053
DNSSEC keys:
  KSK tagged 33113:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key
    Actively used for signing
  ZSK tagged 30906:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key
    Actively used for signing
  Details:
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key expires at 2025-11-03T08:07:27Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key expires at 2025-12-26T14:51:53Z

Vous pouvez admirer l'état final dans DNSviz.

Maintenant, remplaçons la KSK. C'est un peu plus délicat car il y a une opération manuelle à faire, auprès de la zone parente (.fr dans notre cas).

On voit l'état initial sur DNSviz. Démarrons l'opération :

%  cascade keyset internautique.fr ksk start-roll
Manual key roll for internautique.fr successful

% cascade zone status --detailed internautique.fr
Status report for zone 'internautique.fr' using policy 'default'
✔ Waited for a new version of the internautique.fr zone
✔ Loaded version 2025101721
  Loaded at 2025-10-26T14:51:53+00:00 (1day 19h 29m 50s ago)
  Loaded 333 B and 7 records from the filesystem in 0 seconds
✔ Waited for approval to sign version 2025101721
✔ Approval received to sign version 2025101721, signing requested
✔ Signed version 2025101721 as version 2025102801
  Signing requested at 2025-10-28T10:21:36+00:00 (7s ago)
  Signing started at 2025-10-28T10:21:36+00:00 (7s ago)
  Signing finished at 2025-10-28T10:21:36+00:00 (7s ago)
  Collected 8 records in 0s, sorted in 0s
  Generated 7 NSEC(3) records in 0s
  Generated 8 signatures in 0s (8 sig/s)
  Inserted signatures in 0s (8 sig/s)
  Took 0s in total, using 1 threads
  Current action: Finished
✔ Waited for approval to publish version 2025102801
✔ Published version 2025102801
  Published zone available on 127.0.0.1:8053
DNSSEC keys:
  KSK tagged 49915:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+49915.key
    Actively used for signing
  ZSK tagged 30906:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key
    Actively used for signing
  KSK tagged 33113:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key
    Actively used for signing
  Details:
    KskRoll: CacheExpire1(3600)
    Wait until 2025-10-28T11:21:36Z to let caches expire
    For the next step run:
    	cascade keyset internautique.fr ksk cache-expired1
    	automation is enabled for this step.
    
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+49915.key expires at 2025-12-28T10:21:27Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key expires at 2025-12-26T14:51:53Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key expires at 2025-11-03T08:07:27Z

La nouvelle KSK, la 49915, est publiée. Une fois le temps nécessaire écoulé (toujours cette histoire de la mémorisation, par les résolveurs, des données), Cascade nous dit qu'il faut maintenant changer la DS :

    
% cascade zone status --detailed internautique.fr
Status report for zone 'internautique.fr' using policy 'default'
✔ Waited for a new version of the internautique.fr zone
✔ Loaded version 2025101721
  Loaded at 2025-10-26T14:51:53+00:00 (1day 23h 59m 24s ago)
  Loaded 333 B and 7 records from the filesystem in 0 seconds
✔ Waited for approval to sign version 2025101721
✔ Approval received to sign version 2025101721, signing requested
✔ Signed version 2025101721 as version 2025102806
  Signing requested at 2025-10-28T14:22:01+00:00 (29m 15s ago)
  Signing started at 2025-10-28T14:22:01+00:00 (29m 15s ago)
  Signing finished at 2025-10-28T14:22:01+00:00 (29m 15s ago)
  Collected 8 records in 0s, sorted in 0s
  Generated 7 NSEC(3) records in 0s
  Generated 8 signatures in 0s (8 sig/s)
  Inserted signatures in 0s (8 sig/s)
  Took 0s in total, using 1 threads
  Current action: Finished
✔ Waited for approval to publish version 2025102806
✔ Published version 2025102806
  Published zone available on 127.0.0.1:8053
DNSSEC keys:
  KSK tagged 33113:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key
    Actively used for signing
  KSK tagged 49915:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+49915.key
    Actively used for signing
  ZSK tagged 30906:
    Reference: file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key
    Actively used for signing
  Details:
    KskRoll: Propagation2
    Check that all nameservers of the parent zone have the following RRset (or equivalent):
    internautique.fr. 3600 IN DS 49915 15 2 0ADF31249F82B92BC7A8068CB2D6117C35F78E5994F1AFF7BCFE6999A71F5091
    
    For the next step run:
    	cascade keyset internautique.fr ksk propagation2-complete <ttl>
    	automation is enabled for this step.
    
    Automatic key roll state:
    Roll KskRoll, state Propagation2:
    	Wait until the new DS RRset has propagated to all nameservers
    	of the parent zone. Try again after 2025-10-28T15:22:01Z
    
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+30906.key expires at 2025-11-03T08:07:27Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+33113.key expires at 2025-12-26T14:51:53Z
    key file:///var/db/cascade/keys/Kinternautique.fr.+015+49915.key expires at 2025-12-28T10:21:27Z
  

Vous avez vu, à la fin ? Il faut placer la DS internautique.fr. 3600 IN DS 49915 15 2 0ADF31249F82B92BC7A8068CB2D6117C35F78E5994F1AFF7BCFE6999A71F5091 dans la zone parente, ce qui se fait typiquement via l'interface (Web ou API) de son BE. Ce sera la seule opération manuelle qu'il faudra faire.

L'ancienne KSK sera supprimée automatiquement en temps utile. (Ici, la 33113 est encore présente, et les clés seront signées avec les deux KSK.)

Dans l'opération précédente, on avait deux clés, la KSK et la ZSK. C'est la configuration la plus courante. Mais elle n'est pas obligatoire. Elle avait été promue à une époque car elle résolvait un problème spécifique à l'algorithme de cryptographie RSA : ce dernier laissait le choix entre des clés courtes, compactes et rapides mais peu sûres, et des clés longues, dont les avantages et inconvénients étaient à l'opposé. Avec RSA, avoir une ZSK courte et changée souvent, ainsi qu'une KSK longue et changée plus rarement, était logique. Mais avec les algorithmes comme ceux fondés sur des courbes elliptiques, ce n'est plus utile. Autant n'avoir qu'une clé, qu'on nomme souvent CSK, pour Common Signing Key. Dans Cascade, cela se configure dans la politique (rappelez-vous que vous pouvez avoir plusieurs politiques, donc qu'une même instance de Cascade peut gérer des zones avec CSK et des zones avec KSK/ZSK) :

% cat  /etc/cascade/policies/one-key.toml
…
use-csk = true
  

Et voici ce qu'affiche Cascade :

    
% cascade zone status --detailed cours-dns.fr
Status report for zone 'cours-dns.fr' using policy 'one-key'
✔ Waited for a new version of the cours-dns.fr zone
✔ Loaded <serial number not yet known>
  Loaded at 2025-10-31T13:23:23+00:00 (1day 5h 36m 3s ago)
  Loaded 261 B and 5 records from the filesystem in 0 seconds
✔ Waited for approval to sign <serial number not yet known>
• Approval received to sign <serial number not yet known>, signing requested
DNSSEC keys:
  CSK tagged 50973:
    Reference: file:///var/db/cascade/keys/Kcours-dns.fr.+015+50973.key
    Actively used for signing
  Details:
    key file:///var/db/cascade/keys/Kcours-dns.fr.+015+50973.key expires at 2026-10-30T13:01:19Z

  

Et vous pouvez voir graphiquement la clé unique avec DNSviz.

Allez, un autre point, la technique utilisée pour indiquer les noms absents. DNSSEC en permet deux, les NSEC du RFC 4034 et les NSEC3 du RFC 5155. Cascade permet de configurer l'un ou l'autre dans la politique :

type = "nsec"
# type = "nsec3"
  

Ah, et une nouveauté relativement récente de Cascade, un moyen simple de tester si le démon tourne bien :

% cascade health
Ok
  

Ce qui est très pratique dans une supervision automatisée :

% sudo -u nagios /usr/local/lib/nagios/plugins/check_cascade                   
Cascade OK
  

Allez, encore un résolveur DNS public européen, celui de Freifunk München. Rien d'extraordinaire mais rappelez-vous que, dans ce domaine, pluralisme et diversité sont cruciaux.

Des résolveurs DNS publics, il y en a beaucoup (j'en gère même un). Les utilisateurices et administrateurices système s'en servent pour des raisons variées, par exemple échapper à la censure. Mais ils ne sont pas tous équivalents, en terme de caractéristiques techniques, de fonctions (certains sont menteurs), de politique de gestion des données personnelles, etc. Le service de Freifunk München :

• A DoT, DoH, DNSSEC et IPv6 (comme tous les résolveurs publics sérieux),
• Promet d'être strict sur la vie privée et notamment de ne pas garder de trace des requêtes faites,
• Est européen (certains résolveurs publics qui se présentent comme européens sont en fait des services étatsuniens un peu repeints, par exemple en s'appuyant sur la nationalité d'origine du fondateur), plus précisément allemand (par contre, le nom de domaine est dans un TLD étatsunien, ce qui est curieux, mais n'a pas trop d'importance car le nom ne sert pas beaucoup pour accéder à un résolveur DNS, sauf pour l'authentification TLS).

Faisons quelques essais techniques. Les adresses et noms à utiliser sont 185.150.99.255, 5.1.66.255, 2001:678:e68:f000::, 2001:678:ed0:f000::, dot.ffmuc.net, https://doh.ffmuc.net/dns-query et doq.ffmuc.net (je n'ai pas testé ce dernier). D'abord, avec dig :

    
% dig @2001:678:ed0:f000::  sci-hub.se
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24707
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
sci-hub.se.		60 IN A	186.2.163.219

;; Query time: 34 msec
;; SERVER: 2001:678:ed0:f000::#53(2001:678:ed0:f000::) (UDP)
;; WHEN: Thu Oct 16 14:38:17 CEST 2025
;; MSG SIZE  rcvd: 55

  

OK, c'est bon, tout marche, et en un temps raisonnable depuis ma connexion Free à Paris. (Évidemment, un résolveur public ne sera jamais aussi rapide qu'un résolveur local et il n'est donc pas raisonnable d'utiliser un résolveur public « pour les performances ».)

Et avec DoT ?

% dig +tls @2001:678:ed0:f000:: liberation.fr
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 31755
;; flags: qr rd ra; QUERY: 1, ANSWER: 4, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
liberation.fr.		300 IN A 3.165.113.53
liberation.fr.		300 IN A 3.165.113.101
liberation.fr.		300 IN A 3.165.113.127
liberation.fr.		300 IN A 3.165.113.118

;; Query time: 62 msec
;; SERVER: 2001:678:ed0:f000::#853(2001:678:ed0:f000::) (TLS)
;; WHEN: Thu Oct 16 14:40:02 CEST 2025
;; MSG SIZE  rcvd: 106

  

Et du DoH ?

    
% kdig +https=https://doh.ffmuc.net/dns-query  @185.150.99.255 bortzmeyer.fr NS

;; TLS session (TLS1.3)-(ECDHE-SECP256R1)-(RSA-PSS-RSAE-SHA256)-(AES-128-GCM)
;; HTTP session (HTTP/2-POST)-(doh.ffmuc.net/dns-query)-(status: 200)
;; ->>HEADER<<- opcode: QUERY; status: NOERROR; id: 0
;; Flags: qr rd ra ad; QUERY: 1; ANSWER: 7; AUTHORITY: 0; ADDITIONAL: 1

;; EDNS PSEUDOSECTION:
;; Version: 0; flags: ; UDP size: 512 B; ext-rcode: NOERROR
;; PADDING: 238 B
…
;; ANSWER SECTION:
bortzmeyer.fr.      	85495	IN	NS	ns2.1984hosting.com.
bortzmeyer.fr.      	85495	IN	NS	ns0.1984.is.
bortzmeyer.fr.      	85495	IN	NS	ns4.bortzmeyer.org.
bortzmeyer.fr.      	85495	IN	NS	ns-global.kjsl.com.
bortzmeyer.fr.      	85495	IN	NS	puck.nether.net.
bortzmeyer.fr.      	85495	IN	NS	ns2.bortzmeyer.org.
bortzmeyer.fr.      	85495	IN	NS	ns2.1984.is.

;; Received 468 B
;; Time 2025-10-16 14:42:39 CEST
;; From 185.150.99.255@443(HTTPS) in 91.2 ms

  

C'est parfait, tout marche. Pour la dernière requête, celle faite avec DoH, notez que le résolveur valide bien les domaines signés.

Configurons maintenant un résolveur local pour faire suivre à ffmuc, pour profiter de la mémorisation des réponses par celui-ci. On va utiliser Unbound et faire suivre en TLS :

forward-zone:
        name: "."
        # Freifunk München
        forward-addr: 2001:678:ed0:f000::@853#dot.ffmuc.net
        forward-tls-upstream: yes
  

Et tout marche, notre résolveur local fera suivre ce qu'il ne sait pas déjà à ffmuc.

ffmuc a-t-il plusieurs machines, réparties par anycast ? On peut regarder les identités de ces serveurs avec NSID (RFC 5001) :

%   dig +nsid @5.1.66.255 www.phy.cam.ac.uk     
…
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags: do; udp: 512
; NSID: 64 6f 74 2e 66 66 6d 75 63 2e 6e 65 74 ("dot.ffmuc.net")
;; QUESTION SECTION:
;www.phy.cam.ac.uk.	IN A

;; ANSWER SECTION:
www.phy.cam.ac.uk.	3591 IN	CNAME tm-128-232-132-117.tm.uis.cam.ac.uk.
tm-128-232-132-117.tm.uis.cam.ac.uk. 3600 IN A 128.232.132.117
…

  

Le NSID est juste le nom du service. Un test avec les sondes RIPE Atlas montre qu'il n'y a en effet qu'un seul serveur.

Notez enfin que la configuration technique de ce service est publique ainsi que celle des autres services.

Est-ce que je vais utiliser ce service ? Non, il en existe plusieurs autres qui me conviennent (dont le mien, bien sûr, mais aussi celui de FDN) mais avoir le choix est une bonne chose.

Dans beaucoup de TLD, le ou la simple titulaire ne peut pas acheter directement un nom de domaine, il faut passer par un Bureau d'Enregistrement (BE). Le transfert, l'opération qui consiste à changer de bureau d'enregistrement, est parfois une opération frustrante. Je suis en train de transférer mes noms de domaine personnels (et ils sont tous signés avec DNSSEC) donc voici quelques notes, au cas où.

Dans le cas de .fr, l'obligation de passer par un BE est dans la loi : « L'attribution des noms de domaine est assurée par les offices d'enregistrement [sic ; il s'agit des registres], par l'intermédiaire des bureaux d'enregistrement. » (article L45-4 du Code des postes et des communications électroniques). Pour les TLD sous contrat avec l'ICANN, cette obligation est dans le contrat entre l'ICANN et le registre. Vous pouvez trouver le nom du BE via les différents outils d'accès à l'information, cette information est publique.

Le choix d'un BE est une opération complexe, déroutante pour la ou le titulaire d'un nom de domaine. Et on peut être amené à changer de BE, par exemple pour des raisons tarifaires. Ainsi, je transfère en ce moment mes domaines personnels, l'ancien BE, qui était une entreprise indépendante, ayant été racheté par un grand groupe qui a immédiatement considérablement augmenté les tarifs. (Problème courant quand une petite entreprise est rachetée par un grand groupe : celui-ci se dépêche de supprimer tout ce qui faisait l'intérêt de la petite entreprise pour les clients. On a vu cela avec Capitaine Train, par exemple.) Ces noms de domaine ont deux particularités :

• L'hébergeur DNS, c'est moi. Je n'utilise pas, ni avant le transfert, ni après, les services d'hébergement DNS que fournissent la plupart des BE. Il n'y a donc pas de données DNS à transférer, les serveurs faisant autorité restent les mêmes.
• Les domaines sont signés avec DNSSEC.

Outre les contraintes techniques, le transfert est une opération délicate puisque les deux BE, le perdant et le gagnant, sont a priori des concurrents et que certains BE perdants font preuve d'une extrême mauvaise volonté, essayant de retenir de force leur client par tous les moyens. Le transfert est donc piloté par le BE gagnant, puisqu'il est le plus motivé à ce que l'opération réussisse. Et, pour compliquer encore la question, il faut noter qu'il y a un problème de sécurité : un transfert peut être malveillant, par exemple parce qu'un méchant essaie de détourner un nom de domaine à son profit.

Les règles qui encadrent le transfert d'un nom de domaine varient selon les registres. Durant ma migration, j'ai transféré du .org, du .net et du .fr.

Le cheminement normal est le suivant :

• Le ou la titulaire est prudent, teste qu'ielle a bien tous les éléments (mots de passe, etc) et ne commence pas le transfert la veille d'un jour où il faut absolument que le nom de domaine marche. N'attendez pas non plus le dernier moment avant l'expiration. Vouloir grapiller quelques euros peut vous coûter cher.
• La ou le titulaire du nom va sur l'interface Web du futur BE, le gagnant (ou bien utilise l'API de ce BE) et demande le transfert d'un nom. On paie ce transfert.
• Pour des raisons de sécurité évidentes, ce n'est pas fait immédiatement et automatiquement. Des mesures de sécurité sont appliquées.
• Une fois le transfert validé, le registre met à jour sa base de données, indiquant le nouveau BE, et le titulaire est prévenu (typiquement par courrier).

Voici la demande faite auprès d'un BE gagnant (ici, Netim) :

Ensuite, comme je l'ai dit, il faut s'assurer que la demande de transfert n'est pas en fait une tentative de détournement du nom de domaine. La principale mesure de sécurité est nommée, selon les BE, code d'autorisation, clé d'autorisation, code de transfert, auth code, authInfo… C'est un mot de passe qui a été généré par l'ancien BE et transmis au registre, et qui, indiqué par le titulaire au nouveau BE, permet de vérifier que la demande est légitime. (Si vous êtes fana de technique et de sécurité, le RFC 9154 propose une technique alternative.) Voici ici l'obtention de ce code sur l'ancien BE (ici, Gandi). Je vous rassure, le code affiché n'est plus le bon :

Il existe d'autres façons de transmettre ce mot de passe au titulaire, par exemple par courrier électronique, ce qui permet de valider l'adresse mais expose à pas mal de risques de sécurité. La sécurité, ce n'est de toute façon jamais simple et il faut rappeler que, s'il y a des BE qui tentent de gêner les transferts sortants, en invoquant la sécurité, il y a également des malveillants qui tentent de profiter d'une sécurité trop faible pour détourner un nom. Un compromis est donc nécessaire.

Typiquement, vous recevez une notification du BE perdant vous informant de la demande de transfert, ce qui peut permettre de s'y opposer, si elle n'était pas légitime. En effet, pour éviter qu'un BE de mauvaise volonté ne bloque le transfert indéfiniment en ne donnant pas accès au code d'autorisation, le transfert est typiquement effectué automatiquement au bout d'un certain temps. Faites donc bien attention aux messages de votre BE ! Et rappelez-vous qu'il y a autant de transferts légitimes retardés ou bloqués par des procédures kafkaïennes qu'il y a de domaines détournés parce que les procédures de sécurité étaient insuffisantes. J'en profite pour insister sur ce point : gérez vos noms de domaines. Que vous soyez particulier, profession libérale, association, petite entreprise, pensez à désigner plusieurs personnes responsables qui vont recevoir les messages du BE et les lire, et agir. Vous trouvez facilement en ligne d'innombrables témoignages de gens qui ont perdu leur nom de domaine par négligence.

Voici un exemple de message reçu de l'ancien BE (ici, Gandi) :

Subject: [GANDI] IMPORTANT: Transfert sortant vers un autre prestataire du  domaine sources.org
From: no-reply@gandi.net
To: [Moi]
Date: Mon, 01 Sep 2025 13:50:47 -0000
X-Mailer: Gandi Notification Mailer v1.2.12

Vous êtes contacté car vous êtes inscrit comme contact du nom de domaine suivant.

A l'attention de : Stéphane Bortzmeyer

Transfert du domaine: sources.org

Registrar demandeur: <NETIM SARL>

GANDI a été notifié d'une demande de transfert pour ce nom de domaine.

GANDI a reçu à la date 2025-09-01 13:44:18Z une notification selon
laquelle vous avez demandé le transfert de ce nom de domain vers un
autre bureau d'enregistrement.

Si vous souhaitez poursuivre le transfert, vous n'avez pas besoin de
répondre à cette notification. Faute de réponse de votre part avant le
2025-09-06 13:44:18, le transfert sera automatiquement validé.

Vous pouvez cependant accélérer ou refuser le transfert, en vous
rendant à cette adresse avant le 2025-09-06 13:44:18: [URL où il
faudra taper le code d'autorisation].

Vérifiez ensuite avec un RDDS que le domaine a bien été transféré. Ici, on va utiliser le classique client whois :

% whois cyberstructure.fr
…
domain:                        cyberstructure.fr
status:                        ACTIVE
…
registrar:                     NETIM

Parfait, le domaine est bien passé chez Netim.

Revenons à la technique : pensez à vérifier (avec des outils comme Zonemaster et DNSviz) le domaine après le transfert. J'ai vu par exemple un BE qui, lors d'un transfert entrant, limitait le nombre de serveurs faisant autorité à cinq et supprimait silencieusement les autres. Un exemple avec dig, où on interroge un des serveurs faisant autorité pour .fr :

% dig @d.nic.fr cyberstructure.fr NS
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 18712
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 9, ADDITIONAL: 1
…
;; AUTHORITY SECTION:
cyberstructure.fr.	3600 IN	NS fns1.42.pl.
cyberstructure.fr.	3600 IN	NS ns4.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS fns2.42.pl.
cyberstructure.fr.	3600 IN	NS ns2.afraid.org.
cyberstructure.fr.	3600 IN	NS puck.nether.net.
cyberstructure.fr.	3600 IN	NS ns2.bortzmeyer.org.
cyberstructure.fr.	3600 IN	NS ns1.bortzmeyer.org.

Et vérifiez que la liste des serveurs faisant autorité pour votre domaine est la bonne. (Attention, la mise à jour des serveurs du domaine parent peut ne pas être immédiate ; pour .fr, à l'heure actuelle, c'est toutes les dix minutes.)

Et DNSSEC ? Vous avez peut-être remarqué, sur l'image où le BE perdant affichait le code d'autorisation, un avertissement sur DNSSEC. La sécurité supplémentaire qu'apporte DNSSEC se paie d'une complication supplémentaire pendant le transfert : si on utilise le BE comme hébergeur (ce n'est pas mon cas), il faut, soit assurer le passage d'une clé DNSSEC à une autre (ce qui, étant donné le fait que les résolveurs DNS mémorisent des informations, va nécessiter la publication simultanée de deux clés, et une collaboration étroite entre les deux BE, dont je rappelle qu'ils sont concurrents), soit supprimer DNSSEC temporairement, ce que conseille ici le BE. Dans mon cas, comme je suis mon propre hébergeur, il n'y a pas trop de problèmes, à part qu'entre Gandi et Netim, l'enregistrement DS (Delegation Signer) a été supprimé lors du transfert (chaque BE dit que c'est de la faute de l'autre) et qu'il a donc fallu le rétablir ensuite (voyez ci-dessus le point sur l'importance d'un test technique après transfert).

Voilà, dans mon cas, les choses se sont plutôt bien passées, il n'y a pas eu de blocage, et les transferts ont été bouclés en une heure ou deux. Il me reste à transférer le domaine de ce blog bortzmeyer.org, que j'ai gardé pour la fin ; la méthode de bon sens est en effet de commencer par les domaines les moins importants.

Annoncé officiellement le 7 octobre, Cascade est le successeur d'OpenDNSSEC. Ce programme sert à gérer automatiquement les opérations répétitives liées à DNSSEC comme la re-signature ou le remplacement d'une clé. (Notez que Cascade évolue vite en ce moment et que cet article ne sera pas mis à jour. J'en écrirai d'autres.)

OpenDNSSEC est, depuis 15 ans, le logiciel utilisé par mes domaines personnels (comme bortzmeyer.org par lequel vous êtes passé pour voir cet article) mais aussi par plusieurs TLD comme .fr. Mais il est désormais en fin de vie (cela a été annoncé le 3 octobre), il n'y a plus que les mises à jour de sécurité. La même organisation, NLnet Labs, a développé un successeur, Cascade. Celui-ci est actuellement en alpha (ne l'utilisez pas pour la production !) et voici un premier essai.

DNSSEC, contrairement à ce qui se passe avec le DNS d'antan, nécessite des actions périodiques. La plus évidente est la re-signature, car les signatures DNSSEC ont une date d'expiration (pour éviter les attaques par rejeu). Ici, cette signature expire le 18 octobre 2025 (le « 20251018235702 ») :

% dig  +dnssec  cyberstructure.fr TXT 
…
;; ANSWER SECTION:
cyberstructure.fr.	86400 IN TXT "v=spf1 mx -all"
cyberstructure.fr.	86400 IN RRSIG TXT 13 2 86400 (
				20251018235702 20251004235301 34065 cyberstructure.fr.
				Hg/ModpW3pTLgUIcgp7yrVUxUyVAXdEIOtfONpN3pxG0
                                …

  

Mais il y a aussi la nécessité de pouvoir changer les clés cryptographiques utilisées, par exemple en cas de compromission, avérée ou suspectée. (La plupart des organisations changent les clés systématiquement, compromission ou pas, notamment pour être sûr de pouvoir le faire sans incident le jour où ça sera vraiment indispensable.) Cascade, comme OpenDNSSEC avant lui, automatise toutes ces tâches.

Cascade est développé en Rust, le langage à la mode, et qui pourrait remplacer une bonne partie du logiciel d'infrastructure de l'Internet, qui est quasi-uniquement en C (et C++). Il doit son nom au fait qu'une zone DNS qu'on va signer passe par plusieurs étapes successives, où on peut insérer différentes opérations, par exemple de validation.

Jouons donc un peu avec Cascade (j'ai bien dit que c'était en version alpha ; ne le faites pas en production). Notez que vous pouvez lire la documentation officielle au lieu de cet article. Mais j'ai bien dit que le logiciel était en version alpha, ne vous étonnez pas s'il manque beaucoup de choses dans la documentation (et dans le code, bien sûr). Il existe déjà des paquetages tout faits (mais évidemment pas encore distribués avec votre système d'exploitation) mais on va compiler, c'est plus amusant. Il faut donc une version de Rust qui marche. Rust est très pénible, avec ses changements permanents, qui font que certain·es conseillent même de récupérer et d'installer automatiquement une nouvelle version du compilateur chaque nuit. Mais, bon, la version qui est dans Debian stable (la version 13 de Debian) marche bien. Cascade est un logiciel libre, et il est hébergé sur GitHub :

% git clone https://github.com/NLnetLabs/cascade.git
…

# Installer les dépendances
% apt install cargo pkg-config libssl-dev
…

% rustc --version 
rustc 1.85.0 (4d91de4e4 2025-02-17) (built from a source tarball)

% cd cascade

% cargo build
…
  

Et vous n'avez plus qu'attendre que votre machine compile quelques centaines de crates Rust. Vous vous retrouvez alors avec deux exécutables, ./target/debug/cascade et ./target/debug/cascaded. Le second est le démon qui va tourner en permanence. (Si vous venez d'OpenDNSSEC, notez qu'il n'y a cette fois qu'un seul démon.) Notez que ce démon, bien qu'il inclue un serveur DNS minimal, ne doit pas être exposé sur l'Internet. La configuration recommandée est de l'utiliser comme serveur maitre caché, sur lequel s'alimenteront un ou plusieurs des serveurs faisant autorité pour vos domaines. (Si vous venez d'OpenDNSSEC, notez que Cascade ne sait actuellement pas écrire la zone sur le disque, il faut faire un transfert de zones, cf. RFC 5936.) Le premier exécutable, lui, est le programme que vous lancez pour accomplir telle ou telle tâche, et qui parle au démon, qui fera le boulot.

Sinon, une autre solution, pour compiler, est de suivre les instructions :

cargo install --locked --git https://github.com/nlnetlabs/cascade
cargo install --locked --branch keyset --git https://github.com/nlnetlabs/dnst

Et les exécutables atterriront dans votre ~/.cargo/bin.

Regardons les options des deux programmes :

% ./target/debug/cascade
Usage: cascade [OPTIONS] <COMMAND>

Commands:
  config    Manage Cascade's configuration
  zone      Manage zones
  policy    Manage policies
  keyset    Execute manual key roll or key removal commands
  hsm       Manage HSMs
  template  Print example config or policy files

Options:
  -s, --server <IP:PORT>   The cascade server instance to connect to [default: 127.0.0.1:4539]
      --log-level <LEVEL>  The minimum severity of messages to log [default: warning] [possible values: trace, debug, info,
                           warning, error, critical]
  -h, --help               Print help
  -V, --version            Print version



% ./target/debug/cascaded -h
Usage: cascaded [OPTIONS]

Options:
      --check-config
          Check the configuration and exit
      --state <PATH>
          The global state file to use
  -c, --config <PATH>
          The configuration file to load
      --log-level <LEVEL>
          The minimum severity of messages to log [possible values: trace, debug, info, warning, error, critical]
  -l, --log <TARGET>
          Where logs should be written to [possible values: stdout, stderr, file:<PATH>, syslog]
  -d, --daemonize
          Whether Cascade should fork on startup
  -h, --help
          Print help
  -V, --version
          Print version

Si vous avez procédé comme moi, un dernier truc à compiler, il nous faut aussi cascade-dnst, par la même organisation :

%   cargo install --locked --branch keyset --git https://github.com/nlnetlabs/dnst
 

Vérifiez bien que les exécutables sont dans votre PATH (par exemple, que ~/.cargo/bin y soit). Pour le démon, vous pouvez aussi utiliser la variable dnst-binary-path dans le config.toml.

Pour utiliser Cascade, vous devrez, comme avec OpenDNSSEC, définir une politique (quel algorithme de cryptographie, quelle durée de vie des signatures, quand remplacer les clés, etc), indiquer quelles zones Cascade doit gérer, et avoir un serveur faisant autorité qui va récupérer la zone sur Cascade.

Maintenant, configurons le logiciel, toujours en suivant la documentation. (Si vous oubliez cette étape, vous aurez un message « Cascade couldn't be configured: could not load the config file '/etc/cascade/config.toml': No such file or directory (os error 2) ».) Vous avez avec Cascade un fichier de configuration d'exemple, ./etc/config.template.toml, à la syntaxe TOML. Le fichier d'exemple peut être utilisé tel quel dans beaucoup de cas. J'ai juste modifié les paramètres de journalisation :

[daemon]
log-level = "debug"
log-target = { type = "file", path = "/dev/stdout"}
# Mais log-target = { type = "syslog" } est bien aussi.
 

Lançons maintenant le démon (voyez plus loin les mécanismes pour l'avoir en permanence). D'abord, on crée les répertoires configurés dans le config.toml :

% sudo mkdir /var/lib/cascade     
% sudo chown $USER /var/lib/cascade

% sudo mkdir /etc/cascade/policies 
  

Puis on y va :

% ./target/debug/cascaded         
[2025-10-09T15:56:07.480Z] INFO cascaded: State file not found; starting from scratch
…
[2025-10-09T15:56:09.182Z] DEBUG cascade::state: Saved the global state (to '/var/lib/cascade/state.db')
…

Maintenant que le démon tourne, testons le programme de contrôle :

% ./target/debug/cascade zone list
%
  

Pas de message d'erreur, mais pas de zones configurées, c'est normal. (Si le démon ne tournait pas, vous auriez eu «  [2025-10-09T15:59:37.183Z] ERROR cascade: Error: HTTP request failed: error sending request for url (http://127.0.0.1:4539/zone/) ».)

Maintenant, il faut créer une politique. La plus courte est :

version = "v1"

mais elle n'est pas très utile. Pour avoir un point de départ, on va demander à Cascade de nous générer un exemple :

%    ./target/debug/cascade template policy  > mypolicy.toml
  

(On peut aussi utiliser l'exemple en etc/policy.template.toml.) La politique contient l'algorithme de cryptographie utilisé (j'ai choisi Ed25519, cf. RFC 8080) :

algorithm = "ED25519"                                                    
  

Je n'ai rien changé d'autre. On copie le fichier en /etc/cascade/policies/default.toml (on peut évidemment avoir plusieurs politiques, je vous laisse choisir les noms). Et on indique à Cascade de la charger (ce n'est à faire qu'une fois, ce sera mémorisé) :

% ./target/debug/cascade policy reload      
Policies reloaded:
- default added

% ./target/debug/cascade  policy list  
default

% ./target/debug/cascade policy show default
default:
  zones: <none>
…
  signer:
    serial policy: date counter
    signature inception offset: 86400 seconds
    signature validity offset: 1209600 seconds
    denial: NSEC
…
    
  

Bon, on peut maintenant ajouter une zone à gérer. On crée un fichier de zone (je l'ai mis dans /etc/cascade/zones mais vous faites comme vous voulez). Et on dit à Cascade d'y aller, en indiquant la politique à suivre :

% ./target/debug/cascade zone add --source /etc/cascade/zones/rutaba.ga --policy default rutaba.ga
Added zone rutaba.ga
   

Et voilà :

% ./target/debug/cascade zone list
rutaba.ga

% ./target/debug/cascade zone status rutaba.ga
Status report for zone 'rutaba.ga' using policy 'default'
✔ Waited for a new version of the rutaba.ga zone
✔ Loaded version 2025100901
  Loaded at 2025-10-09T16:40:36+00:00 (17s ago)
  Loaded 246 B and 5 records from the filesystem in 0 seconds
✔ Auto approving signing of version 2025100901, no checks enabled in policy.
✔ Approval received to sign version 2025100901, signing requested
✔ Signed version 2025100901 as version 2025100902
  Signing requested at 2025-10-09T16:40:36+00:00 (17s ago)
  Signing started at 2025-10-09T16:40:36+00:00 (17s ago)
  Signing finished at 2025-10-09T16:40:36+00:00 (17s ago)
  Collected 5 records in 0s, sorted in 0s
  Generated 4 NSEC(3) records in 0s
  Generated 5 signatures in 0s (5 sig/s)
  Inserted signatures in 0s (5 sig/s)
  Took 0s in total, using 1 threads
  Current action: Finished
✔ Auto approving publication of version 2025100902, no checks enabled in policy.
✔ Published version 2025100902
  Published zone available on 127.0.0.1:4543
   

(L'option --detailed après status vous donnera… des détails.)

Vous pouvez maintenant récupérer la zone signée :

    
%  dig @localhost -p 4543 rutaba.ga AXFR
…
rutaba.ga.		600 IN SOA ns4.bortzmeyer.org. hostmaster.bortzmeyer.org. (
				2025100902 ; serial
…
rutaba.ga.		3600 IN	DNSKEY 257 3 15 (
				oQjxu7aDwhDyqZbqPfx0e3I4Y+UowV0eYlssuXgiMw0=
				) ; KSK; alg = ED25519 ; key id = 57782
…
rutaba.ga.		600 IN NS ns4.bortzmeyer.org.
rutaba.ga.		600 IN NS ns1.bortzmeyer.org.
…
rutaba.ga.		600 IN RRSIG SOA 15 2 600 (
				20251023164036 20251008164036 64849 rutaba.ga.
				xn3KC4qzitoUz5ABlJDTtMd9VGPU2l8dYpsd4bYjeCqo
				vpjBdWcBbwwk1HENj5ESCLEIobpjNS3/rA4qidUvCg== )
rutaba.ga.		600 IN RRSIG NS 15 2 600 (
				20251023164036 20251008164036 64849 rutaba.ga.
				gWrzM1jYO7GJ234bH8JDejrxMhwtHrGWjxRM30gz37Fb
				dxnSv2/DiAgOt5OhdTPKYc7+IX4gLR1DPAUlJgXqDA== )
rutaba.ga.		600 IN RRSIG DNSKEY 15 2 3600 (
				20251023163739 20251008163739 57782 rutaba.ga.
				t3wZ31rY7TgXY+QZXd/Yy7QtTmYdJy6v7Kuj6IN8G+m4
				GycTLLn9W3lXErMS7f93RfkvXfERrwzbHqrTp1/oDg== )
…
;; Query time: 1 msec
;; SERVER: ::1#4543(localhost) (TCP)
;; WHEN: Thu Oct 09 16:43:24 UTC 2025
;; XFR size: 15 records (messages 1, bytes 1201)

  

(On verra plus loin comment configurer le « vrai » serveur de noms pour utiliser cette zone.)

Comme OpenDNSSEC, Cascade regarde sa montre pour savoir si un délai suffisant s'est écoulé (rappelez-vous que les résolveurs DNS ont une mémoire, et que cela a une grande importance opérationnelle ; dans le DNS, rien n'est jamais instantané). Mais, contrairement à OpenDNSSEC, il demande au résolveur local des tests (à l'heure actuelle, la machine qui fait tourner Cascade doit donc avoir accès à un résolveur qui marche). En attendant, cascade zone status --detailed vous affichera des choses comme :

      Roll AlgorithmRoll, state Propagation1:
    	Wait until the new DNSKEY RRset has propagated to all nameservers.
    	Try again after 2025-10-09T16:47:42Z

Voyons plutôt une fonction essentielle de Cascade : les étapes de validation. Pour l'instant, je n'en ai configuré aucune. Mais, en production, on veut éviter à tout prix ces ennuyeuses erreurs, qui plantent DNSSEC et toute la zone. On va donc forcément valider la zone signée avant de la publier. Le principe est d'écrire un programme (typiquement un script shell) qui va lancer un programme de validation comme validns ou le dnssec-verify de BIND. On peut avoir cette étape de validation avant la signature (pour tester le fichier de zone original) ou après (ce que je fais ici). Essayons pour commencer avec un script de validation méchant qui refuse tout :

% cat /etc/cascade/reviews/always-reject.sh
#!/bin/sh

logger "Rejecting ${CASCADE_ZONE} of serial ${CASCADE_SERIAL} from ${CASCADE_SERVER}"

♯ Cascade va utiliser le code de retour pou savoir si la zone est
# validée ou pas.
exit 1

On configure la politique (pas la configuration générale : valider ou pas fait partie de la politique) :

% cat /etc/cascade/policies/default.toml
…
# How signed zones are reviewed.
[signer.review]

required = true

cmd-hook = "/etc/cascade/reviews/always-reject.sh"
  

On recharge la politique (cascade policy reload) et la validation est configurée (Cascade étant en version alpha, pour l'instant, il faut redémarrer le démon mais ce n'est pas normal). Le résultat est l'attendu :

% ./target/debug/cascade zone status rutaba.ga     
…
• Waiting for approval to publish version 2025101004
  Configured to invoke /etc/cascade/reviews/always-reject.sh
x An error occurred that prevents further processing of this zone version:
x Signed zone was rejected at the review stage.

Et dans le journal du démon :

[2025-10-10T06:32:49.335Z] INFO cascade::units::zone_server: [RS2]: Executed hook '/etc/cascade/reviews/always-reject.sh' for signed zone 'rutaba.ga' at serial 2025101004
[2025-10-10T06:32:49.339Z] DEBUG cascade::units::zone_server: [RS2]: Hook '/etc/cascade/reviews/always-reject.sh' exited with status exit status: 1
[2025-10-10T06:32:49.339Z] DEBUG cascade::targets::central_command: [CC]: Event received: ReviewZone { name: Name(rutaba.ga.), stage: Signed, serial: Serial(2025101004), decision: Reject }
…
[2025-10-10T06:32:49.339Z] DEBUG cascade::targets::central_command: [CC]: Event received: SignedZoneRejectedEvent { zone_name: Name(rutaba.ga.), zone_serial: Serial(2025101004) }

Écrivons maintenant un script plus sérieux. Il va obtenir la zone à valider via un transfert de zones. Notez que le port utilisé est obtenu via une variable d'environnement ; Cascade sert la zone sur des ports différents selon qu'elle a été validée ou pas (cf. les paramètres servers dans config.toml). Donc, le « vrai » serveur, présenté plus loin, n'utilisera pas le même port. Voici le script de validation utilisable en production :

% cat /etc/cascade/reviews/validate-signed.bash 
#!/bin/bash

# Yes, bash is required, to parse CASCADE_SERVER

set -e

logger -p daemon.notice -t cascade "Validating ${CASCADE_ZONE} of serial ${CASCADE_SERIAL} from ${CASCADE_SERVER}"

# Parsing magic by mozzieongit
SERVER=${CASCADE_SERVER%:*}
SERVER_IP="${SERVER//[\[\]]/}" # remove brackets from IPv6
SERVER_PORT=${CASCADE_SERVER##*:} # Using double '##' in case its an IPv6

tmp_zone=$(mktemp /tmp/.cascade_zone.XXXXXXXXXX)
# Clean when leaving
trap  "rm -f ${tmp_zone}; exit 1" 1 2 3 15
trap  "rm -f ${tmp_zone}" EXIT

# Too bad dig logs some errors on standard output :-(
dig @${SERVER_IP} -p ${SERVER_PORT} ${CASCADE_ZONE} AXFR > ${tmp_zone}

# validns does not handle Ed25519
# validns -z ${CASCADE_ZONE} -p all ${tmp_zone}
# or:
dnssec-verify -q -o ${CASCADE_ZONE} ${tmp_zone}
# Or:
# ldns-verify ${tmp_zone}

# Le code de retour du programme de vérification va être celui du script.
  

Et la zone est acceptée :

[2025-10-10T07:01:01.462Z] DEBUG cascade::units::zone_server: [RS2] Received command: SeekApprovalForSignedZone { zone_name: Name(rutaba.ga.), zone_serial: Serial(2025101001) }
[2025-10-10T07:01:01.462Z] INFO cascade::units::zone_server: [RS2]: Seeking approval for signed zone 'rutaba.ga' at serial 2025101001.
[2025-10-10T07:01:01.463Z] INFO cascade::units::zone_server: [RS2]: Executed hook '/etc/cascade/reviews/validns.sh' for signed zone 'rutaba.ga' at serial 2025101001
[2025-10-10T07:01:01.485Z] INFO domain::net::server::middleware::cookies: preprocess; request_ip=127.0.0.1
[2025-10-10T07:01:01.485Z] INFO domain::net::server::middleware::xfr::service: AXFR for rutaba.ga from 127.0.0.1:35159
[2025-10-10T07:01:01.498Z] DEBUG cascade::units::zone_server: [RS2]: Hook '/etc/cascade/reviews/validns.sh' exited with status exit status: 0
[2025-10-10T07:01:01.498Z] DEBUG cascade::targets::central_command: [CC]: Event received: ReviewZone { name: Name(rutaba.ga.), stage: Signed, serial: Serial(2025101001), decision: Approve }
[2025-10-10T07:01:01.498Z] INFO cascade::targets::central_command: [CC]: Passing back zone review

Bon, maintenant, configurons un « vrai » serveur de noms pour charger la zone et la servir à tous les résolveurs de l'Internet. J'utilise nsd. Dans le nsd.conf, je mets :

zone:
      name: "internautique.fr"
      zonefile: "/var/lib/nsd/%s.zone"
      request-xfr: AXFR 127.0.0.1@8053 NOKEY
      allow-notify: 127.0.0.1 NOKEY
      # Mettre ici les autres serveurs faisant autorité, qu'il faut notifier et autoriser. 

On va autoriser 127.0.0.1 (la machine locale, où tourne Cascade) à nous notifier les changements de la zone signée, et on demandera les transferts de zone à cette même machine, sur le port où écoute Cascade (ici 8053). nsd va alors charger la zone, éventuellement notifier les autres serveurs faisant autorité et tout roule.

Si vous connaissez DNSSEC, vous avez vu qu'il manque une étape : ajouter l'enregistrement DS (Delegation Signer) dans la zone parente. Cascade n'affiche pas ce DS tout de suite, il sait que les résolveurs ont une mémoire et il attend d'avoir vu la zone signée publiée et que la durée configurée soit écoulée. En version alpha, cette étape ne marche pas toujours donc on va le faire à la main (ne le faites pas en production !) :

    
% dig @127.0.0.1 -p 8053 AXFR internautique.fr > /tmp/internautique.fr

% dnssec-dsfromkey -f /tmp/internautique.fr internautique.fr
internautique.fr. IN DS 30790 15 2 BB8987B69144BFB6863D9F86983EE1FB465629CDB3EE8DC43EE6B7C11056598F

Et c'est ce DS qu'on va transmettre à la zone parente (peut-être via son BE). Les programmes de test disponibles en ligne montrent une configuration (presque) correcte : Zonemaster et DNSviz.

Avant-dernière chose à faire : faire tourner le démon en permanence sur la machine. Cascade vient avec un fichier de configuration pour systemd mais une bogue subtile l'empêche actuellement de fonctionner. J'ai donc utilisé un plus classique script rc.local :

% cat /etc/boot.d/cascade
#!/bin/sh

# You may change this one:
DEBUG=1

set -e 

# Don't touch
export PATH=${PATH}:/home/cascade/.cargo/bin

if [ ${DEBUG} -ge 1 ]; then
   DAEMON_OPTS="--log-level debug"
   export RUST_BACKTRACE=full
else
    DAEMON_OPTS="--log-level info"
fi
   
# Does not work with su (for unknown reasons): "Permission denied"
sudo -E -u cascade /home/cascade/.cargo/bin/cascaded --daemonize ${DAEMON_OPTS} --state=/var/lib/cascade/state.db --config=/etc/cascade/config.toml
# su -p cascade -c '/home/cascade/.cargo/bin/cascaded --state=/var/lib/cascade/state.db --config=/etc/cascade/config.toml'

Enfin, quand on sera en production, il faudra évidemment superviser Cascade. J'utilise un petit script qui suit l'API Nagios :

% cat /usr/local/lib/nagios/plugins/check_cascade
#!/bin/sh

# Simple Nagios/Icinga plugin for Cascade. 

USAGE="Usage: $0 -e string_to_expect"

TEMP=$(getopt -o "e:h" -- "$@")
if [ $? != 0 ]; then
    echo $USAGE
    exit 1
fi

eval set -- "$TEMP"

while true ; do
    case "$1" in
	-e) EXPECTED=$2; shift 2;;
	-h) echo $USAGE; exit 3;;
	--) shift ; break ;;
	*) echo "Internal error!"; exit 3 ;;
    esac
done

logger "Test Cascade, expect \"${EXPECTED}\""

E_OUT=$(/home/cascade/.cargo/bin/cascade zone list 2>/dev/null)

if [ $? -ne 0 ];
then
    echo "Cascade did not respond"
    exit 2
fi

if [ ! -z "${EXPECTED}" ]; then
    L_CNT=$(echo ${E_OUT} | grep "${EXPECTED}" 2>/dev/null | wc -l)
    if [ ${L_CNT} -eq 0 ]; then
	echo "Cascade zone list did not return a match on ${EXPECTED}"
	exit 2
    fi
fi

echo "Cascade OK ${S_OUT}"
exit 0

Et qui se configure comme cela dans Icinga :

object CheckCommand "cascade" {          
  command = [ PluginContribDir + "/check_cascade" ]       
  arguments = {                 
      "-e" = "$cascade_expect$", 
    } 
}
                                           
object Host "ayla-cascade" {  
  import "generic-host"   
  check_command = "remote_always_true"  
  vars.cascade = true   
  vars.cascade_expect="internautique\\.fr" 
}        

Et en conclusion, un peu d'opéra, avec l'air « Cascader la vertu » de La Belle Hélène, interprété par Gaëlle Arquez.

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 http://monlycee.net/ marchait, pas http://monlycée.net/ (avec l'accent sur le E). C'est désormais réparé.

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 https://peertube.monlycee.net/ fonctionne, pas https://peertube.monlycée.net/ (nom non existant). On retombe dans le problème de communication cité plus haut.

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.

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) :

• Ne pas utiliser de paquetage du tout, compiler OpenDNSSEC moi-même et l'installer sur les machines via d'autres modules Ansible qui permettent de copier exécutables et fichiers de configuration. Pas pratique ; cela fait perdre un des gros avantages de l'utilisation de Debian, son excellent système de paquetages.
• Utiliser le successeur d'OpenDNSSEC (qui est officiellement retiré), Cascade. Pas de paquetage (donc on revient au point précédent) et, en plus, Cascade est loin d'être utilisable.
• Utiliser la version unstable de Debian au lieu de la stable. Pour des travaux pratiques dans une formation, le risque d'utiliser unstable est moins grave qu'en production mais, quand même, je ne voudrais pas qu'un problème surgisse pendant les exercices.
• Créer un paquetage Debian sur une machine stable (en utilisant le source du paquetage de unstable), le copier vers les machines virtuelles et l'installer avec 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.

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.

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.

Autres articles sur cet événement :

• « Infini à Pas Sage En Steïr 2025 »,
• « Tour des GULL : étape 13 - Pas Sage en Steir ».

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):

• Develop a (very small, and very minimum don't be afraid) domain name registry, with a pseudo-RPP interface,
• Develop a client test suite.

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.)

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 :

• L'article de Martin Clavey dans Next.
• Un appel à sauver Afrinic face au dernier coup de force de Cloud Innovation.