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 <noreply@anthropic.com>

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