Set-OPS-Public/roles/client_resolveur
Daniel Allaire 1a7c042e5b site : quatre zones d'autorite, et l'ordre inscrit dans les integrations
Le site n'est plus un /24 plat. Une zone par nature d'autorite — pilotage, autorite,
genome, service — chacune son VLAN et sa patte sur la frontiere. L'inversion corrigee,
mesuree : les cinq VM du site n'avaient AUCUN filtrage est-ouest, contre policy_in=DROP
sur une machine de tenant. La plus autoritaire etait la moins protegee.

Filtrage nord-sud par choix de l'exploitant : un seul point de police, un seul devis.
90 -> 117 regles. Chaque flux `flotte` produit une regle par zone SOURCE, destination
nommee — ce qui etait gratuit devient police.

L'ORDRE FAIT PARTIE DE L'INTEGRATION. client_pki tournait en parallele sur tous les hotes ;
sur celui qui porte l'autorite il recharge step-ca, et les quatre autres echouaient dans
cette fenetre sur `TLS handshake timeout` — un message qui accuse le reseau. Chaque
integration declare desormais sa dependance dans meta/integration.yml, les playbooks en
sont le miroir genere, et P44 refuse l'ecart (4 controles negatifs). `serveur: ~` est une
reponse valable : client_metrique pose un exportateur qu'on vient LIRE.

Autres defauts du meme soir :
  - le plancher /etc/hosts venait APRES le premier apt, qui vise le cache par son NOM :
    boucle fermee des que les adresses changent. Il ne s'installe pas, il rend installable.
  - dns_amorcage ecrit en dur a eu tort deux fois ; il se derive de serveur_resolveur.
  - l'ACL du resolveur derivait d'un seul sous-reseau : trois zones refusees sur quatre.

ET UNE ERREUR A MOI : j'ai diagnostique un trou noir de MTU et declare 1450. Faux — pas de
VXLAN sur ce chemin, tout est a 1500 de bout en bout. Ma mesure etait reelle, mon
interpretation non : je venais de debrancher la carte a chaud, et chaque `ip link set mtu`
reconfigurait l'interface. C'est la reconfiguration qui debloquait, pas la valeur.

44 preuves vertes, ansible-lint profil production.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 17:31:07 -04:00
..
defaults resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
meta site : quatre zones d'autorite, et l'ordre inscrit dans les integrations 2026-08-25 17:31:07 -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.