Daniel Allaire db2d6f6bf0 resolveur : un par tenant, et non plus un par machine

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>

2026-08-24 16:59:34 -04:00

2.7 KiB

Raw Blame History

DNS interne

Pour qui : le mainteneur du DNS interne.

Le service DNS interne est la premiere capacite de plateforme.

Plancher de resolution independant du DNS. Le socle (hosts_statiques, dans serveur_debian) genere /etc/hosts sur chaque VM depuis l'inventaire : tout l'ecosysteme se resout par nom meme serveur DNS eteint (et au bootstrap, avant que PowerDNS ne soit la). PowerDNS devient une commodite (zone, externe, dynamique), plus un point de defaillance. Le resolveur local client_resolveur est optionnel (opt-in, avec bascule validee) : sans lui, le plancher /etc/hosts suffit.

Groupes

serveur_powerdns -> service DNS central PowerDNS Authoritative
client_resolveur   -> resolveur local optionnel (opt-in, bascule validee)

client_resolveur (résolveur local optionnel) peut viser PowerDNS en stub-zone + récursion.

Zone initiale

La zone initiale est :

exemple.internal

Elle est definie dans :

instance/inventories/production/group_vars/serveur_powerdns.yml

Enregistrement automatique

Le role serveur_powerdns genere la zone a partir de l'inventaire.

Les hotes qui remplissent ces conditions sont ajoutes automatiquement :

hote dans hotes_actifs
ansible_host defini

Exemple :

web-frontal-01 ansible_host=10.0.2.31
-> web-frontal-01.exemple.internal A 10.0.2.31

Les enregistrements additionnels explicites sont dans serveur_powerdns_records.

Backend PowerDNS

Le premier jalon utilise le backend BIND de PowerDNS.

Raison :

pas de dependance prematuree a PostgreSQL ;
zone lisible et generee par Ansible ;
idempotence simple ;
bon point de depart pour la supervision.

Quand serveur_postgresql sera stable, il sera possible de migrer vers un backend SQL si le besoin operationnel le justifie.

Résolveur local (optionnel)

Le role client_resolveur (opt-in) installe un résolveur récursif local qui, en stub-zone, délègue les noms internes à PowerDNS et récurse le reste.

La bascule du resolver local est protegee (le role valide qu'Unbound répond AVANT de basculer /etc/resolv.conf) :

client_resolveur_apply: true
client_resolveur_confirm: true

Sans ces deux variables, le role prépare Unbound mais ne modifie pas /etc/resolv.conf.

Cette protection est volontaire : une mauvaise configuration DNS peut couper la resolution de noms.

Surveillance a prevoir

Les premiers checks utiles :

service pdns actif ;
port UDP/TCP 53 disponible ;
SOA de exemple.internal resoluble ;
enregistrement ns1.exemple.internal resoluble ;
enregistrements des hotes actifs presents ;
serial de zone attendu ;
latence de resolution.

2.7 KiB Raw Blame History