Set-OPS-Public/roles/client_resolveur
Daniel Allaire db2d6f6bf0 resolveur : un par tenant, et non plus un par machine
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>
2026-08-24 16:59:34 -04:00
..
defaults resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
meta resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
tasks resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
README.md resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00

client_resolveur

Résolveur local par nœud (Unbound) : cache + récursion, avec une stub-zone vers l'autoritatif interne (PowerDNS). Rend la résolution dynamique sans casser Internet. Troisième et dernière couche du DNS interne (docs/dns-interne.md).

Les trois couches

  1. hosts_statiques — plancher /etc/hosts, toujours là, indépendant de tout service ;
  2. serveur_powerdns — autoritatif de la zone interne ;
  3. ce rôle — résolveur local, opt-in, qui rend la résolution dynamique par nœud.

Rôle

  • Installe unbound et bind9-dnsutils (dig, pour valider avant de basculer).
  • Déploie setops.conf : écoute sur 127.0.0.1, stub-zone vers l'autoritatif interne, récursion (ou transitaires) pour le reste d'Internet.
  • Valide la configuration (unbound-checkconf), active le service.
  • Bascule /etc/resolv.conf vers 127.0.0.1 — protégée (voir ci-dessous).

Garde-fou de bascule (anti-coupure)

Changer le résolveur d'un nœud à distance, c'est risquer de le rendre muet. Le rôle exige donc deux interrupteurs, et vérifie avant d'agir :

client_resolveur_apply: true
client_resolveur_confirm: true

Sans les deux, le rôle installe et démarre Unbound mais ne touche pas à /etc/resolv.conf (refus explicite). Avec les deux, il applique d'abord les redémarrages en attente, puis valide qu'Unbound résout réellement (un nom interne et un nom Internet) — et ne bascule qu'ensuite. Même doctrine que la règle 4 d'AGENTS.md : action risquée = confirmation explicite.

Variables

Variable Défaut Rôle
client_resolveur_ecoute 127.0.0.1 Écoute (boucle locale)
client_resolveur_zone_interne {{ domaine_interne }} Zone en stub
client_resolveur_dns_autoritatif dérivé du groupe serveur_powerdns Cible de la stub-zone
client_resolveur_transitaires [] Vide = récursion propre (racine + DNSSEC)
client_resolveur_apply / _confirm false / false Bascule de /etc/resolv.conf

Flux (meta/flux.yml)

53/udp entrant en localhost · 53/tcp sortant vers serveur_powerdns.

Notes / limites

  • Transitaires vides = Unbound récurse lui-même (racine + DNSSEC). Si la récursion sortante est bloquée par le réseau, renseigner client_resolveur_transitaires.
  • Le rôle exige l'IP de l'autoritatif interne (assertion) : serveur_powerdns doit être dans l'inventaire avec un ansible_host.
  • DoT (DNS chiffré) n'est pas encore branché — c'est un des flux restants du zéro-confiance.

Prérequis

  • serveur_powerdns actif. Couche agents.