Daniel Allaire
db2d6f6bf0
Mesure avant de decider : ~21 Mo de RSS par VM pour 28 a 189 requetes servies. Le gain de cache est negligeable ; ce qu'on recupere, c'est un demon au lieu de cinq et un endroit a regarder au lieu de cinq. Pas sur la frontiere : un resolveur de SITE devrait connaitre la zone interne de chaque tenant, et un tenant dont le resolveur vit chez l'hebergeur ne peut plus s'emanciper avec. La recursion est generique, la zone interne ne l'est pas. L'autoritatif se replie sur 127.0.0.1:5300 -- derive de la colocalisation, pas declare a la main. Son port devient `derive` dans meta/flux.yml : les deux lient 53 mais sur des adresses differentes. Deux pieges. Unbound refuse d'interroger une loopback par defaut : sans lever do-not-query-localhost, toute la zone rendait SERVFAIL. Et le plancher /etc/hosts MASQUAIT la panne -- getent repondait, dig disait SERVFAIL. La tache de validation du role avait raison contre moi. client_unbound n'installant plus Unbound, son nom mentait : client_resolveur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
44 lines
2.1 KiB
YAML
44 lines
2.1 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
|
|
|
|
# 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: []
|