67 lines
2.9 KiB
Markdown
67 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/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.
|