# GÉNÉRÉ par Set-OPS (rôle serveur_resolveur). NE PAS éditer à la main. server: {% for a in serveur_resolveur_ecoutes %} interface: {{ a }} {% endfor %} {% for r in serveur_resolveur_reseaux_autorises %} access-control: {{ r }} allow {% endfor %} access-control: 127.0.0.0/8 allow hide-identity: yes hide-version: yes prefetch: yes do-ip6: no # La zone souveraine n'est pas signée : on ne la soumet pas à la validation DNSSEC. domain-insecure: "{{ serveur_resolveur_zone_interne }}" # LA RACINE NIE NOTRE TLD, ET UNBOUND ÉTEND CE NON À TOUT CE QUI EST DESSOUS # (mesuré le 2026-09-01). # # `internal.` n'existe pas dans la racine, qui rend donc un NXDOMAIN **signé** — # `dig internal. SOA` le montre avec le drapeau `ad`. `harden-below-nxdomain` # (actif par défaut) tient ce non pour prouvé et fabrique lui-même un NXDOMAIN pour # tout nom sous `internal.`, SANS JAMAIS interroger la `stub-zone` déclarée plus # bas. La délégation était correcte, l'autoritatif répondait juste, et pas une seule # requête ne lui parvenait. # # CE QUE ÇA COÛTAIT : aucun locataire ne pouvait nommer un service du site. Chacun # gravait donc des ADRESSES dans sa configuration — le cache, le résolveur, la # forge — et le site devenait indéplaçable un intrant à la fois. Le défaut ne s'est # pas vu parce que les machines du site, elles, ont le plancher `/etc/hosts` : le # nom marchait partout où on le testait, et nulle part où on en avait besoin. # # `transparent` sur NOTRE zone seulement : la question reprend son cours normal — # donc atteint la `stub-zone` — sans rien changer pour le reste de l'Internet. # Même remède que pour les zones inverses ci-dessous, même cause : un « non » # d'Unbound qu'on ne distingue pas d'une absence. local-zone: "{{ serveur_resolveur_zone_interne }}." transparent {% for zone_inverse in serveur_resolveur_zones_inverses | default([]) %} # Les zones inverses ne le sont pas davantage — et `in-addr.arpa`, LUI, est signé # publiquement. Sans cette ligne, la validation chercherait une chaîne de confiance # vers une délégation qui n'existe pas, et tous les PTR rendraient SERVFAIL. domain-insecure: "{{ zone_inverse }}" # UNBOUND BLOQUE L'INVERSE PRIVÉ PAR DÉFAUT (2026-08-25). # # Il embarque des `local-zone` pour tout l'espace RFC1918 inversé, et y répond # lui-même. Avec la `stub-zone` pourtant bien déclarée, `dig -x` rendait NXDOMAIN # avec le drapeau `aa` — une réponse AUTORITAIRE d'Unbound, qui n'avait jamais # interrogé l'autoritatif. Le même NXDOMAIN qu'un nom qui n'existe pas : rien ne # distinguait le blocage de l'absence. # # `transparent` laisse la requête suivre son cours — donc atteindre la `stub-zone` # ci-dessous — pour CETTE zone seulement. # # Pas `nodefault` : ce mode ne retire un blocage que si le nom correspond EXACTEMENT # à une zone par défaut d'Unbound. La sienne est `10.in-addr.arpa`, le /8 entier ; nos # `/24` n'y correspondent pas, et la ligne restait sans effet — mesuré, le NXDOMAIN # autoritaire persistait après rechargement. # # Pas `unblock-lan-zones: yes` non plus : il aurait débloqué tout l'espace privé # inversé, y compris ce que cet écosystème ne sert pas. local-zone: "{{ zone_inverse }}" transparent {% endfor %} # UNBOUND REFUSE D'INTERROGER UNE LOOPBACK PAR DÉFAUT (2026-08-24). # # `do-not-query-localhost` vaut `yes` d'origine — une protection contre les boucles. # Or l'autoritatif de l'écosystème vit désormais SUR 127.0.0.1:5300, derrière ce # résolveur. Sans cette ligne, toute la zone souveraine rend SERVFAIL. # # Et la panne était MASQUÉE : le plancher /etc/hosts répondait pour les noms de la # flotte, si bien qu'un `getent hosts forge.genese.internal` semblait prouver que la # résolution marchait. Seul un `dig` explicite l'a montrée. do-not-query-localhost: no stub-zone: name: "{{ serveur_resolveur_zone_interne }}" stub-addr: {{ serveur_resolveur_autoritatif }}@{{ serveur_resolveur_autoritatif_port }} {# LES ZONES INVERSES SE DELEGUENT COMME LA DIRECTE (2026-08-25). Sans ces stubs, l'autoritatif servait les PTR 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. Un service correct derriere un chemin que rien n'emprunte. #} {% for zone_inverse in serveur_resolveur_zones_inverses | default([]) %} stub-zone: name: "{{ zone_inverse }}" stub-addr: {{ serveur_resolveur_autoritatif }}@{{ serveur_resolveur_autoritatif_port }} {% endfor %} {% if serveur_resolveur_transitaires %} forward-zone: name: "." {% for f in serveur_resolveur_transitaires %} forward-addr: {{ f }} {% endfor %} {% endif %}