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

87 lines
4.3 KiB
YAML
Raw Normal View History

---
serveur_powerdns_packages:
- pdns-server
- pdns-backend-bind
- bind9-utils
- dnsutils
serveur_powerdns_service_name: "pdns"
serveur_powerdns_zone_directory: "/etc/powerdns/zones"
serveur_powerdns_bind_config: "/etc/powerdns/bindbackend.conf"
serveur_powerdns_zone: "{{ domaine_interne }}"
serveur_powerdns_nameserver: "ns1"
serveur_powerdns_contact: "hostmaster.{{ domaine_interne }}"
serveur_powerdns_ttl: 3600
serveur_powerdns_serial: 2026062201
serveur_powerdns_soa_refresh: 3600
serveur_powerdns_soa_retry: 900
serveur_powerdns_soa_expire: 1209600
serveur_powerdns_soa_minimum: 3600
# L'adresse du tenant SEULEMENT, pas `0.0.0.0` : lier toutes les interfaces occupe aussi
# `127.0.0.1:53`, ou un resolveur recursif local voudrait s'installer. Ce n'est pas un
# probleme theorique — c'est la raison pour laquelle `client_resolveur` exempte cet hote.
# PowerDNS reste autoritatif pur : il repond pour la zone souveraine et REFUSE le reste.
# LE RESOLVEUR DU TENANT PARTAGE CET HOTE (2026-08-24). Quand c'est le cas, l'autoritatif
# lui laisse le port 53 de l'adresse LAN et se replie sur la loopback, sur un autre port :
# le resolveur devient la SEULE porte, et personne n'interroge l'autoritatif directement.
#
# Derive de l'inventaire, pas declare a la main : l'exploitant ne doit pas avoir a se
# souvenir de deplacer un port parce qu'il a ajoute un role.
serveur_powerdns_colocalise_resolveur: >-
{{ inventory_hostname in (groups['serveur_resolveur'] | default([])) }}
serveur_powerdns_listen_port: "{{ 5300 if (serveur_powerdns_colocalise_resolveur | bool) else 53 }}"
serveur_powerdns_listen_addresses: >-
{{ ['127.0.0.1'] if (serveur_powerdns_colocalise_resolveur | bool)
else [ansible_host | default('0.0.0.0')] }}
serveur_powerdns_allow_axfr_ips: []
# Enregistrements additionnels geres explicitement.
serveur_powerdns_records:
- name: "dns"
type: "CNAME"
value: "ns1.{{ serveur_powerdns_zone }}."
# Groupes dont les hotes actifs avec ansible_host seront ajoutes a la zone.
serveur_powerdns_inventory_groups:
- hotes_actifs
# Publier des A pour les FQDN d'exposition (champ 'expose' des applications) vers l'edge
# qui les sert (domaines.edge). Ferme la boucle : declarer 'expose' -> vhost + cert + DNS.
serveur_powerdns_publier_expositions: true
serveur_powerdns_expositions: []
dns : quatre zones inverses pour le site, et rien de plus Le site ne servait aucun PTR. `serveur_powerdns_zone_inverse` derivait d'un supernet /16 — la forme d'un TENANT, qui tire tout de son index. Un site ne derive pas : il declare plusieurs /24 et n'a pas de supernet unique, si bien que la derivation rendait une chaine vide et qu'aucune zone n'etait generee. Le site revendique desormais exactement ce qu'il occupe : 31.0.10.in-addr.arpa 32.0.10.in-addr.arpa 33.0.10.in-addr.arpa 34.0.10.in-addr.arpa Revendiquer `0.10.in-addr.arpa` d'un seul geste aurait ete plus simple et faux : cette zone couvre aussi la frontiere, le transit et les hyperviseurs, qui ne sont pas a lui. Une autorite qu'on s'attribue sans l'exercer est une panne differee — le resolveur repondrait NXDOMAIN pour des adresses qu'un autre sait nommer. LA DERIVATION VIT DANS UN FILTRE (`zones_inverses`) parce qu'elle a DEUX appelants : `serveur_powerdns` ecrit ces zones, `serveur_resolveur` les delegue a l'autoritatif. Deux calculs separes finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge. Le nom d'une zone dit sa profondeur — trois etiquettes numeriques valent un /24, deux valent un /16 — et le modele en deduit seul la forme du PTR. DEUX CHEMINS MORTS TROUVES EN ROUTE. Les zones etaient servies, et personne ne les demandait. `serveur_resolveur` deleguait la zone directe par une `stub-zone` mais pas les inverses : `dig -x` rendait vide depuis les cinq machines alors que la meme requete posee directement a l'autoritatif repondait juste. Un service correct derriere un chemin que rien n'emprunte. Puis, les stubs poses, Unbound repondait toujours NXDOMAIN avec le drapeau `aa` — une reponse AUTORITAIRE, sans jamais consulter le stub. Il embarque des `local-zone` pour tout l'espace RFC1918 inverse. `nodefault` n'y change rien : ce mode n'agit que si le nom correspond EXACTEMENT a une zone par defaut, et la sienne est `10.in-addr.arpa`, le /8 entier. C'est `transparent` qui laisse la requete suivre son cours — pour nos quatre zones seulement, la ou `unblock-lan-zones` aurait ouvert tout l'espace prive. Rien ne distinguait ce blocage d'une absence : le meme NXDOMAIN qu'un nom qui n'existe pas. AUSSI : les zones inverses sont desormais validees par `named-checkzone` comme la directe (un fichier mal forme etait refuse en silence par PowerDNS), et une zone qu'un ecosysteme cesse de revendiquer est retiree du repertoire. VERIFICATION. Les cinq PTR resolvent depuis les cinq hotes par le resolveur, les huit noms directs par le plancher ET par le DNS, et les deux roles sont idempotents (changed=0). P47 evalue la derivation sur cinq cas — un site a quatre zones, un tenant a une, deux machines d'un meme /24 qui n'en font qu'une, aucune adresse, une adresse illisible. Controle negatif verifie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 20:58:50 -04:00
# ZONES INVERSES — DERIVEES, JAMAIS ECRITES.
#
dns : quatre zones inverses pour le site, et rien de plus Le site ne servait aucun PTR. `serveur_powerdns_zone_inverse` derivait d'un supernet /16 — la forme d'un TENANT, qui tire tout de son index. Un site ne derive pas : il declare plusieurs /24 et n'a pas de supernet unique, si bien que la derivation rendait une chaine vide et qu'aucune zone n'etait generee. Le site revendique desormais exactement ce qu'il occupe : 31.0.10.in-addr.arpa 32.0.10.in-addr.arpa 33.0.10.in-addr.arpa 34.0.10.in-addr.arpa Revendiquer `0.10.in-addr.arpa` d'un seul geste aurait ete plus simple et faux : cette zone couvre aussi la frontiere, le transit et les hyperviseurs, qui ne sont pas a lui. Une autorite qu'on s'attribue sans l'exercer est une panne differee — le resolveur repondrait NXDOMAIN pour des adresses qu'un autre sait nommer. LA DERIVATION VIT DANS UN FILTRE (`zones_inverses`) parce qu'elle a DEUX appelants : `serveur_powerdns` ecrit ces zones, `serveur_resolveur` les delegue a l'autoritatif. Deux calculs separes finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge. Le nom d'une zone dit sa profondeur — trois etiquettes numeriques valent un /24, deux valent un /16 — et le modele en deduit seul la forme du PTR. DEUX CHEMINS MORTS TROUVES EN ROUTE. Les zones etaient servies, et personne ne les demandait. `serveur_resolveur` deleguait la zone directe par une `stub-zone` mais pas les inverses : `dig -x` rendait vide depuis les cinq machines alors que la meme requete posee directement a l'autoritatif repondait juste. Un service correct derriere un chemin que rien n'emprunte. Puis, les stubs poses, Unbound repondait toujours NXDOMAIN avec le drapeau `aa` — une reponse AUTORITAIRE, sans jamais consulter le stub. Il embarque des `local-zone` pour tout l'espace RFC1918 inverse. `nodefault` n'y change rien : ce mode n'agit que si le nom correspond EXACTEMENT a une zone par defaut, et la sienne est `10.in-addr.arpa`, le /8 entier. C'est `transparent` qui laisse la requete suivre son cours — pour nos quatre zones seulement, la ou `unblock-lan-zones` aurait ouvert tout l'espace prive. Rien ne distinguait ce blocage d'une absence : le meme NXDOMAIN qu'un nom qui n'existe pas. AUSSI : les zones inverses sont desormais validees par `named-checkzone` comme la directe (un fichier mal forme etait refuse en silence par PowerDNS), et une zone qu'un ecosysteme cesse de revendiquer est retiree du repertoire. VERIFICATION. Les cinq PTR resolvent depuis les cinq hotes par le resolveur, les huit noms directs par le plancher ET par le DNS, et les deux roles sont idempotents (changed=0). P47 evalue la derivation sur cinq cas — un site a quatre zones, un tenant a une, deux machines d'un meme /24 qui n'en font qu'une, aucune adresse, une adresse illisible. Controle negatif verifie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-25 20:58:50 -04:00
# Rien dans le moteur ne touchait `in-addr.arpa` avant le 2026-08-08 : un hote pouvait
# etre resolu par son nom et rester anonyme a l'envers, ce que le courriel et la
# journalisation reprochent en silence.
#
# La premiere derivation supposait un supernet /16 — la forme d'un TENANT, qui tire tout
# de son index. Un SITE ne derive pas : il declare ses reseaux, et il en declare
# plusieurs. `setops_supernet` y vaut le /24 de la machine, jamais un /16, si bien que la
# derivation rendait une chaine vide et qu'AUCUNE zone inverse n'etait generee (mesure du
# 2026-08-25 : les cinq machines du site, sans PTR).
#
# On couvre desormais EXACTEMENT ce que l'ecosysteme occupe : un /16 quand il en a un,
# sinon un /24 par reseau ou vit reellement une machine. Pour le site, les quatre zones
# `31.0.10`, `32.0.10`, `33.0.10`, `34.0.10` — et rien au-dela. Revendiquer tout
# `0.10.in-addr.arpa` aurait ete plus simple et faux : cette zone couvre aussi la
# frontiere, le transit et les hyperviseurs, qui ne sont pas a lui. Une autorite qu'on
# s'attribue sans l'exercer est une panne differee.
#
# LA DERIVATION VIT DANS UN FILTRE (`zones_inverses`), parce qu'elle a DEUX appelants :
# `serveur_powerdns` ecrit ces zones, `serveur_resolveur` les delegue a l'autoritatif.
# Deux calculs separes finiraient par diverger, et la divergence ne se verrait qu'au
# premier PTR interroge.
#
# Le nom d'une zone dit sa profondeur : trois etiquettes numeriques valent un /24, deux
# valent un /16. Le modele en deduit seul la forme du PTR ; rien n'est ecrit deux fois.
serveur_powerdns_zones_inverses: >-
{{ (serveur_powerdns_inventory_groups | map('extract', groups) | select | flatten
| map('extract', hostvars, 'ansible_host') | select | list)
| zones_inverses(setops_supernet | default('')) }}
sondes : les cinq qui manquaient le plus (autorite, base, annuaire, zones, edge) CORRECTION DE COMPTE D ABORD. J avais annonce cinq groupes sans sonde. La mesure en donne VINGT-SEPT : j avais compte ceux que j avais en tete, pas ceux que le depot contient. Il en reste vingt-deux. LES CINQ, PAR ORDRE DE DEGAT SILENCIEUX. autorite (step_ca) — la plus urgente : nos certificats vivent 24 h, une AC muette ne casse rien aujourd hui et casse TOUT demain, d un coup, sur les 21 machines. Elle surveille aussi l expiration de la RACINE, que personne ne regarde parce qu elle vit des annees (relevee a 3642 jours). base (postgresql) — une VRAIE requete, pas pg_isready : celui-ci dit que le port repond, pas que la base sert. Plus le compte des connexions : a saturation, chaque application tombe sans que la base ait l air morte. annuaire (openldap) — elle COMPTE les entrees. Un annuaire vide repond success a tout : le mensonge des sauvegardes vides, vert et sans contenu. zones (powerdns) — un autoritatif sans zone repond NXDOMAIN a tout, ce qui se lit comme « ce nom n existe pas ». edge (nginx) — elle valide la configuration SUR DISQUE : nginx sert la derniere valide, et une configuration cassee ne se voit qu au prochain demarrage, souvent des mois plus tard. Les cinq eprouvees vertes sur le sain puis rouges PAR PARAMETRE, sans toucher a un service. Etat : 20 sondes sur 19 roles, 23 services distincts, 70 instances, 67 au vert. Les trois autres sont connues : deux sauvegardes sans donnee a emporter, et Loki en delai de stabilisation apres redeploiement. make prouver : CONFORME, 64 OK, 0 echec, 0 saute. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q
2026-09-10 03:47:03 -04:00
# --- Sonde de supervision -----------------------------------------------------------
# La zone souveraine et son inverse : deux au minimum.
serveur_powerdns_sonde_minimum: 2