Daniel Allaire a9a1493440 Plancher de résolution /etc/hosts (indépendant du DNS)

Nouveau rôle de socle hosts_statiques (dans serveur_debian) : génère
/etc/hosts sur chaque VM depuis l'inventaire. L'écosystème se résout par
nom même DNS éteint, et le bootstrap ne dépend plus du DNS. client_dns
rendu tolérant (inerte sans DNS interne) ; dépendance client_dns→powerdns
passée molle. PowerDNS devient une commodité (zone/externe).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>

2026-06-30 18:05:42 -04:00

2.5 KiB

Raw Blame History

DNS interne

Le service DNS interne est la premiere capacite de plateforme.

Plancher de resolution independant du DNS. Le socle (hosts_statiques, dans serveur_debian) genere /etc/hosts sur chaque VM depuis l'inventaire : tout l'ecosysteme se resout par nom meme serveur DNS eteint (et au bootstrap, avant que PowerDNS ne soit la). PowerDNS devient une commodite (zone, externe, dynamique), plus un point de defaillance : la dependance client_dns -> powerdns est molle (client_dns est inerte si aucun DNS interne n'existe).

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_dns       -> integration cliente DNS

client_dns depend de serveur_powerdns dans docs/dependances-groupes.yml.

Zone initiale

La zone initiale est :

exemple.internal

Elle est definie dans :

instance/inventories/production/group_vars/serveur_powerdns.yml

Enregistrement automatique

Le role serveur_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.0.2.31
-> web-frontal-01.exemple.internal A 10.0.2.31

Les enregistrements additionnels explicites sont dans serveur_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 serveur_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Clients DNS

Le role client_dns valide :

qu'un serveur serveur_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 :

client_dns_apply: true
client_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 exemple.internal resoluble ;
enregistrement ns1.exemple.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2.5 KiB Raw Blame History