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_resolveurposait 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) etdig(DNS) : deux chemins, même IP. - Casse & répare. Vide
/etc/hostsde ses entréeschezlepro(garde une sauvegarde !) et pointe/etc/resolv.confailleurs : la résolution interne échoue. Restaure/etc/hostsseul : ç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 queinternal.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_resolveurest une intégration universelle (elle suit l'existence deserveur_resolveur) — voir l'unité Liaisons etdocs/integrations-vm.md.
Set-OPS
Tu viens d'arriver
Unités d'apprentissage
Fondations
Communication
Données
Observabilité
Socle & méthode
- Le GUI (console d'exploitation)
- Virtualisation & clonage
- Sécurité & durcissement
- Infra as Code & idempotence
- Le plan & l'adressage dérivé
- Liaisons (bindings)
Flotte & preuve
Opérations
- Runbooks → dépôt
docs/runbooks-exploitation.md
Repères
- Glossaire
- Référence technique → dépôt
docs/