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

68 lines
2.9 KiB
YAML
Raw Normal View History

---
- name: Validate PowerDNS zone
ansible.builtin.command:
cmd: "named-checkzone {{ serveur_powerdns_zone }} {{ serveur_powerdns_zone_directory }}/{{ serveur_powerdns_zone }}.zone"
changed_when: false
when: not ansible_check_mode # en dry-run le fichier de zone n'existe pas encore
listen: Validate and reload PowerDNS
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
# UNE ZONE NON VALIDEE EST UNE ZONE QUI PEUT NE PAS ETRE SERVIE. La zone directe etait
# verifiee, les inverses non : PowerDNS refuse silencieusement un fichier mal forme et
# continue de servir le reste, si bien qu'un PTR casse ne se voit qu'a l'usage — et
# l'usage, ici, c'est un journal ou un courriel qui reproche un nom sans le dire.
- name: Validate PowerDNS reverse zones
ansible.builtin.command:
cmd: >-
named-checkzone {{ zone_inverse }}
{{ serveur_powerdns_zone_directory }}/{{ zone_inverse }}.zone
changed_when: false
loop: "{{ serveur_powerdns_zones_inverses | default([]) }}"
loop_control:
loop_var: zone_inverse
when: not ansible_check_mode # en dry-run le fichier de zone n'existe pas encore
listen: Validate and reload PowerDNS
- name: Restart PowerDNS
ansible.builtin.systemd:
name: "{{ serveur_powerdns_service_name }}"
state: restarted
when: not ansible_check_mode # en dry-run le service n'existe pas encore
listen: Validate and reload PowerDNS
# L'INSTANCE PUBLIQUE : on valide chaque zone AVANT de redemarrer — une zone refusee est
# une zone que le secondaire du site cesserait de recevoir, sans erreur visible dehors.
- name: Valider les zones publiques
ansible.builtin.command:
cmd: >-
named-checkzone {{ zone_publique }}
{{ serveur_powerdns_public_zones_dir }}/{{ zone_publique }}.zone
changed_when: false
loop: "{{ serveur_powerdns_zones_publiques | default([]) }}"
loop_control:
loop_var: zone_publique
when: not ansible_check_mode
listen: Valider et redemarrer le DNS public du locataire
- name: Redemarrer l'instance publique
ansible.builtin.systemd:
name: pdns@public
state: restarted
when: not ansible_check_mode
listen: Valider et redemarrer le DNS public du locataire
# PREVENIR LE SITE TOUT DE SUITE : sans notification, le secondaire attendrait le
# rafraichissement du SOA — une heure de retard sur chaque changement.
- name: Notifier le serveur public du site
ansible.builtin.command:
argv: [pdns_control, --config-name=public, notify, "{{ zone_publique }}"]
changed_when: false
# PAS DE `failed_when: false` (retire le 2026-09-16). Il cachait un socket de controle
# introuvable : la notification echouait a chaque deploiement, sans un mot, et un
# changement de zone aurait mis jusqu'a l'expiration du SOA a se propager. Un canal de
# controle casse est un defaut, pas un bruit.
loop: "{{ serveur_powerdns_zones_publiques | default([]) }}"
loop_control:
loop_var: zone_publique
when: not ansible_check_mode
listen: Valider et redemarrer le DNS public du locataire