Alliance-Boreale/Set-OPS-Public
2
0
Fork 0
Code Issues Pull requests 1 Projects Releases Packages Wiki Activity
Set-OPS-Public/roles/serveur_powerdns
History
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
handlers Rendre le dry-run (--check) fiable sur les rôles applicatifs 2026-07-01 21:01:53 -04:00
meta resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
tasks D-71 : PKI et DNS debout avant tout, et la zone inverse manquait 2026-08-08 15:29:57 -04:00
templates resolveur : un par tenant, et non plus un par machine 2026-08-24 16:59:34 -04:00
README.md Set-OPS — moteur d'ecosystemes numeriques souverains (Alliance Boreale) 2026-06-24 20:17:46 -04:00

README.md

Role serveur_powerdns

Installe et configure PowerDNS Authoritative comme service DNS interne initial.

Ce premier jalon utilise le backend BIND et une zone generee par Ansible depuis l'inventaire. Cela evite de rendre DNS dependant de PostgreSQL avant que le service serveur_postgresql soit disponible.

Variables principales :

  • serveur_powerdns_zone
  • serveur_powerdns_nameserver
  • serveur_powerdns_contact
  • serveur_powerdns_records

Les hotes actifs portant ansible_host sont ajoutes automatiquement dans la zone par le template.