Set-OPS/docs/dns-interne.md

DNS interne Chezlepro

Le service DNS interne est la premiere capacite de plateforme.

Groupes

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-01 ansible_host=192.168.12.101
-> web-01.chezlepro.internal A 192.168.12.101

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 :

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.