# DNS interne Chezlepro Le service DNS interne est la premiere capacite de plateforme. ## Groupes ```text serveurs_powerdns -> service DNS central PowerDNS Authoritative clients_dns -> integration cliente DNS ``` `clients_dns` depend de `serveurs_powerdns` dans `docs/dependances-groupes.yml`. ## Zone initiale La zone initiale est : ```text chezlepro.internal ``` Elle est definie dans : ```text inventories/production/group_vars/serveurs_powerdns.yml ``` ## Enregistrement automatique Le role `serveurs_powerdns` genere la zone a partir de l'inventaire. Les hotes qui remplissent ces conditions sont ajoutes automatiquement : ```text hote dans hotes_actifs ansible_host defini ``` Exemple : ```text web-frontal-01 ansible_host=10.1.15.31 -> web-frontal-01.chezlepro.internal A 10.1.15.31 ``` Les enregistrements additionnels explicites sont dans `serveurs_powerdns_records`. ## Backend PowerDNS Le premier jalon utilise le backend BIND de PowerDNS. Raison : - pas de dependance prematuree a PostgreSQL ; - zone lisible et generee par Ansible ; - idempotence simple ; - bon point de depart pour la supervision. Quand `serveurs_postgresql` sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie. ## Clients DNS Le role `clients_dns` valide : - qu'un serveur `serveurs_powerdns` actif existe ; - que la zone repond a une requete SOA ; - que le nom de l'hote existe dans la zone. La modification du resolver local est protegee : ```yaml clients_dns_apply: true clients_dns_confirm: true ``` Sans ces deux variables, le role valide les prerequis mais ne modifie pas `/etc/resolv.conf`. Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms. ## Surveillance a prevoir Les premiers checks utiles : - service `pdns` actif ; - port UDP/TCP 53 disponible ; - SOA de `chezlepro.internal` resoluble ; - enregistrement `ns1.chezlepro.internal` resoluble ; - enregistrements des hotes actifs presents ; - serial de zone attendu ; - latence de resolution.