Daniel Allaire
e5841ea684
Some checks are pending
verifier / verifier (push) Waiting to run
Le site ne servait aucun PTR. `serveur_powerdns_zone_inverse` derivait d'un supernet /16 — la forme d'un TENANT, qui tire tout de son index. Un site ne derive pas : il declare plusieurs /24 et n'a pas de supernet unique, si bien que la derivation rendait une chaine vide et qu'aucune zone n'etait generee. Le site revendique desormais exactement ce qu'il occupe : 31.0.10.in-addr.arpa 32.0.10.in-addr.arpa 33.0.10.in-addr.arpa 34.0.10.in-addr.arpa Revendiquer `0.10.in-addr.arpa` d'un seul geste aurait ete plus simple et faux : cette zone couvre aussi la frontiere, le transit et les hyperviseurs, qui ne sont pas a lui. Une autorite qu'on s'attribue sans l'exercer est une panne differee — le resolveur repondrait NXDOMAIN pour des adresses qu'un autre sait nommer. LA DERIVATION VIT DANS UN FILTRE (`zones_inverses`) parce qu'elle a DEUX appelants : `serveur_powerdns` ecrit ces zones, `serveur_resolveur` les delegue a l'autoritatif. Deux calculs separes finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge. Le nom d'une zone dit sa profondeur — trois etiquettes numeriques valent un /24, deux valent un /16 — et le modele en deduit seul la forme du PTR. DEUX CHEMINS MORTS TROUVES EN ROUTE. Les zones etaient servies, et personne ne les demandait. `serveur_resolveur` deleguait la zone directe par une `stub-zone` mais pas les inverses : `dig -x` rendait vide depuis les cinq machines alors que la meme requete posee directement a l'autoritatif repondait juste. Un service correct derriere un chemin que rien n'emprunte. Puis, les stubs poses, Unbound repondait toujours NXDOMAIN avec le drapeau `aa` — une reponse AUTORITAIRE, sans jamais consulter le stub. Il embarque des `local-zone` pour tout l'espace RFC1918 inverse. `nodefault` n'y change rien : ce mode n'agit que si le nom correspond EXACTEMENT a une zone par defaut, et la sienne est `10.in-addr.arpa`, le /8 entier. C'est `transparent` qui laisse la requete suivre son cours — pour nos quatre zones seulement, la ou `unblock-lan-zones` aurait ouvert tout l'espace prive. Rien ne distinguait ce blocage d'une absence : le meme NXDOMAIN qu'un nom qui n'existe pas. AUSSI : les zones inverses sont desormais validees par `named-checkzone` comme la directe (un fichier mal forme etait refuse en silence par PowerDNS), et une zone qu'un ecosysteme cesse de revendiquer est retiree du repertoire. VERIFICATION. Les cinq PTR resolvent depuis les cinq hotes par le resolveur, les huit noms directs par le plancher ET par le DNS, et les deux roles sont idempotents (changed=0). P47 evalue la derivation sur cinq cas — un site a quatre zones, un tenant a une, deux machines d'un meme /24 qui n'en font qu'une, aucune adresse, une adresse illisible. Controle negatif verifie. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
61 lines
3 KiB
YAML
61 lines
3 KiB
YAML
---
|
|
# LE RÉSOLVEUR DE L'ÉCOSYSTÈME — un seul, pour tout le tenant.
|
|
#
|
|
# Avant : un Unbound sur CHAQUE VM, écoutant sur 127.0.0.1. Ça marchait, et c'était
|
|
# parfaitement étanche — mais c'était N démons identiques pour un service unique.
|
|
#
|
|
# MESURE DU 2026-08-24, avant de décider : ~21 Mo de RSS par VM, et entre 28 et 189
|
|
# requêtes servies depuis le démarrage. Le gain de cache mutualisé est donc négligeable ;
|
|
# ce qu'on récupère, c'est un démon au lieu de quatorze, et un endroit à regarder au lieu
|
|
# de quatorze.
|
|
#
|
|
# POURQUOI PAS SUR LA FRONTIÈRE (OPNsense), qui aurait été le geste le plus économe : un
|
|
# résolveur partagé par tout le SITE devrait connaître la zone interne de CHAQUE tenant.
|
|
# Sans vues par réseau soigneusement réglées, le tenant A résoudrait les noms du tenant B
|
|
# — l'étanchéité qu'on protège partout ailleurs. Et un tenant dont le résolveur vit chez
|
|
# l'hébergeur ne peut plus s'émanciper avec (docs/filiation-emancipation.md).
|
|
#
|
|
# La récursion est générique ; la ZONE INTERNE ne l'est pas. C'est ce qui fait du
|
|
# résolveur un service de TENANT, et non de fabric.
|
|
|
|
serveur_resolveur_paquets:
|
|
- unbound
|
|
serveur_resolveur_service: "unbound"
|
|
|
|
# Il écoute pour toute la flotte du tenant — plus seulement pour lui-même.
|
|
serveur_resolveur_ecoutes:
|
|
- "127.0.0.1"
|
|
- "{{ ansible_host }}"
|
|
|
|
# QUI A LE DROIT DE L'INTERROGER : le supernet du tenant, dérivé du seed comme tout le
|
|
# reste. Un résolveur ouvert au monde est un relais d'amplification.
|
|
serveur_resolveur_reseaux_autorises:
|
|
- "{{ setops_supernet | default('127.0.0.0/8') }}"
|
|
|
|
# La zone souveraine et son autoritatif. PowerDNS se replie sur la loopback quand il
|
|
# partage cet hôte (voir serveur_powerdns/defaults), pour lui laisser le port 53.
|
|
serveur_resolveur_zone_interne: "{{ domaine_interne }}"
|
|
serveur_resolveur_autoritatif: "127.0.0.1"
|
|
serveur_resolveur_autoritatif_port: 5300
|
|
|
|
# LE RESOLVEUR DELEGUE A L'AUTORITATIF CE QUE L'AUTORITATIF SERT (2026-08-25).
|
|
#
|
|
# La zone souveraine lui etait deleguee par une `stub-zone` ; les zones INVERSES ne
|
|
# l'etaient pas. PowerDNS servait donc les PTR sur son port, et personne ne les lui
|
|
# demandait : `dig -x` rendait vide depuis les cinq machines alors que la meme requete
|
|
# posee directement a l'autoritatif repondait juste.
|
|
#
|
|
# C'est la panne que le depot connait deja sous une autre forme — un service correct
|
|
# derriere un chemin que rien n'emprunte.
|
|
#
|
|
# MEME DERIVATION QUE `serveur_powerdns`, par le meme filtre : deux calculs separes
|
|
# finiraient par diverger, et la divergence ne se verrait qu'au premier PTR interroge.
|
|
serveur_resolveur_zones_inverses: >-
|
|
{{ (groups.get('hotes_actifs', []) | map('extract', hostvars, 'ansible_host')
|
|
| select | list)
|
|
| zones_inverses(setops_supernet | default('')) }}
|
|
|
|
# AUCUN TRANSITAIRE : Unbound récurse depuis les serveurs racine. Poser un transitaire ici
|
|
# reviendrait à confier chaque question de l'écosystème à un tiers — ce que la bascule du
|
|
# 2026-08-23 avait justement supprimé.
|
|
serveur_resolveur_transitaires: []
|