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>
53 lines
2.6 KiB
Markdown
53 lines
2.6 KiB
Markdown
# client_resolveur
|
|
|
|
**Résolveur local** par nœud (Unbound) : cache + récursion, avec une **stub-zone** vers
|
|
l'autoritatif interne (PowerDNS). Rend la résolution *dynamique* sans casser Internet.
|
|
Troisième et dernière couche du DNS interne (`docs/dns-interne.md`).
|
|
|
|
## Les trois couches
|
|
1. `hosts_statiques` — plancher `/etc/hosts`, toujours là, indépendant de tout service ;
|
|
2. `serveur_powerdns` — autoritatif de la zone interne ;
|
|
3. **ce rôle** — résolveur local, **opt-in**, qui rend la résolution dynamique par nœud.
|
|
|
|
## Rôle
|
|
- Installe `unbound` et `bind9-dnsutils` (`dig`, pour valider **avant** de basculer).
|
|
- Déploie `setops.conf` : écoute sur `127.0.0.1`, stub-zone vers l'autoritatif interne,
|
|
récursion (ou transitaires) pour le reste d'Internet.
|
|
- Valide la configuration (`unbound-checkconf`), active le service.
|
|
- **Bascule** `/etc/resolv.conf` vers `127.0.0.1` — protégée (voir ci-dessous).
|
|
|
|
## Garde-fou de bascule (anti-coupure)
|
|
Changer le résolveur d'un nœud à distance, c'est risquer de le rendre muet. Le rôle exige
|
|
donc **deux** interrupteurs, et vérifie avant d'agir :
|
|
|
|
```yaml
|
|
client_resolveur_apply: true
|
|
client_resolveur_confirm: true
|
|
```
|
|
|
|
Sans les deux, le rôle installe et démarre Unbound mais **ne touche pas** à `/etc/resolv.conf`
|
|
(refus explicite). Avec les deux, il applique d'abord les redémarrages en attente, puis
|
|
**valide qu'Unbound résout réellement** (un nom interne *et* un nom Internet) — et ne bascule
|
|
qu'ensuite. Même doctrine que la règle 4 d'`AGENTS.md` : action risquée = confirmation explicite.
|
|
|
|
## Variables
|
|
| Variable | Défaut | Rôle |
|
|
| --- | --- | --- |
|
|
| `client_resolveur_ecoute` | `127.0.0.1` | Écoute (boucle locale) |
|
|
| `client_resolveur_zone_interne` | `{{ domaine_interne }}` | Zone en stub |
|
|
| `client_resolveur_dns_autoritatif` | dérivé du groupe `serveur_powerdns` | Cible de la stub-zone |
|
|
| `client_resolveur_transitaires` | `[]` | Vide = récursion propre (racine + DNSSEC) |
|
|
| `client_resolveur_apply` / `_confirm` | `false` / `false` | Bascule de `/etc/resolv.conf` |
|
|
|
|
## Flux (`meta/flux.yml`)
|
|
`53/udp` entrant en **localhost** · `53/tcp` sortant vers `serveur_powerdns`.
|
|
|
|
## Notes / limites
|
|
- Transitaires vides = Unbound **récurse lui-même** (racine + DNSSEC). Si la récursion
|
|
sortante est bloquée par le réseau, renseigner `client_resolveur_transitaires`.
|
|
- Le rôle exige l'IP de l'autoritatif interne (assertion) : `serveur_powerdns` doit être
|
|
dans l'inventaire avec un `ansible_host`.
|
|
- DoT (DNS chiffré) n'est pas encore branché — c'est un des flux restants du zéro-confiance.
|
|
|
|
## Prérequis
|
|
- `serveur_powerdns` actif. Couche **agents**.
|