Daniel Allaire
db2d6f6bf0
Mesure avant de decider : ~21 Mo de RSS par VM pour 28 a 189 requetes servies. Le gain de cache est negligeable ; ce qu'on recupere, c'est un demon au lieu de cinq et un endroit a regarder au lieu de cinq. Pas sur la frontiere : un resolveur de SITE devrait connaitre la zone interne de chaque tenant, et un tenant dont le resolveur vit chez l'hebergeur ne peut plus s'emanciper avec. La recursion est generique, la zone interne ne l'est pas. L'autoritatif se replie sur 127.0.0.1:5300 -- derive de la colocalisation, pas declare a la main. Son port devient `derive` dans meta/flux.yml : les deux lient 53 mais sur des adresses differentes. Deux pieges. Unbound refuse d'interroger une loopback par defaut : sans lever do-not-query-localhost, toute la zone rendait SERVFAIL. Et le plancher /etc/hosts MASQUAIT la panne -- getent repondait, dig disait SERVFAIL. La tache de validation du role avait raison contre moi. client_unbound n'installant plus Unbound, son nom mentait : client_resolveur. Co-Authored-By: Claude Opus 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/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.
|