# serveur_resolveur

**Le résolveur de l'écosystème** : un seul Unbound pour tout le tenant, récursif depuis
les serveurs racine, qui délègue la zone souveraine à PowerDNS.

## Pourquoi un seul, et pourquoi ici

Avant le 2026-08-24, `client_unbound` posait un Unbound sur **chaque VM**. Ça marchait et
c'était parfaitement étanche — mais c'était N démons identiques pour un service unique.

Mesure prise avant de décider : **~21 Mo de RSS par VM**, et **28 à 189 requêtes** servies
depuis le démarrage. Le gain de cache mutualisé est donc négligeable ; ce qu'on récupère,
c'est un démon au lieu de quatorze, et **un endroit à regarder** au lieu de quatorze.

## Pourquoi pas sur la frontière

Un résolveur partagé par tout le SITE — l'OPNsense — aurait été le geste le plus économe.
Il devrait alors connaître la zone interne de **chaque tenant** : sans vues par réseau
soigneusement réglées, le tenant A résoudrait les noms du tenant B. C'est l'étanchéité
qu'on protège partout ailleurs.

Et un tenant dont le résolveur vit chez l'hébergeur **ne peut plus s'émanciper avec**
(voir `docs/filiation-emancipation.md`).

La récursion est générique ; **la zone interne ne l'est pas**. C'est ce qui fait du
résolveur un service de tenant, et non de fabric.

## La cohabitation avec l'autoritatif

Les deux vivent sur `infra-dns-01` et voudraient le port 53. Le partage est **dérivé, pas
déclaré** — l'exploitant n'a pas à se souvenir de déplacer un port parce qu'il a ajouté un
rôle :

```
resolveur (Unbound)    10.29.19.11:53  +  127.0.0.1:53     la seule porte
autoritatif (PowerDNS) 127.0.0.1:5300                      derrière lui
```

Personne n'interroge l'autoritatif directement. Le résolveur le prend en `stub-zone`.

## Aucun transitaire

`forward-addr` reste vide : Unbound récurse depuis la racine. Poser un transitaire
reviendrait à confier chaque question de l'écosystème à un tiers — ce que la bascule du
2026-08-23 avait justement supprimé.

## Ce qu'il vérifie avant de se déclarer bon

Il interroge sa propre adresse pour la **zone interne** *et* pour un nom de l'**Internet**.
Un résolveur « active » qui ne répond pas est le pire des cas : toute la flotte pointe vers
lui, et découvre la panne en essayant de résoudre — c'est-à-dire au moment où le
diagnostic lui-même devient impossible.

## Variables principales

| Variable | Défaut | Rôle |
|---|---|---|
| `serveur_resolveur_ecoutes` | loopback + IP du tenant | où il répond |
| `serveur_resolveur_reseaux_autorises` | le supernet du tenant | qui a le droit de demander |
| `serveur_resolveur_autoritatif` | `127.0.0.1:5300` | la zone souveraine |
| `serveur_resolveur_transitaires` | `[]` | vide = récursion depuis la racine |

## Ce que ce rôle ne fait pas

Il ne bascule aucun `/etc/resolv.conf` — c'est le travail de `client_resolveur`, qui
valide que ce service répond **avant** de désigner qui que ce soit.