Daniel Allaire
e006dee693
Supprimés (supersédés / hors-conception) : serveur_sendmail (→ Postfix), client_dns (→ plancher + client_unbound), client_ldap (login LDAP OS, hors design). Rôles + playbooks de groupe retirés. Nettoyage des références : - dependances-groupes.yml : entrées client_dns/client_ldap retirées + entrées mortes des scaffoldings (nextcloud/collabora/client_supervision) ; deps périmées corrigées (client_smtp → serveur_postfix ; serveur_keycloak → serveur_postgresql, la raison parlait à tort de Nextcloud). - 6 modèles d'exemple : app mail serveur_sendmail → serveur_postfix. - README, AGENTS : listes/glossaire nettoyés. - catalogue-services : listes, tables, roadmap ; note « rôles retirés ». - nomenclature-vm : infra-mail-01 → serveur_dovecot (était faux). - courriel-conception, dns-interne (re-ciblé client_unbound), pouvoirs, intrants, READMEs (client_smtp/forgejo/openldap/unbound). ansible-lint : 0 échec (366 fichiers). instancier OK. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
95 lines
2.6 KiB
Markdown
95 lines
2.6 KiB
Markdown
# 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. Le resolveur local `client_unbound` est
|
|
> **optionnel** (opt-in, avec bascule validee) : sans lui, le plancher `/etc/hosts` suffit.
|
|
|
|
## Groupes
|
|
|
|
```text
|
|
serveur_powerdns -> service DNS central PowerDNS Authoritative
|
|
client_unbound -> resolveur local optionnel (opt-in, bascule validee)
|
|
```
|
|
|
|
`client_unbound` (résolveur local optionnel) peut viser PowerDNS en stub-zone + récursion.
|
|
|
|
## Zone initiale
|
|
|
|
La zone initiale est :
|
|
|
|
```text
|
|
exemple.internal
|
|
```
|
|
|
|
Elle est definie dans :
|
|
|
|
```text
|
|
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 :
|
|
|
|
```text
|
|
hote dans hotes_actifs
|
|
ansible_host defini
|
|
```
|
|
|
|
Exemple :
|
|
|
|
```text
|
|
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.
|
|
|
|
## Résolveur local (optionnel)
|
|
|
|
Le role `client_unbound` (opt-in) installe un résolveur récursif local qui, en stub-zone,
|
|
délègue les noms internes à PowerDNS et récurse le reste.
|
|
|
|
La bascule du resolver local est **protegee** (le role valide qu'Unbound répond AVANT de
|
|
basculer `/etc/resolv.conf`) :
|
|
|
|
```yaml
|
|
client_unbound_apply: true
|
|
client_unbound_confirm: true
|
|
```
|
|
|
|
Sans ces deux variables, le role prépare Unbound 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.
|