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>
55 lines
1.9 KiB
YAML
55 lines
1.9 KiB
YAML
---
|
|
- name: Exiger la zone souveraine et un réseau autorisé
|
|
ansible.builtin.assert:
|
|
that:
|
|
- serveur_resolveur_zone_interne | length > 0
|
|
- serveur_resolveur_reseaux_autorises | length > 0
|
|
fail_msg: >-
|
|
serveur_resolveur exige `domaine_interne` et au moins un réseau dans
|
|
`serveur_resolveur_reseaux_autorises`. Un résolveur sans liste d'accès serait
|
|
soit muet, soit un relais ouvert.
|
|
|
|
- name: Installer le résolveur
|
|
ansible.builtin.apt:
|
|
name: "{{ serveur_resolveur_paquets }}"
|
|
state: present
|
|
update_cache: true
|
|
when: not ansible_check_mode
|
|
|
|
- name: Déployer la configuration Set-OPS
|
|
ansible.builtin.template:
|
|
src: setops.conf.j2
|
|
dest: /etc/unbound/unbound.conf.d/setops.conf
|
|
owner: root
|
|
group: root
|
|
mode: "0644"
|
|
notify: Redémarrer le résolveur
|
|
|
|
- name: Valider la configuration avant de la servir
|
|
ansible.builtin.command: unbound-checkconf
|
|
changed_when: false
|
|
when: not ansible_check_mode
|
|
|
|
- name: Activer et démarrer le résolveur
|
|
ansible.builtin.systemd:
|
|
name: "{{ serveur_resolveur_service }}"
|
|
enabled: true
|
|
state: started
|
|
when: not ansible_check_mode
|
|
|
|
- name: Appliquer les redémarrages avant de vérifier
|
|
ansible.builtin.meta: flush_handlers
|
|
|
|
# ÉCRIRE, PUIS RELIRE (D-68). Un résolveur « active » qui ne répond pas est le pire des
|
|
# cas : toute la flotte pointe vers lui, et découvre la panne en essayant de résoudre.
|
|
- name: Répond-il vraiment, pour l'interne ET pour l'Internet ?
|
|
ansible.builtin.command: "dig @{{ ansible_host }} {{ item.nom }} {{ item.type }} +short"
|
|
register: serveur_resolveur_controle
|
|
changed_when: false
|
|
failed_when: serveur_resolveur_controle.stdout | trim == ''
|
|
loop:
|
|
- { nom: "{{ serveur_resolveur_zone_interne }}", type: "SOA" }
|
|
- { nom: "deb.debian.org", type: "A" }
|
|
loop_control:
|
|
label: "{{ item.nom }} {{ item.type }}"
|
|
when: not ansible_check_mode
|