Daniel Allaire db2d6f6bf0 resolveur : un par tenant, et non plus un par machine

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>

2026-08-24 16:59:34 -04:00

3.6 KiB

Raw Blame History

DNS & résolution de noms

Unité d'apprentissage. Moule : ① concept → ② Set-OPS → ③ transférable → ④ à toi de jouer.

① Le concept (générique)

Les machines se parlent par adresses IP ; les humains (et les configs) utilisent des noms. La résolution de noms fait le pont : keycloak.lab… → 192.168.15.21.

Plusieurs couches, de la plus locale à la plus globale :

Fichier hosts (/etc/hosts) : une table statique, locale, consultée en premier, sans aucun réseau. Increvable, mais manuelle.
DNS autoritatif : le serveur qui détient la vérité d'une zone (ex. lab.chezlepro.internal) et répond pour ses noms (enregistrements A, SOA…).
DNS récursif (résolveur) : celui que tes machines interrogent ; il cherche pour toi (cache local, puis interne, puis Internet).

Distinction-clé souvent floue : autoritatif (« je possède ce nom ») ≠ récursif (« je vais chercher la réponse pour toi »).

② Comment Set-OPS le fait — trois couches

Couche	Pièce	Propriété
1. Le plancher	`hosts_statiques` (socle) → `/etc/hosts` sur chaque nœud	résout même DNS éteint, dès le bootstrap. Le filet en dessous de tout.
2. Autoritatif	`serveur_powerdns` (PowerDNS)	la zone interne, les enregistrements A.
3. Récursif local	`client_resolveur` (opt-in)	résolveur local : stub-zone → PowerDNS pour l'interne, récursion pour le reste.

Le plancher est le cœur pédagogique : parce que chaque nœud connaît tout l'écosystème par /etc/hosts, rien ne dépend du DNS pour démarrer — PowerDNS devient une commodité, pas un point de défaillance unique. On construit la robustesse de bas en haut.

C'est aussi ce que tu utilises depuis ta machine : mettre 192.168.15.21 keycloak.lab… dans ton /etc/hosts, c'est exactement le même « plancher ».

③ Pourquoi c'est transférable

Set-OPS	Équivalents ailleurs
`/etc/hosts`	identique sur tout OS (Linux, macOS, Windows)
PowerDNS autoritatif	BIND · Knot · NSD · Route 53 / Cloud DNS (autoritatifs)
Unbound récursif	`systemd-resolved` · dnsmasq · le résolveur de ton FAI · 1.1.1.1

Tu as appris la hiérarchie de résolution (hosts → récursif → autoritatif) et la distinction autoritatif/récursif — pas « PowerDNS ». Ça vaut partout.

④ À toi de jouer

Le plancher, sans DNS. Sur un nœud :

getent hosts keycloak.lab.chezlepro.internal    # répond via /etc/hosts, zéro DNS
grep chezlepro /etc/hosts | head

Interroge l'autoritatif. Demande à PowerDNS directement :

dig @infra-dns-01.lab.chezlepro.internal keycloak.lab.chezlepro.internal A +short
dig @infra-dns-01.lab.chezlepro.internal lab.chezlepro.internal SOA +short

Vois les couches. Compare getent hosts (plancher) et dig (DNS) : deux chemins, même IP.
Casse & répare. Sur un nœud sans client_resolveur, vide /etc/hosts de ses entrées chezlepro (garde une sauvegarde !) et coupe l'accès au DNS : la résolution interne échoue. Restaure /etc/hosts : ça remarche sans DNS. Tu viens de sentir pourquoi le plancher est le filet de sécurité.

Pour aller plus loin (dépôt)

Rôles : roles/hosts_statiques (le plancher), roles/serveur_powerdns, roles/client_resolveur.
Conception des 3 couches + frontière publique : docs/dns-interne.md.
Note : client_resolveur est une liaison optionnelle (opt-in) — voir l'unité Liaisons.

3.6 KiB Raw Blame History