# 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 :
chezlepro.internal
Elle est definie dans :
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 :
hote dans hotes_actifs
ansible_host defini
Exemple :
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.