Mon blog

J'ai acheté un mini-PC Shuttle Nano NE10N et cet article est là pour documenter cet appareil et parler du problème d'installation avec sa carte Ethernet.

Je voulais ce mini-PC pour un serveur à la maison, restant allumé en permanence. Mon cahier des charges était :

• Peut faire tourner Linux, de préférence Debian,
• Très silencieux (puisque allumé en permanence),
• Faible consommation électrique (puisque allumé en permanence),
• Au moins 100 Go de disque et 2 Go de RAM (le processeur n'est pas important, un ARM aurait parfaitement convenu),
• Ethernet (pas besoin de Wifi). Et cela a été le plus gros problème lors de l'installation.

En outre, je souhaitais :

• Pas sur Amazon ou AliExpress,
• Peu encombrant (bon, c'est le principe du mini-PC),
• Pas de ventilateur,
• Vendu sans Windows pour ne pas payer de licence,
• Dans un seul boitier (pas de bricolage matériel nécessaire).

J'indiquerai plus tard quelques pistes que j'ai suivies. Mais d'abord, la machine.

Voici l'engin de face, de dos et l'intérieur :

Voici le matériel sur le bus PCI :

% lspci
00:00.0 Host bridge: Intel Corporation Alder Lake-N Processor Host Bridge/DRAM Registers
00:02.0 VGA compatible controller: Intel Corporation Alder Lake-N [UHD Graphics]
00:08.0 System peripheral: Intel Corporation GNA Scoring Accelerator
00:0a.0 Signal processing controller: Intel Corporation Platform Monitoring Technology (rev 01)
00:0d.0 USB controller: Intel Corporation Alder Lake-N Thunderbolt 4 USB Controller
00:14.0 USB controller: Intel Corporation Alder Lake-N PCH USB 3.2 xHCI Host Controller
00:14.2 RAM memory: Intel Corporation Alder Lake-N PCH Shared SRAM
00:16.0 Communication controller: Intel Corporation Alder Lake-N PCH HECI Controller
00:17.0 SATA controller: Intel Corporation Alder Lake-N SATA AHCI Controller
00:1c.0 PCI bridge: Intel Corporation Alder Lake-N PCI Express Root Port #4
00:1f.0 ISA bridge: Intel Corporation Alder Lake-N PCH eSPI Controller
00:1f.3 Audio device: Intel Corporation Alder Lake-N PCH High Definition Audio Controller
00:1f.4 SMBus: Intel Corporation Alder Lake-N SMBus
00:1f.5 Serial bus controller: Intel Corporation Alder Lake-N SPI (flash) Controller
01:00.0 Ethernet controller: Motorcomm Microelectronics. YT6801 Gigabit Ethernet Controller (rev 01)
  

Les caractéristiques du processeur sont en nano-ne10-cpu.txt et les messages de démarrage en nano-ne10-boot.txt.

La consommation électrique, mesurée par un wattmètre Chacon est de 5 W au calme et de 15 W quand la machine travaille à fond.

Où trouve-t-on cette machine ? Shuttle ne vend pas en direct. On peut trouver des machines chez des vendeurs en ligne mais je n'avais pas envie d'acheter chez des boites peu sympathiques et puis je voulais davantage de RAM et de disque que dans le cas de l'offre par défaut, et je n'avais pas envie de monter cela moi-même (ce qui aurait été assez facile, le boitier s'ouvre facilement et tout est accessible). Heureusement, des revendeurs de Shuttle rendent ce service. Si MisterOops n'a jamais répondu à mes demandes de devis, M2N a été très réactif et m'a rapidement livré un PC comme je voulais (« Shuttle XPC nano NE1000N Configurable (Sans Système d'exploitation, 8 Go DDR4, 500 Go SSD M.2 (SATA), Aucun) 1,00 Unité(s) »), après passage par le configurateur de Shuttle. (La bonne RAM serait de la DDR5, mais actuellement elle est hors de prix et peu disponible.)

J'avais demandé une machine sans système d'exploitation en me disant qu'il n'y avait pas de raison que l'installation pose des problèmes. J'ai téléchargé une image « netinst » (Network Installation) Debian, copié sur une clé USB avec cp debian.iso /dev/sdX quand soudain, le drame : « A driver for your hardware is not available. You may need to load drivers from removable media. Load missing drivers from removable media? ». L'installateur de l'actuelle version de Debian n'a en effet pas de pilote pour la carte Ethernet « YT6801 Gigabit Ethernet ». (Ah, comment on trouve le type de la carte et donc le pilote nécessaire ? Alt-F2 pour changer de console puis lspci.)

Je vous donne tout de suite la solution :

• Installer Debian sans le réseau en utilisant l'image dite « DVD » (pas sur un DVD, bien sûr, mais sur une clé USB de bonne capacité car l'image fait 3,7Go),
• Comme il va falloir installer des paquetages pour compiler un pilote, mettre dans /etc/apt/sources.list la ligne deb file:///mnt trixie main (où /mnt est l'endroit où vous montez la clé USB), puis apt update,
• Installer avec apt install build-essential kmod dpkg-dev build-essential patch linux-headers-6.12.48+deb13-amd64,
• Récupérer le pilote chez Tuxedo, wget https://deb.tuxedocomputers.com/debian/pool/main/t/tuxedo-yt6801/tuxedo-yt6801_1.0.30tux4_all.deb, et le mettre sur une clé USB,
• Récupérer le paquetage dkms, qui existe chez Debian, et est indispensable pour compiler proprement le pilote, mais n'est pas dans l'image d'installation, wget http://ftp.fr.debian.org/debian/pool/main/d/dkms/dkms_3.2.2-1~deb13u1_all.deb, et le mettre sur une clé USB,
• Installer les deux paquetages téléchargés (mettons que la clé USB ait été montée en /mnt2) avec apt install /mnt2/tuxedo-yt6801_1.0.30tux4_all.deb /mnt2/dkms_3.2.2-1~deb13u1_all.deb.

Le pilote va alors être compilé et installé, tout est bien qui finit bien, Ethernet marche.

% dpkg -l | grep yt6801
ii  tuxedo-yt6801                           1.0.29tux0                           all          Driver for Motorcomm YT6801

% lsmod | grep yt6801
yt6801                163840  0

% ip link show
…
2: enp1s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 38:f7:cd:ce:22:c6 brd ff:ff:ff:ff:ff:ff
    altname enx38f7cdce22c6

Cette approche est également documentée sur le forum de Linux Mint ou bien sur Reddit. Notez que ce pilote réseau fait débat, ce qui peut expliquer son absence de Debian.

Les autres machines que j'avais considérées :

• Le Trigkey Key-N150 (je ne me souviens même plus pourquoi je l'avais écarté),
• Les Raspberry Pi sont cools mais je préférais une solution toute intégrée, pas un SBC,
• Les Tuxedo étaient bien trop chers, trop haut de gamme (j'ai un portable de cette marque),
• Même chose pour le Slimbook,
• Le Geekom aussi est cher,
• Le BMax B5A Pro (16Go de RAM, 512Go de SSD, AMD Ryzen7 5825U) sur AliExpress (un utilisateur m'a raconté qu'il avait dû changer l'alimentation, défaillante),
• Le MiniPC Soyo M4 Plus Intel N150 (je crois que je ne l'avais trouvé que sur AliExpress),
• Le Beelink ME Pro, plutôt pour faire NAS que serveur mais, de toute façon, il ne semble pas encore sorti.

Vous avez aussi un test de la machine que j'ai achetée sur l'excellent site MiniMachines. Notez qu'ils sont sur le fédivers, en @[email protected].

Il y a beaucoup, mais vraiment beaucoup, de satellites au-dessus de nos têtes, notamment sur les orbites basses. Risquent-ils de se tamponner ? Oui, montre cette étude : en l'absence de réaction de leurs opérateurs, il y aurait une collision tous les 2,8 jours.

Le risque de collision entre satellites est connu depuis longtemps. Le cas le plus fameux est bien sûr la collision du 10 février 2009 (cf. le bilan récent « Subsequent Assessment of the Collision between Iridium 33 and COSMOS 2251 »). Les conséquences d'un choc direct sont évidemment la destruction des deux satellites mais le principal problème est surtout la nuée de débris ainsi créée, et les nombreuses collisions secondaires qu'elle peut entrainer. En cas d'éparpillement des satellites impliqués, l'orbite peut devenir inutilisable.

Mais l'espace est grand et un satellite est petit, non ? Les collisions devraient être rares. Ce serait le cas s'il y avait peu de satellites. Mais de nos jours, avec les méga-constellations, le nombre de satellites est tel que la probabilité de collision a sérieusement augmenté. Et puis un satellite en orbite basse fait beaucoup de tours de la Terre, augmentant le risque. C'est comme jouer à la roulette russe en essayant souvent.

Peut-on quantifier ce risque ? C'est ce que tente l'article « An Orbital House of Cards: Frequent Megaconstellation Close Conjunctions ». Les auteurices ont développé un indice, spirituellement appelé « CRASH clock » (pour Collision Realization And Significant Harm), exprimé sous forme d'une durée, et qui indique l'intervalle moyen entre collisions. Je vous laisse lire l'article pour les détails du calcul (comme toutes les modélisations, c'est compliqué et certains facteurs ne sont pas connus avec précision). Mais ce qui est inquiétant est le résultat : le CRASH clock qui était de 121 jours avant l'arrivée des méga-constellations est descendu à 2,8 jours, en grande partie grâce à Starlink.

Bon mais, en pratique, on ne voit pas de collision tous les 2,8 jours, non ? C'est parce que les opérateurs des satellites surveillent les environs et actionnent de temps en temps les moteurs pour s'éloigner d'un risque de collision. On ne voit donc pas souvent d'accident. Le risque est qu'un événement survienne qui empêche ces réactions pendant quelques jours. Les auteurices imaginent un problème logiciel important chez un des opérateurs, voire sur plusieurs, ou bien une crise socio-politique importante sur Terre, ou tout simplement une tempête solaire, qui pourrait perturber les communications pendant une durée significative par rapport au CRASH clock. (Le risque des tempêtes solaires n'est pas purement théorique.) Le CRASH clock indique donc ce qui se passerait lors d'un de ces événements. Les opérateurs de satellites ne peuvent pas se permettre une interruption de leur travail, même de seulement quelques heures.

En français, vous serez peut-être intéressé par cet article du CNES.

Vous le savez, j'ai expérimenté récemment l'outil de formatage de textes Typst. Un de ses intérêts est de disposer d'un langage pour réaliser des schémas, nommé Fletcher. Voici quelques points intéressants de Fletcher.

Fletcher est sur le même créneau que des systèmes comme Asymptote (que j'utilise jusqu'à présent), Graphviz ou TikZ : un langage pour décrire les schémas techniques, qui évite de passer du temps avec la souris en essayant de placer ses éléments de schémas au bon endroit. Fletcher est écrit avec le langage de programmation de Typst, et s'appuie sur le système CeTZ.

Sans plus tarder, un exemple de code en Fletcher :

#import "@preview/fletcher:0.5.8" as fletcher: diagram, node, edge

#diagram(
  {
    node([Un], stroke: 1pt)
    node((rel: (1, 1)), [Deux], stroke: 1pt)
    node((rel: (-1, 1)), [Trois], stroke: 1pt)
    edge(auto, auto, [Par ici], "->")
  }
)
  

Compilé avec typst compile --format png simple-fletcher-1.typ, il donne :

Voyons les détails :

• Il faut importer le paquetage Fletcher (il sera téléchargé la première fois qu'on compile).
• On dessine trois boites ; par défaut, la bordure est de taille nulle donc on demande une bordure d'un point.
• La première boite est, par défaut, placée à l'origine des coordonnées, les deux suivantes sont placées relativement à la boite précédente (l'axe des X va vers la droite, celui des Y vers le bas, ce qui est un peu déconcertant mais c'est documenté).
• On termine avec une flèche, sans s'embêter à indiquer où elle s'accroche donc elle est mise sur le dernier élément dessiné. Notez la façon d'indiquer la forme de la flèche, avec un exemple sous forme d'une chaine de caractères.

Maintenant, si on veut davantage de contrôle sur le placement, on va donner des noms aux objets (et puis on met des valeurs par défaut pour les boites) :

#import "@preview/fletcher:0.5.8" as fletcher: diagram, node, edge

#diagram(
 // Valeurs par défaut pour les nœuds
 node-stroke: 2pt,
 node-shape: fletcher.shapes.house,
 {
    node([Un], name: <un>)
    node((rel: (1, 1)), [Deux], name: <deux>)
    node((rel: (-1, 1), to: <un>), [Trois], name: <trois>)
    node((rel: (3, 4), to: <deux>), [Quatre], name: <quatre>) 
    edge(<un>, <deux>, [Par ici], "->")
  }
  )

  

Et cela donne :

Vous noterez, dans le deuxième essai :

• La boite Trois est désormais relative à la boite Un, pas à la dernière boite placée.
• L'image s'agrandit automatiquement (regardez la boite Quatre, qui est placée assez loin).
• La flèche est explicitement accrochée à deux des boites, et placée automatiquement au bon endroit.

Pour un exemple plus réaliste, je vous ai mis un schéma de la résolution DNS et un autre de l'arborescence des noms de domaine, avec le PDF (ce que produit Typst par défaut) et le source : fletcher-resolution-dns.pdf, fletcher-resolution-dns.typ, fletcher-arbre-domaines.pdf et fletcher-arbre-domaines.typ. La combinaison de coordonnées relatives, et de flèches qu'on accroche à des boites, sans se préoccuper de donner des coordonnées, est très agréable.

Voilà, bien sûr, Fletcher est beaucoup plus riche que cela et vous pouvez faire bien d'autres choses, n'hésitez pas à lire la très complète documentation.

Au Capitole du Libre de novembre 2025, j'ai suivi l'exposé de Patrick Massot sur Typst, un concurrent possible de LaTeX. Je ne suis pas un expert de Typst, je n'ai pas encore écrit de vrai texte avec donc ce qui suit est un résumé de l'exposé, agrémenté de quelques essais.

Typst est un compilateur de texte, un système où vous tapez du texte et du formatage avec un éditeur quelconque, texte qui sera ensuite traduit dans des formats de distribution comme PDF. Les avantages de ces compilateurs (ou formatteurs), comme noté par Patrick Massot, sont la reproductibilité, la possibilité de choisir librement son éditeur, la flexibilité, et la possibilité d'automatiser la production de documents. Typst est donc une alternative à LaTeX ou à Pandoc+Markdown. C'est évidemment un logiciel libre, sinon on n'en parlerait pas à Capitole du Libre. Il se veut plus perfectionné que Pandoc+Markdown (par exemple pour des documents complexes avec de la mathématique) et plus simple à utiliser que LaTeX, avec une syntaxe moins tordue (pas difficile) et des messages d'erreur plus clairs (pas difficile non plus).

Voici un très simple document (tant que ça reste aussi simple, la syntaxe ressemble vaguement à Markdown) :

= J'essaie Typst

Ça marche. Je peux *insister* ou faire des listes :

+ liberté
+ égalité
+ fraternité

== Des maths

$E = m c^2$

== Du texte plus long

#text(red)[
On peut colorier.
]

J'ai pas envie de tout taper. #lorem(100)
  

On le compile :

% typst compile essai.typ
  

Et on obtient un PDF.

Comme promis, les messages d'erreur sont clairs et précis, grosse différence avec LaTeX :

% typst compile essai.typ
error: unclosed delimiter
   ┌─ essai.typ:15:9
   │
15 │ #set text(
   │          ^
  

Si on veut de l'HTML (option actuellement présentée comme expérimentale et, comme vous le verrez dans l'exemple suivant, la mathématique n'est pas traitée) :

% typst compile --features html --format html essai.typ
warning: html export is under active development and incomplete
 = hint: its behaviour may change at any time
 = hint: do not rely on this feature for production use cases
 = hint: see https://github.com/typst/typst/issues/5512 for more information

warning: equation was ignored during HTML export
   ┌─ essai.typ:11:0
   │
11 │ $e = m c^2$
   │ ^^^^^^^^^^^
  

Aucun CSS n'est produit, le texte en rouge n'est donc pas colorié. Bref, la production de HTML est à l'heure actuelle très limitée. Pour cela, Pandoc est une meilleure solution, car il sait lire le Typst, même les formules mathématiques :

% pandoc -i essai.typ -o essai.html
  

Typst dispose d'innombrables autres possibilités, lisez la documentation pour en avoir une idée. On peut créer ses propres fonctions (Typst inclut un langage de programmation complet), définir des gabarits, etc. Il existe déjà plein de paquetages rigolos pour Typst sur le dépôt officiel, notamment pour l'écriture d'articles techniques et scientifiques. Voyons un exemple avec le paquetage atomic :

// (Ceci est un commentaire.) https://typst.app/universe/package/atomic
#import "@preview/atomic:1.0.0"

= Un essai d'un paquetage Typst

*atomic* permet de dessiner des atomes, avec leurs électrons. Ici, le plutonium.

// Cf. Article Wikipédia « Électrons par niveau d’énergie 	2, 8, 18, 32, 24, 8, 2 »
#atomic.atom(94,239, "Pu", (2, 8, 18, 32, 24, 8, 2))
  

(Attention, à la première utilisation, il faut être connecté à l'Internet, le paquetage étant téléchargé.) Compilé, cela donnera ce joli PDF.

De la même façon, vous pouvez faire des supports de présentation, avec touying qui est donc un concurrent de Beamer :

#import "@preview/touying:0.6.1": *
#import themes.simple: *
#show: simple-theme

= Mon exposé

Le sujet de l'exposé

== Première diapo

Je mets du texte.

== Deuxième diapo

Je continue.

Et encore.
  

Ah, et comment ai-je installé Typst ? C'est bien documenté. Il n'y a apparemment pas de paquetage de Typst existant, pour aucun système, mais Typst fournit des binaires (déjà compilés). Comme je préfère vérifier que les sources compilent, je l'ai compilé moi-même :

% cargo install --locked typst-cli

Typst est écrit en Rust et compiler du Rust est souvent une expérience frustrante. Sur un Ubuntu stable :

error: cannot install package `typst-cli 0.14.0`, it requires rustc 1.88 or newer, while the currently active rustc version is 1.75.0
`typst-cli 0.11.1` supports rustc 1.74

Eh oui, comme trop souvent avec Rust, il faut la toute, vraiment toute dernière version du compilateur, le langage changeant tout le temps. (J'ai donc fait mes tests sur une Debian unstable.)

Est-ce que je vais utiliser Typst ? Je ne sais pas encore. Le logiciel est déjà très utilisable, en tout cas sur un système d'exploitation très récent. Je vais faire les supports de ma présentation au prochain SplinterCon en Typst, ce sera une occasion de tester. L'une de mes inquiétudes est la gestion du projet. Typst est à 100 % du logiciel libre (licence Apache) mais son développement est apparemment étroitement contrôlé par une seule entreprise, qui commercialise des extensions privatrices à Typst et dont il n'est pas certain qu'ils acceptent d'ouvrir le projet.

Quelques autres ressources :

• Le tutoriel officiel est très bien.
• Typst est bien documenté.
• Les exemples utilisés dans la présentation de Patrick Massot : git clone https://codeberg.org/pmassot/typst_cdl2025.

Les 15 et 16 novembre s'est tenue à Toulouse Capitole du Libre, conférence consacrée aux logiciels libres mais pas que. Quelques notes suivent, entre autres sur l'exposé que j'ai fait sur les types de média (comme text/html pour ce blog).

Le poète toulousain Louis-Catherine Vestrepain, dont la statue n'est pas trop éloignée du lieu où se tient Capitole du Libre :

Capitole du Libre, c'est gros, avec beaucoup de monde, et un programme chargé (93 exposés, 1 400 participants, 10 kg de café, 500 repas aux camions de nourriture, 10 mètres carrés de pizzas pour les bénévoles). Je ne vais donc pas parler de tout. Déjà, j'ai suivi un exposé et un atelier qui font l'objet d'articles séparés :

• L'exposé sur le compilateur de texte Typst, un concurrent de LaTeX,
• L'atelier (donc, avec de la pratique) sur le mécanisme eBPF, qui permet de développer plus facilement des programmes dans le noyau Linux, ici un programme qui intercepte et autorise (ou pas) les requêtes DNS.

Autres moments passionnants :

• L'exposé de Natouille sur « C’est quoi l’UX design et pourquoi le libre aurait à y gagner en intégrant ces profils ? », où elle rappelait que la conception d'UX, ce n'est pas juste pour les cliquodromes et que tout logiciel peut avoir intérêt à avoir une démarche UX, et, entre autres, que les développeureuses devraient parler avec leurs utilisateurices et les observer. « Le design, c'est faire des produits utilisables, limiter frictions, risques et déceptions » et « Il y a utile, utilisable et utilisé. Instagram est utilisé, le site des impôts est utile, un site / logiciel bien conçu est utilisable ».
• La présentation par Bookynette de l'escape game (en cartes) de l'April pour faire connaitre le logiciel libre.
• L'exposé sur Ceph m'a plutôt convaincu que cette solution de stockage réparti n'était pas pour moi, pas parce que le logiciel n'est pas bon mais parce qu'il traite un problème bien précis qui n'est pas forcément le mien : avoir des données qui soient toujours disponibles, en les stockant dans des endroits bien distincts. Chaque fichier confié à Ceph est divisé en objets et chaque objet se retrouve sur plusieurs disques de plusieurs serveurs. L'interface de Ceph peut être du S3, un système de fichiers accessible comme un partage réseau ou même un block device. Ceph en lui-même ne remplace pas les sauvegardes. On peut toutefois utiliser des snapshots qui, à condition qu'ils ne soient pas accessibles aux clients, protègent contre erreurs humaines et rançongiciels.
• La présentation de Skeptikon « Le logiciel libre est un projet politique » insistait sur la lutte contre les mensonges et le discours anti-scientifique. Dans le contexte de la montée de l'extrême-droite, le logiciel libre est une des armes pour préserver sa liberté.
• Et puis, il n'a pas été présenté à Capitole du Libre mais saviez-vous qu'il existe un langage de programmation conçu et maintenu à Toulouse, Smala ?

De mon côté, j'ai fait un exposé sur les types de médias (également appelés types MIME, vous savez, les text/plain, image/png et autres haptics/ivs). Voici les supports et leur source (en LaTeX, pas en Typst) et la vidéo.

Et j'ai participé à la table ronde « Souveraineté numérique : pourquoi le logiciel libre est stratégique », avec Ludovic Dubost et Nicolas Vivant, animée par Aline Paponaud. L'idée (assez consensuelle parmi les participants) était qu'il n'y a pas de vraie souveraineté sans logiciel libre, entre autres parce que remplacer un GAFA étatsunien par un GAFA français qui ferait exactement la même chose n'a pas beaucoup d'intérêt. Le logiciel libre permet la souveraineté de l'utilisateurice, pas seulement celle de l'État.

Photos et vidéos sont disponibles, les photos sur https://photos.capitoledulibre.org/ et les vidéos (via PeerTube, bien sûr) sur https://videos.capitoledulibre.org/.

Ah, et le quotidien la Dépêche a fait un article très louangeur.

Bref, soutenez Capitole du Libre : .

Au Capitole du Libre de novembre 2025, j'ai participé à un passionnant atelier de Maxime Chevallier et Alexis Lothoré sur la programmation réseau en eBPF. Le but était de mettre en œuvre un bloqueur de publicité (ou autre contenu qu'on ne voulait pas voir), agissant via les requêtes DNS, que le programme va intercepter et analyser.

eBPF désigne à la fois un jeu d'instructions machine, normalisé dans le RFC 9669, et un système permettant de produire des programmes utilisant ce jeu d'instructions, et des les installer dans le noyau Linux. eBPF permet ainsi d'ajouter des fonctions au noyau, sans modifier et recompiler celui-ci (ce qui est vraiment une tâche difficile) et sans redémarrer la machine. Je vous renvoie à mon article sur le RFC 9669 pour plus de détail. Un exemple d'utilisation de eBPF dans le contexte du DNS est dans le serveur NSD.

Le cahier des charges de l'atelier était d'écrire (en C) et de faire tourner un programme eBPF qui va regarder toutes les requêtes DNS de la machine, les comparer à une liste de blocage, et stopper ces requêtes si le nom de domaine est dans cette liste. Si vous avez un peu de temps, je recommande de faire l'exercice vous-même, téléchargez le support de l'atelier (git clone https://github.com/bootlin/ebpf-workshop-cdl), lisez le fichier Readme.md (il est en anglais) et essayez. Cet article que vous lisez est plutôt destiné aux gens qui veulent la solution.

Comme le système eBPF sur Linux n'est pas d'une clarté parfaite, il vaut mieux commencer par un programme trivial. Attention, comme indiqué dans le Readme.md, ça marchera… ou pas, selon la version exacte du système d'exploitation que vous utilisez (j'ai tout fait sur une Ubuntu stable, la version 24.04). Quelques paquetages à installer :

% sudo apt install linux-tools-common build-essential clang libbpf-dev
  

Après cela, si, quand vous essayez de lancer bpftool, vous avez :

% bpftool 
WARNING: bpftool not found for kernel 6.14.0-112033

  You may need to install the following packages for this specific kernel:
    linux-tools-6.14.0-112033-tuxedo
    linux-cloud-tools-6.14.0-112033-tuxedo

  You may also want to install one of the following packages to keep up to date:
    linux-tools-tuxedo
    linux-cloud-tools-tuxedo
  

N'essayez pas d'installer les paquetages cités, ça ne servira sans doute pas. À la place, installez à la main :

% git clone --recurse-submodules https://github.com/libbpf/bpftool.git
% cd src
% make
% sudo make install   
  

Maintenant, écrivons le programme trivial qui ne fait pas grand'chose :

% cat hello.bpf.c

#include <linux/bpf.h>
#include <linux/pkt_cls.h>
#include "bpf/bpf_helpers.h"
#include "bpf/bpf_endian.h"

SEC("tc")
int hello(struct __sk_buff *skb)
{
  bpf_printk("Hello, world !"); 
  return TC_ACT_OK;
}

char __license[] SEC("license") = "GPL";

  

Ce programme crée une fonction (qui sera donc exécutée par le noyau), qui sera appelée à chaque paquet réseau et affichera le classique « Bonjour, tout le monde », avant de laisser passer le paquet. Compilons-le en eBPF :

% clang -Wall  -g -O1 -target bpf -c hello.bpf.c -o hello.bpf.o

Pour des raisons que je ne comprends pas bien, les options -g et surtout -On avec n > 0 semblent indispensables. Apparemment (c'est peu documenté), l'optimisation est nécessaire pour retirer du code qui, autrement, serait refusé par le vérificateur. Regardez la documentation « Clang implementation notes » et l'article « Building BPF applications with libbpf-bootstrap » (« -g is mandatory to make Clang emit BTF information. -O2 is also necessary for BPF compilation).

La compilation va produire du code eBPF :

% file hello.bpf.o
hello.bpf.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), with debug_info, not stripped
  

Le désassembleur par défaut ne connait pas eBPF :

% objdump -d hello.bpf.o 
hello.bpf.o:     file format elf64-little
objdump: can't disassemble for architecture UNKNOWN!
  

Mais il y en a un autre qui marche (suivez le RFC 9669) mais je le trouve moins joli :

% llvm-objdump -d hello.bpf.o     
hello.bpf.o:	file format elf64-bpf

Disassembly of section tc:

0000000000000000 <hello>:
       0:	18 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00	r1 = 0x0 ll
       2:	b7 02 00 00 0f 00 00 00	r2 = 0xf
       3:	85 00 00 00 06 00 00 00	call 0x6
       4:	b7 00 00 00 00 00 00 00	r0 = 0x0
       5:	95 00 00 00 00 00 00 00	exit

  

Bon, ce n'est pas tout de produire un binaire eBPF, il faut le charger dans le noyau, et dire au noyau de l'exécuter pour chaque paquet sortant. Il existe plusieurs méthodes pour cela (on peut aussi écrire son propre programme qui fait le chargement), on va utiliser tc, et attacher le code eBPF à l'interface réseau active, ici wlp1s0 :

% sudo tc qdisc add dev wlp1s0 clsact
% sudo tc filter add dev wlp1s0 egress bpf direct-action object-file  hello.bpf.o sec tc
  

(La syntaxe de tc est merveilleuse. Sur les noyaux Linux plus récents bpftool prog load fichier.o chemin suivi de bpftool net attach tcx_egress pinned chemin dev interface devrait pouvoir charger puis attacher des programmes, sans utiliser tc.) Une fois que tout cela est fait sans erreur, on peut afficher les messages :

%  sudo bpftool prog tracelog
 irq/80-iwlwifi:-928     [011] b.s3. 200018.139564: bpf_trace_printk: Hello, world !
 irq/81-iwlwifi:-929     [008] b.s3. 200018.139564: bpf_trace_printk: Hello, world !
   Socket Thread-576739  [000] b..1. 200018.139832: bpf_trace_printk: Hello, world !
   Socket Thread-576739  [000] b..1. 200018.139976: bpf_trace_printk: Hello, world !
…
  

Et voilà, à chaque paquet sortant (la directive egress dans l'appel à tc), on a un message affiché.

Comme eBPF inclut un vérificateur qui examine le code avant de l'exécuter (pour éviter qu'un programme eBPF bogué ne plante tout le noyau), des erreurs apparemment innocentes (comme d'aller visiter de la mémoire en dehors de nos variables) va se traduire par des erreurs au chargement, assez difficiles à déboguer :

libbpf: prog 'dns_filter': BPF program load failed: Permission denied
libbpf: prog 'dns_filter': -- BEGIN PROG LOAD LOG --
0: R1=ctx() R10=fp0
; int             dns_filter(struct __sk_buff *skb) @ dns-filter.bpf.c:107
0: (bf) r7 = r1                       ; R1=ctx() R7_w=ctx()
1: (b7) r6 = 0                        ; R6_w=0
...
124: (bf) r3 = r1                     ; R1_w=scalar(id=253) R3_w=scalar(id=253)
125: (0f) r3 += r2                    ; R2_w=0 R3_w=scalar(id=253+0)
126: (71) r3 = *(u8 *)(r3 +0)
R3 invalid mem access 'scalar'
processed 9460 insns (limit 1000000) max_states_per_insn 4 total_states 129 peak_states 129 mark_read 128
-- END PROG LOAD LOG --
libbpf: prog 'dns_filter': failed to load: -13
libbpf: failed to load object 'dns-filter.bpf.o'
Unable to load program
  

Si vous voyez cela, dites-vous que votre programme doit être trop laxiste et, pour reprendre une expression utilisée par les animateurs de l'atelier, qu'il jardine en dehors de ses plate-bandes.

Maintenant, revenons au vrai projet. L'atelier était prévu pour une découverte progressive, et c'est ce que vous ferez si vous suivez le support de l'atelier mentionné plus tôt (git clone https://github.com/bootlin/ebpf-workshop-cdl). Ici, je vais simplement présenter le résultat final. Mon code complet (légèrement différent de celui qui figure en correction dans les documents de l'atelier) est dns-filter.bpf.c. Je ne vais mentionner ici que le plus important, des commentaires dans le source éclairent d'autres points.

La liste des domaines bloqués est un dictionnaire, structure de données fournie par eBPF pour communiquer entre le programme dans le noyau, et l'extérieur :

struct {
    __uint(type, BPF_MAP_TYPE_ARRAY);
    __uint(max_entries, 2);
    __type(key, int);
                    __type(value, char[253]);
} blocklist     SEC(".maps");
  

On va utiliser beaucoup de structures de données TCP/IP dont la description est déjà fournie par Linux (comme struct udphdr pour un en-tête UDP). Il n'y en a apparemment pas pour le DNS, donc on la crée :

struct dnshdr {
    __be16          trans_id;
    __be16          flags;
    __be16          nr_quest;
    __be16          nr_answ;
    __be16          nr_auth_rr;
    __be16          add_rr;
    };
  

Pour l'analyse des paquets, on va charger les octets dans nos structures de données, à partir d'un index (la variable offset) avec la fonction BPF bpf_skb_load_bytes. Voici les étapes :

/* Ce paquet est-il un paquet IP ? Chargeons-le dans ethdhr avant de
regarder son champ Protocol. */	     
ret = bpf_skb_load_bytes(skb, offset, &ethhdr, sizeof(ethhdr));
if (ret) {
    return TC_ACT_OK;
}
if ((ethhdr.h_proto != __bpf_constant_htons(ETH_P_IPV6)) &&
        (ethhdr.h_proto != __bpf_constant_htons(ETH_P_IP))) {
        return TC_ACT_OK;
} 

  

Si une fonction échoue (j'ai omis ce test par la suite mais dans le vrai code, il faut le mettre, rappelez-vous que le vérificateur vous surveille), ou bien si le paquet n'est pas de l'IP, on le laisse passer (on renvoie OK à tc). Ensuite, après avoir sauté l'en-tête IP (attention, il n'a pas la même taille en IPv4 et IPv6), on regarde si c'est bien de l'UDP, et s'il utilise bien le port 53 du DNS :

if (l4_proto != IPPROTO_UDP) {
        return TC_ACT_OK;
}
ret = bpf_skb_load_bytes(skb, offset, &udph, sizeof(udph));
if (__bpf_constant_ntohs(udph.dest) != 53) {
        return TC_ACT_OK;
}

  

On va ensuite récupérer le nom de domaine demandé (attention à l'analyse d'un paquet DNS, lisez bien le RFC 9267) :

offset += sizeof(dnsh);
ret = parse_query(skb, offset, query, 253);
ctx.query = query;

  

On va ensuite tester ce nom query pour voir s'il est dans la liste de blocage, avec bpf_for_each_map_elem. Notez le code de retour TC_ACT_SHOT, qui dit à tc de jeter le paquet sans autre forme de procès.

    
bpf_for_each_map_elem(&blocklist, dns_check, &ctx, 0);
if (ctx.match) {
        bpf_printk("*REJECTED* DNS query of %s", query);
        return TC_ACT_SHOT;
}
bpf_printk("Accepted DNS query of %s", query);
return TC_ACT_OK;

  

Reste un petit détail : il faut peupler cette liste de blocage (la variable blocklist, de type dictionnaire). Une méthode possible est d'utiliser la commande bpftool mais, évidemment, en vrai, on écrirait un programme avec une interface utilisateur plus agréable :

% sudo bpftool map update name blocklist key 0 0 0 0 value $(printf '%-253s' x.com | tr ' ' '\0' | xxd -i -c 253| tr -d ,)
  

Armé de tout cela, on peut utiliser cette suite de commandes pour compiler le programme, attacher l'eBPF via tc, remplir la liste de blocage et regarder le résultat :

#!/bin/sh

sudo tc qdisc del dev wlp1s0 clsact
sudo tc qdisc add dev wlp1s0 clsact
clang -Wall -g -O1 -target bpf -c dns-filter.bpf.c -o dns-filter.bpf.o
sudo tc filter add dev wlp1s0 egress bpf direct-action object-file dns-filter.bpf.o sec tc
sudo bpftool map update name blocklist key 0 0 0 0 value $(printf '%-253s' x.com | tr ' ' '\0' | xxd -i -c 253| tr -d ,)
sudo bpftool map update name blocklist key 1 0 0 0 value $(printf '%-253s' facebook.com | tr ' ' '\0' | xxd -i -c 253| tr -d ,)
sudo bpftool prog tracelog 
  

Testons-le :

% ping facebook.com
ping: facebook.com: Temporary failure in name resolution

% ping bootlin.com  
PING bootlin.com (87.98.181.233) 56(84) bytes of data.
64 bytes from bootlin.com (87.98.181.233): icmp_seq=1 ttl=49 time=15.8 ms
  

Et, affiché par bpftool :

systemd-resolve-1112    [000] b..1. 208052.900167: bpf_trace_printk: *REJECTED* DNS query of facebook.com
systemd-resolve-1112    [000] b..1. 208052.900183: bpf_trace_printk: *REJECTED* DNS query of facebook.com
systemd-resolve-1112    [005] b..1. 208264.967434: bpf_trace_printk: Accepted DNS query of bootlin.com
  

Objectif atteint. On peut aller boire une bière. Notez que vous pouvez afficher la liste de blocage :

% sudo bpftool map dump name blocklist 
[{
        "key": 0,
        "value": "x.com"
    },{
        "key": 1,
        "value": "facebook.com"
    }
]
  

Quelques détails toutefois. D'abord, le programme de filtrage étant sommaire, il ne bloque que le nom exact dans la liste, pas ses sous-domaines :

 % dig facebook.com
;; communications error to 127.0.0.53#53: timed out
…
;; no servers could be reached

% dig www.facebook.com
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54041
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
www.facebook.com.	2724 IN	CNAME star-mini.c10r.facebook.com.
star-mini.c10r.facebook.com. 29	IN A 157.240.253.35

;; Query time: 22 msec
;; SERVER: 127.0.0.53#53(127.0.0.53) (UDP)
;; WHEN: Mon Nov 17 16:08:00 CET 2025
;; MSG SIZE  rcvd: 90

  

Corriger cette limite est laissé au lecteur ou à la lectrice (notez toutefois que dans l'atelier, il y avait environ vingt participants et pas de participante).

Ensuite, puisque tc va purement et simplement jeter le paquet, le client DNS n'aura aucune information, réessaiera et finira par laisser tomber mais au bout d'un délai qui est certainement pénible pour l'utilisateur. Il vaudrait mieux fabriquer une réponse mensongère, genre NXDOMAIN. Je ne suis pas sûr que cela soit facilement faisable avec tc mais il existe d'autres façons d'exécuter de l'eBPF donc le problème est certainement soluble.

Enfin, le DNS ne marche pas que sur UDP, il fonctionne aussi sur TCP (RFC 7766). Le programme ci-dessus peut donc être facilement contourné :

% dig @9.9.9.9 facebook.com
;; communications error to 9.9.9.9#53: timed out
…;; no servers could be reached

% dig +tcp @9.9.9.9 facebook.com
…
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 24690
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
…
;; ANSWER SECTION:
facebook.com.		30 IN A	57.144.222.1

;; Query time: 7 msec
;; SERVER: 9.9.9.9#53(9.9.9.9) (TCP)
;; WHEN: Mon Nov 17 16:16:59 CET 2025
;; MSG SIZE  rcvd: 63
    
  

Là encore, si vous voulez perfectionner ce programme, n'hésitez pas (mais c'est plus difficile, une requête DNS peut se retrouver répartie dans deux paquets IP différents).

Merci aux organisateurs de cet excellent atelier, Alexis Lothoré et Maxime Chevallier, et à Quentin Monnet pour un déboguage de cet article.

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 (la bibliothèque ldns, voir plus loin). 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 erroné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. Une mise à jour de ldns a apoporté la bogue.

Celle-ci a été signalée, bogue ldns #285 et corrigée mais pas encore forcément déployée partout.

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: [email protected]
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: [email protected]
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
  

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: [email protected]
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.

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.

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.