From a3f496a49684f584a8c2a9b23ac31d135ba2e02b Mon Sep 17 00:00:00 2001 From: Daniel Allaire Date: Sun, 23 Aug 2026 13:37:05 -0400 Subject: [PATCH] resolveur : patient 0 ne pose plus ses questions a personne Les hotes interrogeaient Quad9 alors que l'ecosysteme fait tourner son propre autoritatif. Le mecanisme n'etait pas absent -- client_unbound etait desarme. En l'armant, la zone s'est revelee FAUSSE : ni ops-01, ni forge.genese.internal, le nom que l'ecosysteme publie. Meme cause que le vhost nginx et le plancher : setops_plan_dir pointait le mauvais plan. Un service que personne n'interroge n'est pas surveille, il est muet. Quatre hotes bascules, forward-addr = 0 : Unbound recurse depuis la racine, il ne renvoie a aucun tiers. Co-Authored-By: Claude Opus 5 --- CHANGELOG.md | 58 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 58 insertions(+) diff --git a/CHANGELOG.md b/CHANGELOG.md index 4a12e5d..6800af8 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -1,5 +1,63 @@ # CHANGELOG — Set-OPS +## 2026-08-23 — Le résolveur : un service qui répondait à des questions que personne ne posait + +Les hôtes de patient 0 interrogeaient **Quad9**, alors que `infra-dns-01` fait tourner un +PowerDNS autoritatif pour `genese.internal`. Chaque requête DNS de l'écosystème sortait +chez un tiers — une fuite au niveau le plus fondamental de la pile, pour une plateforme +dont le principe est la souveraineté. + +Le mécanisme n'était pas absent : `client_unbound` était **désarmé**, deux booléens à +`false`, avec une garde qui refuse la bascule sans confirmation et valide qu'Unbound +répond *déjà* — zone interne **et** Internet — avant de toucher `/etc/resolv.conf`. + +### La zone était fausse, et rien ne le disait + +C'est le troisième effet, et le pire. En armant la bascule, la zone servie contenait : + +``` +genese.internal SOA/NS/ns1 · dns CNAME +forge-01 · infra-dns-01 · infra-edge-01 · infra-pki-01 +``` + +Manquaient **`ops-01`** — la machine créée le matin même — et surtout +**`forge.genese.internal`**, le nom que l'écosystème *publie*. Un service que personne +n'interroge n'est pas surveillé : il est muet. La zone aurait pu être fausse pendant des +mois sans qu'aucun vert ne vacille. + +La cause est la même que celle du vhost nginx et du plancher `/etc/hosts` : le rôle +dérive ses enregistrements de `setops_plan_dir`, qui pointait le mauvais plan. Un +redéploiement avec la variable corrigée a suffi : + +``` +forge.genese.internal A 10.29.16.11 ← l'edge qui le sert +ops-01.genese.internal A 10.29.19.41 +``` + +### La bascule + +Quatre hôtes — `infra-dns-01` reste hors du groupe, un autoritatif ne se résout pas +auprès de lui-même par un récurseur local. Vérifié après coup : + +``` +resolv.conf search genese.internal · nameserver 127.0.0.1 +interne forge.genese.internal -> 10.29.16.11 ops-01 -> 10.29.19.41 +internet deb.debian.org -> 151.101.138.132 +apt update ok +fetch du génome depuis sa forge, par le poste : ok +``` + +Et le point qui décide si le gain est réel ou cosmétique : **`forward-addr` = 0**. Unbound +récurse depuis les serveurs racine, il ne renvoie à aucun tiers. Patient 0 est le premier +écosystème de la flotte à ne plus poser ses questions à personne. + +### Une note d'outillage + +`grep -c` rend un code de sortie **1** quand il compte zéro. Ma sonde a donc affiché +`FAILED` sur les quatre hôtes alors que tout livrait — le zéro était précisément le +résultat cherché. Un instrument qui crie à l'échec quand il constate le succès attendu +vaut la peine d'être relu avant d'être cru. + ## 2026-08-23 — `serveur_ops` : la différence entre une archive et une matrice Un écosystème pouvait **détenir** son génome sans savoir l'exécuter. Les cinq dépôts