Daniel Allaire
5340220192
- metier: sur chaque sonde (47) ; catalogue des vues et services dans serveur_icingaweb2 ; vues Mes outils / Services rendus / Exploitation - contrôles calculés comme serveur_icinga (sauvegardes, socle, matériel, frontière) ; vue vide non posée ; ancien exemple supervision retiré - CHANGELOG 71 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| 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.