Daniel Allaire aab1bcc83a doc : rangee par lecteur, trois portes d'entree (architecture, setup, usage) et un index

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>

2026-10-15 01:01:54 -04:00

2.9 KiB

Raw Blame History

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.

2.9 KiB Raw Blame History