Daniel Allaire
3ea0c95492
Some checks are pending
verifier / verifier (push) Waiting to run
Chezlepro rangeait ses instantanes sur une VM DE SA PROPRE FLOTTE. Raser l ecosysteme pour le reconstruire, c etait raser le filet avec. Le site a son depot ; les neuf detenteurs d etat y deposent ; une restitution est sortie (annuaire LDAP lisible, hors flotte). Isolation par compte Unix, pas par convention : home 0700, cle exclusive, racine partagee a root en 0711 (traversable, non listable). Les deux refus constates. Le site heberge du chiffre : il ne peut ni lire ni ouvrir, d ou la verification deplacee chez le locataire qui detient la cle. Quatre defauts reveles par ce deuxieme usage : - la racine des depots ne peut etre le home de personne (StrictModes rendait Permission denied publickey pour un refus de CHEMIN) - la racine nie le TLD internal, et harden-below-nxdomain etendait ce non a toute la zone sans jamais interroger l autoritatif : aucun locataire ne pouvait nommer un service du site - le gabarit transporte des fichiers de durcissement perimes, et les machines du site ne recoivent jamais ssh_hardening - MaxStartups compte les connexions non authentifiees : un depot de site en voit la somme de ses locataires Constat non corrige : les machines du site ne sont pas durcies. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_019f91zs9SDdwSzL2CVei6on |
||
|---|---|---|
| .. | ||
| defaults | ||
| handlers | ||
| meta | ||
| tasks | ||
| templates | ||
| README.md | ||
serveur_resolveur
Le résolveur de l'écosystème : un seul Unbound pour tout le tenant, récursif depuis les serveurs racine, qui délègue la zone souveraine à PowerDNS.
Pourquoi un seul, et pourquoi ici
Avant le 2026-08-24, client_unbound posait un Unbound sur chaque VM. Ça marchait et
c'était parfaitement étanche — mais c'était N démons identiques pour un service unique.
Mesure prise avant de décider : ~21 Mo de RSS par VM, et 28 à 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
Un résolveur partagé par tout le SITE — l'OPNsense — aurait été le geste le plus économe. Il devrait alors 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. C'est 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
(voir 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.
La cohabitation avec l'autoritatif
Les deux vivent sur infra-dns-01 et voudraient le port 53. Le partage est dérivé, pas
déclaré — l'exploitant n'a pas à se souvenir de déplacer un port parce qu'il a ajouté un
rôle :
resolveur (Unbound) 10.29.19.11:53 + 127.0.0.1:53 la seule porte
autoritatif (PowerDNS) 127.0.0.1:5300 derrière lui
Personne n'interroge l'autoritatif directement. Le résolveur le prend en stub-zone.
Aucun transitaire
forward-addr reste vide : Unbound récurse depuis la racine. Poser un transitaire
reviendrait à confier chaque question de l'écosystème à un tiers — ce que la bascule du
2026-08-23 avait justement supprimé.
Ce qu'il vérifie avant de se déclarer bon
Il interroge sa propre adresse pour la zone interne et pour un nom de l'Internet. Un résolveur « active » qui ne répond pas est le pire des cas : toute la flotte pointe vers lui, et découvre la panne en essayant de résoudre — c'est-à-dire au moment où le diagnostic lui-même devient impossible.
Variables principales
| Variable | Défaut | Rôle |
|---|---|---|
serveur_resolveur_ecoutes |
loopback + IP du tenant | où il répond |
serveur_resolveur_reseaux_autorises |
le supernet du tenant | qui a le droit de demander |
serveur_resolveur_autoritatif |
127.0.0.1:5300 |
la zone souveraine |
serveur_resolveur_transitaires |
[] |
vide = récursion depuis la racine |
Ce que ce rôle ne fait pas
Il ne bascule aucun /etc/resolv.conf — c'est le travail de client_resolveur, qui
valide que ce service répond avant de désigner qui que ce soit.