# DNS interne

Le service DNS interne est la premiere capacite de plateforme.

## Groupes

```text
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 :

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

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

```yaml
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.