Daniel Allaire
aab1bcc83a
README reduit au role du projet et au demarrage rapide. docs/architecture.md (schemas Mermaid), docs/setup.md, docs/usage.md (154 cibles en 13 familles), docs/README.md (index). Documents ranges en conception/, exploitation/, hebergement/, projet/ ; 598 chemins suivis. QUICKSTART.md, SOLUTION.md, architecture-set-ops.md et la carte fondus puis retires. Preuves : P48 lit l'index et conception/mecanismes.md ; les gardes parcourent docs/ sous- dossiers compris (_documents) ; usage.md suit le Makefile dans les deux sens. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
66 lines
2.9 KiB
Markdown
66 lines
2.9 KiB
Markdown
# 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/conception/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.
|