Daniel Allaire
5bc3bceac1
Some checks failed
verifier / verifier (push) Has been cancelled
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
90 lines
4.6 KiB
Markdown
90 lines
4.6 KiB
Markdown
# 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
|
|
|
|
1. **Le plancher, sans DNS.** Sur un nœud :
|
|
```bash
|
|
getent hosts keycloak.chezlepro.internal # répond via /etc/hosts, zéro DNS
|
|
grep chezlepro /etc/hosts | head
|
|
```
|
|
2. **Interroge l'autoritatif.** Demande à PowerDNS directement :
|
|
```bash
|
|
dig @infra-dns-01.chezlepro.internal keycloak.chezlepro.internal A +short
|
|
dig @infra-dns-01.chezlepro.internal chezlepro.internal SOA +short
|
|
```
|
|
3. **Vois les couches.** Compare `getent hosts` (plancher) et `dig` (DNS) : **deux chemins**, même IP.
|
|
4. **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é.
|
|
5. **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`.
|