Daniel Allaire
0854b2a93c
Some checks are pending
verifier / verifier (push) Waiting to run
Chezlepro detruite (15 VM, disques compris) et refaite depuis le gabarit minimal. 15/15 hotes, 0 echec ; make valider passe, test de restitution compris. Aucun defaut ne venait de la flotte ni du gabarit. 1. Un avertissement n est pas un echec. Proxmox rend WARNINGS: n pour une tache ABOUTIE ; la garde n acceptait que OK et declarait perdues cinq VM clonees a 100 pourcent. Le message parlait d etat stopped — celui de la TACHE, pas de la VM. 2. client_artefacts se contredisait : son commentaire disait de degrader, son code arretait. L autorite monte en premier, donc avant le cache du locataire : aucun ordre ne pouvait satisfaire la garde. 3. harden-below-nxdomain etendait le NXDOMAIN signe de la racine pour le TLD internal a toute la zone du site, sans jamais interroger l autoritatif. Declencheur : toute question sur un nom absent sous internal, y compris la zone d un autre locataire. Le cache contenait la bonne reponse ET un message negatif ; c est le negatif qui etait servi. aggressive-nsec: no avait semble marcher — c est le redemarrage qui vidait le cache, pas le reglage. 4. Un locataire doit savoir a qui demander la zone de son hebergeur, sans quoi il ne peut plus nommer son depot de sauvegarde. La derivation prenait dns_amorcage pour le resolveur du site : faux chez Technolibre, dont l amorcage est 9.9.9.9. P03 l a attrape avant tout deploiement. Au passage : instancier tentait encore le mot de passe unique d avant la separation des voutes ; comparer echouait en exit 4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on
77 lines
3.9 KiB
YAML
77 lines
3.9 KiB
YAML
---
|
|
# LE RÉSOLVEUR DE L'ÉCOSYSTÈME — un seul, pour tout le tenant.
|
|
#
|
|
# Avant : un Unbound sur CHAQUE VM, écoutant sur 127.0.0.1. Ça marchait, et c'était
|
|
# parfaitement étanche — mais c'était N démons identiques pour un service unique.
|
|
#
|
|
# MESURE DU 2026-08-24, avant de décider : ~21 Mo de RSS par VM, et entre 28 et 189
|
|
# requêtes servies depuis le démarrage. Le gain de cache mutualisé est donc négligeable ;
|
|
# ce qu'on récupère, c'est un démon au lieu de quatorze, et un endroit à regarder au lieu
|
|
# de quatorze.
|
|
#
|
|
# POURQUOI PAS SUR LA FRONTIÈRE (OPNsense), qui aurait été le geste le plus économe : un
|
|
# résolveur partagé par tout le SITE devrait connaître la zone interne de CHAQUE tenant.
|
|
# Sans vues par réseau soigneusement réglées, le tenant A résoudrait les noms du tenant B
|
|
# — l'étanchéité qu'on protège partout ailleurs. Et un tenant dont le résolveur vit chez
|
|
# l'hébergeur ne peut plus s'émanciper avec (docs/filiation-emancipation.md).
|
|
#
|
|
# La récursion est générique ; la ZONE INTERNE ne l'est pas. C'est ce qui fait du
|
|
# résolveur un service de TENANT, et non de fabric.
|
|
|
|
serveur_resolveur_paquets:
|
|
- unbound
|
|
serveur_resolveur_service: "unbound"
|
|
|
|
# Il écoute pour toute la flotte du tenant — plus seulement pour lui-même.
|
|
serveur_resolveur_ecoutes:
|
|
- "127.0.0.1"
|
|
- "{{ ansible_host }}"
|
|
|
|
# QUI A LE DROIT DE L'INTERROGER : le supernet du tenant, dérivé du seed comme tout le
|
|
# reste. Un résolveur ouvert au monde est un relais d'amplification.
|
|
serveur_resolveur_reseaux_autorises:
|
|
- "{{ setops_supernet | default('127.0.0.0/8') }}"
|
|
|
|
# La zone souveraine et son autoritatif. PowerDNS se replie sur la loopback quand il
|
|
# partage cet hôte (voir serveur_powerdns/defaults), pour lui laisser le port 53.
|
|
serveur_resolveur_zone_interne: "{{ domaine_interne }}"
|
|
serveur_resolveur_autoritatif: "127.0.0.1"
|
|
serveur_resolveur_autoritatif_port: 5300
|
|
|
|
# LE RESOLVEUR DELEGUE A L'AUTORITATIF CE QUE L'AUTORITATIF SERT (2026-08-25).
|
|
#
|
|
# La zone souveraine lui etait deleguee par une `stub-zone` ; les zones INVERSES ne
|
|
# l'etaient pas. PowerDNS servait donc les PTR sur son port, et personne ne les lui
|
|
# demandait : `dig -x` rendait vide depuis les cinq machines alors que la meme requete
|
|
# posee directement a l'autoritatif repondait juste.
|
|
#
|
|
# C'est la panne que le depot connait deja sous une autre forme — un service correct
|
|
# derriere un chemin que rien n'emprunte.
|
|
#
|
|
# MEME DERIVATION QUE `serveur_powerdns`, par le meme filtre : deux calculs separes
|
|
# finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge.
|
|
serveur_resolveur_zones_inverses: >-
|
|
{{ (groups.get('hotes_actifs', []) | map('extract', hostvars, 'ansible_host')
|
|
| select | list)
|
|
| zones_inverses(setops_supernet | default('')) }}
|
|
|
|
# AUCUN TRANSITAIRE : Unbound récurse depuis les serveurs racine. Poser un transitaire ici
|
|
# reviendrait à confier chaque question de l'écosystème à un tiers — ce que la bascule du
|
|
# 2026-08-23 avait justement supprimé.
|
|
serveur_resolveur_transitaires: []
|
|
|
|
# LES ZONES QUI NE SONT PAS À NOUS, ET À QUI LES DEMANDER.
|
|
#
|
|
# Liste de `{nom, adresses}`. Un locataire y trouve la zone de son HÉBERGEUR : il dépend
|
|
# de ses services par leur NOM — cache d'artefacts, forge, dépôt de sauvegarde, autorité
|
|
# — et doit savoir à quel résolveur les demander.
|
|
#
|
|
# DÉRIVÉE, PAS DÉCLARÉE : `inventory_host.py` la construit depuis la carte de
|
|
# l'hébergeur (le symlink `underlay.yml`) et l'adresse d'amorçage DNS que le locataire
|
|
# connaît déjà. Deux déclarations du même fait finiraient par diverger.
|
|
#
|
|
# VIDE PAR DÉFAUT, ET C'EST LE COMPORTEMENT D'UN ÉMANCIPÉ : un écosystème dont la carte
|
|
# de l'hébergeur n'est plus montée ne délègue plus rien. Il ne peut alors plus nommer les
|
|
# services du site — ce qui est exactement ce qu'on veut constater d'une émancipation, et
|
|
# non une panne à réparer.
|
|
serveur_resolveur_zones_deleguees: []
|