Daniel Allaire
cdac6d0ea5
docs/dns-interne.md couvre desormais le DNS public sur deux sites : vue d'ensemble, chemin d'une requete interne, publication d'une zone, requete de l'Internet, NS d'une zone (cinq schemas Mermaid), et les tableaux des flux, des declarations, des gardes et de la bascule. README de serveur_powerdns et de serveur_dns_public a jour ; le wiki y renvoie. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
91 lines
4.8 KiB
Markdown
91 lines
4.8 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`.
|
|
- Le DNS **public** — le locataire écrit sa zone, deux sites la servent (`dns1.chezlepro.ca`, `dns1.technolibre.ca`) : schémas des processus et des flux dans `docs/dns-interne.md`, et `roles/serveur_dns_public`.
|
|
- Note : `client_resolveur` est une **intégration universelle** (elle suit l'existence de `serveur_resolveur`) — voir l'unité *Liaisons* et `docs/integrations-vm.md`.
|