Daniel Allaire
1295eeaf4e
Contrainte de l'exploitant apres avoir vu backup-01 et collab-01 crees avant l'AC et le DNS. Ma premiere reponse etait incomplete : un clone est bien inerte, mais un echec a la 12e VM coute 40 minutes sans rien deployer, et le journal donne l'impression que le moteur ignore ses couches. Mesure avant de coder : - enregistrements A : DEJA derives du plan (zone generee depuis hotes_actifs) - zone inverse / PTR : n'existe NULLE PART, aucun role ne touche in-addr.arpa - ordre d'amorcage : aucun, deployer-tout est par couches Le premier point a reduit le travail de moitie — j'allais ecrire un enrolement DNS par hote alors que la zone directe etait deja correcte. Zone inverse derivee du supernet (27.10.in-addr.arpa), PTR issus de la MEME source que les A : pas d'endroit ou elles puissent diverger. Vide si le supernet n'est pas un /16. _amorcer-socle monte l'AC puis le DNS completement avant deployer-tout ; les deux derives de applications.<app>.hote, dans un ordre causal et non alphabetique. Deux exceptions assumees : l'AC s'auto-signe, le DNS pose son propre enregistrement. P10 a attrape un handler que je venais d'inventer (Recharger PowerDNS au lieu de Validate and reload PowerDNS) avant tout deploiement. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
55 lines
2.4 KiB
YAML
55 lines
2.4 KiB
YAML
---
|
|
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_unbound` exempte cet hote.
|
|
# PowerDNS reste autoritatif pur : il repond pour la zone souveraine et REFUSE le reste.
|
|
serveur_powerdns_listen_addresses:
|
|
- "{{ 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: []
|
|
|
|
# Zone INVERSE — DERIVEE du supernet, jamais ecrite. Un /16 `10.(10+index).0.0` donne
|
|
# `(10+index).10.in-addr.arpa`. Vide si le supernet n'est pas connu ou n'est pas un /16 :
|
|
# mieux vaut pas de zone inverse qu'une zone fausse.
|
|
#
|
|
# Pourquoi elle manquait. Rien dans le moteur ne touchait `in-addr.arpa` — mesure du
|
|
# 2026-08-08. Un hote pouvait donc etre resolu par son nom et rester anonyme a l'envers,
|
|
# ce que la plupart des services de courriel et de journalisation reprochent en silence.
|
|
serveur_powerdns_zone_inverse: >-
|
|
{{ (setops_supernet | default('') | ansible.utils.ipaddr('prefix') | int == 16)
|
|
| ternary(
|
|
(setops_supernet | default('0.0.0.0/0')).split('.')[1] ~ '.'
|
|
~ (setops_supernet | default('0.0.0.0/0')).split('.')[0] ~ '.in-addr.arpa',
|
|
'') }}
|