Set-OPS-Public/docs/dns-interne.md

# 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.