Set-OPS-Public/roles/serveur_resolveur/defaults/main.yml

---
# 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: []