verifier / verifier (push) Has been cancelled

Details

documentation : la tournee des 74 documents, parce qu un balayage ne lit pas

La revision a commence par un balayage par motifs — chemins morts, cibles make
absentes, comptes derives. Il a trouve une trentaine d ecarts et rate presque
tout le reste : un motif ne voit que ce qui s exprime en motif.

make hote-planifier en est l exemple. La cible EXISTE, donc le controle passait
au vert. C est une cible depreciee qui refuse et sort en 2, recommandee par
AGENTS.md, et qui contredit la REGLE D OR du meme fichier trois ecrans plus
haut. Il fallait lire pour la voir.

74 documents lus un par un. 66 corriges, 8 exacts.

CE QUI ETAIT FRANCHEMENT FAUX

AGENTS.md, la source d autorite, annoncait la flotte pas encore executee contre
des VM reelles. Elle a ete rasee et remontee depuis zero trois fois.
ecosysteme-chezlepro.md, le document montre a un client, portait la meme
phrase : il se sous-vendait gravement.

courriel-conception.md s ouvrait sur aucun role n est encore ecrit, au-dessus de
son propre paragraphe 1 qui les nomme. autorisation.md se terminait sur rien n
est construit alors qu il rapporte des mesures datees du role en fonctionnement.
hebergeur-exploitation.md disait rien n est fait d un depot qui existe.
filiation-emancipation.md se contredisait a deux ecrans de distance.

DES MODELES DECRITS D APRES UN MONDE ANTERIEUR

Le resolveur : cinq documents decrivaient un Unbound par VM en opt-in, trois le
donnaient en exemple d integration FACULTATIVE — il est universel depuis le
2026-08-24. L adressage de nomenclature-vm.md : reseau unique, VLAN 11-15, VMID
a cinq chiffres. Le nommage SDN de sdn-evpn.md contre le code : c est le wiki
qui avait raison.

CE QUI CASSE AU PREMIER ESSAI

Le nom du gabarit dore etait faux a quatre endroits, dont la procedure qui le
FABRIQUE et le critere R2 de l epreuve d operateur independant.
preparer-un-site-hebergeur.md avertissait qu une VM faite a la main serait
detruite : raser derive du plan, il ne la detruira jamais — le risque est l
inverse. Un mot de passe d essai en clair dans un depot public.

DEUX PREUVES ETENDUES, ET UNE QUI SE TROMPAIT ELLE-MEME

P57 couvre les groupes : elle a signale aussitot 29 groupes annonces au-dessus d
un tableau qui en cite 40. P29 confronte le tableau de authentification.md aux
declarations reelles : 12 annonces, 21 reels.

Et P57 imposait un chiffre faux — 56 preuves alors que le depot en porte 57, la
conditionnelle vivant hors de tout comptage. Un garde-fou qui fait respecter une
erreur ajoute l assurance a l erreur.

CE QUI RESTE, ET QU AUCUNE PREUVE NE TIENT

Deux comptes trouves a la main. Et une lacune reelle : rien ne garde les
meta/acces.yml — ni qu un service web-sso en porte un, ni que le groupe qu il
nomme existe. P29 tient les positions d authentification, personne ne tient les
habilitations.

make prouver : CONFORME, 56 OK, 0 echec, 1 saute. 0 lien mort.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Crgis8CxCWkAGFA1ecBz3q

2026-09-06 16:18:23 -04:00

4.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.chezlepro.internal → 10.17.17.11.

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. 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	`serveur_resolveur` — un Unbound pour tout le tenant	récurse depuis la racine, délègue la zone souveraine à PowerDNS.
(l'intégration)	`client_resolveur` — universelle, sur chaque nœud	n'installe rien : écrit `/etc/resolv.conf` pour désigner le résolveur ci-dessus.

Le récursif n'est plus « local », et il n'est plus optionnel. Avant le 2026-08-24, client_resolveur posait un Unbound sur chaque VM — N démons identiques pour un service unique. Il n'installe plus rien, et son intégration est universelle, sans aucune exemption : pas même l'hôte qui porte le résolveur, qui se sert lui-même.

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 10.17.16.11 keycloak.chezlepro.internal 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.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.chezlepro.internal keycloak.chezlepro.internal A +short
dig @infra-dns-01.chezlepro.internal chezlepro.internal SOA +short

Vois les couches. Compare getent hosts (plancher) et dig (DNS) : deux chemins, même IP.
Casse & répare. Vide /etc/hosts de ses entrées chezlepro (garde une sauvegarde !) et pointe /etc/resolv.conf ailleurs : la résolution interne échoue. Restaure /etc/hosts seul : ça remarche sans DNS. Tu viens de sentir pourquoi le plancher est le filet de sécurité.
Le piège du récursif. Demande un nom qui n'existe pas sous internal., puis redemande un nom qui existe. Si le résolveur répond NXDOMAIN aux deux, tu viens de reproduire la panne de deux jours du 2026-09-02 : la racine étant signée, elle prouve que internal. n'existe pas, et Unbound étend ce « non » à tout ce qui est dessous — sans jamais interroger la stub-zone. Remède : harden-below-nxdomain: no.

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 intégration universelle (elle suit l'existence de serveur_resolveur) — voir l'unité Liaisons et docs/integrations-vm.md.

4.6 KiB Raw Blame History