resolveur : la flotte interroge son propre DNS

client_unbound arme sur les quatre hotes clients. En armant, la zone s'est
revelee incomplete -- ni ops-01 ni forge.genese.internal -- et a ete regeneree.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

README.md

@@ -64,6 +64,12 @@ d'irremplaçable (les clés de l'AC, les dépôts).
 **Il est hébergé par la fabric de Chezlepro** (`SITE-Chezlepro`), au même titre qu'un
 autre tenant. Il n'a pas d'underlay à lui.
 
+**Il résout par lui-même.** Les quatre hôtes clients interrogent un Unbound local, qui
+tient la zone `genese.internal` de `infra-dns-01` et **récurse depuis les serveurs
+racine** pour le reste — `forward-addr` = 0, aucun résolveur tiers n'est consulté.
+`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.
+
 ## Le génome, sur sa forge
 
 Les dépôts vivent sous l'organisation `genome` :
@@ -145,10 +151,10 @@ ses VLAN n'auraient existé nulle part.
 
 - [ ] **Décider où il vit.** Sur `asgard`, la perte du cluster emporte patient 0 *et*
       Chezlepro d'un coup. Ailleurs, la famille survit à la perte du cluster. Le
-      déménagement tient en quatre valeurs (`group_vars/proxmox.yml`) et un symlink.
+      déménagement tient en **trois** valeurs de `group_vars/proxmox.yml` — nœud, stockage,
+      gabarit. Le pont n'en fait pas partie : chaque VM atterrit sur le VNet dérivé de sa
+      zone.
 - [ ] **Une source d'artefacts.** Sa forge héberge du code, pas des binaires. Les
       collections Ansible sont réglées (cache du contrôleur, poussé par SSH) ; Forgejo,
       step-ca et les autres viennent encore du dehors. Un enfant coupé de l'internet ne
       se construit pas.
-- [ ] **Son propre résolveur.** Les hôtes interrogent Quad9 et non `infra-dns-01` :
-      l'écosystème fait tourner un DNS que personne n'utilise.

inventories/production/group_vars/client_unbound.yml

@@ -0,0 +1,30 @@
+---
+# BASCULER LA FLOTTE SUR SON PROPRE RESOLVEUR.
+#
+# Jusqu'ici, les hotes de patient 0 interrogeaient Quad9 (9.9.9.9) — alors que
+# `infra-dns-01` fait tourner un PowerDNS AUTORITATIF pour `genese.internal` que personne
+# ne consultait. Trois consequences, dont la troisieme est la pire :
+#
+#   1. la resolution interne ne reposait que sur le plancher /etc/hosts, qui ne connait
+#      que ce que l'inventaire declare ;
+#   2. chaque requete DNS de l'ecosysteme sortait chez un tiers — une fuite au niveau le
+#      plus fondamental de la pile, pour une plateforme dont le principe est la
+#      souverainete ;
+#   3. la zone pouvait etre FAUSSE sans que rien ne le signale. Elle l'etait : au moment
+#      d'armer cette bascule, `forge.genese.internal` — le nom que l'ecosysteme PUBLIE —
+#      n'existait pas dans PowerDNS, et `ops-01` non plus. Un service qui repond a des
+#      questions que personne ne pose n'est pas surveille, il est simplement muet.
+#
+# POURQUOI LES DEUX DRAPEAUX SONT ICI, ET PAS EN LIGNE DE COMMANDE. Le role refuse
+# `apply` sans `confirm` : declarer l'un sans l'autre ferait echouer TOUT deploiement
+# ulterieur. Les deux vont donc ensemble, et leur place est le plan — c'est la que les
+# decisions de cet ecosysteme sont ecrites, relues et versionnees.
+#
+# CE QUE LA GARDE FAIT ENCORE, a chaque passage : avant de toucher /etc/resolv.conf, le
+# role exige qu'Unbound reponde DEJA sur 127.0.0.1, pour la zone interne ET pour un nom
+# de l'Internet. Si l'un des deux manque, il echoue AVANT d'avoir rien casse.
+client_unbound_apply: true
+client_unbound_confirm: true
+
+# `infra-dns-01` n'est pas dans ce groupe : l'autoritatif ne se resout pas aupres de
+# lui-meme par un recurseur local. Il garde sa resolution amont.