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>
78 lines
3.6 KiB
Markdown
78 lines
3.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.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
|
|
|
|
1. **Le plancher, sans DNS.** Sur un nœud :
|
|
```bash
|
|
getent hosts keycloak.lab.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.lab.chezlepro.internal keycloak.lab.chezlepro.internal A +short
|
|
dig @infra-dns-01.lab.chezlepro.internal lab.chezlepro.internal SOA +short
|
|
```
|
|
3. **Vois les couches.** Compare `getent hosts` (plancher) et `dig` (DNS) : **deux chemins**, même IP.
|
|
4. **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*.
|