← tous les articles

Intégrer son DNS au cluster — sans y mettre le résolveur

20 juin 2026 · 4 min de lecture

dnsadguardconfig-as-codeobservabiliteautheliaarchitecture

Après un débogage qui m’a fait croire que Vaultwarden était mort — c’était le DNS — j’ai décidé de ne plus jamais « chipoter » mon résolveur à la main. Il allait devenir un citoyen de première classe de mon infra : configuration versionnée, métriques, alertes, accès SSO. Bref, tout ce que j’exige des autres services.

Tout… sauf une chose. Son moteur ne rentrera pas dans le cluster. Et c’est un choix, pas une paresse.

La règle : on ne met pas le sol à l’intérieur du bâtiment

Le DNS, c’est le sol sur lequel tout le reste est posé. Tirer une image, joindre Cloudflare, résoudre un voisin : une foule de choses ont besoin de DNS pour démarrer.

Si je faisais tourner le résolveur (:53) comme un service Swarm — sur un réseau overlay, derrière une IP virtuelle, derrière le reverse-proxy — je lui donnerais une dépendance circulaire sur le cluster qu’il est censé servir. Le jour où le cluster se reconfigure (je déplace un nœud, un quorum vacille, une IP virtuelle se périme), le LAN entier perdrait le DNS en cascade. Y compris les outils dont j’ai besoin pour réparer.

J’ai passé des semaines à retirer des points uniques de défaillance de ce cluster. Mettre le résolveur dedans serait une régression nette. Donc : le moteur reste sur du matériel dédié, toujours allumé, indépendant. On intègre la gestion, pas le runtime.

Ce qu’on intègre, alors

Tout le reste — et c’est beaucoup.

Config-as-code. Un fichier config.yml est la source de vérité : upstreams, réécritures, listes de blocage, réglages. Un script le réconcilie sur la boîte via son API REST, de façon idempotente et sans redémarrage. Plus jamais d’édition manuelle non tracée.

make adguard-diff    # ce qui changerait (dry-run)
make adguard-apply   # réconcilie la boîte au dépôt — à chaud

Observabilité. Deux sondes, côté cluster, qui surveillent la boîte de l’extérieur. Un exporter lit l’API (volume de requêtes, taux de blocage, top domaines). Et surtout, un blackbox qui envoie une vraie requête DNS sur le :53 :

probe_success{job="blackbox-dns"} == 1   # le DNS résout, point.

C’est le signal qui compte — la vérité de bout en bout, indépendante de l’API. C’était mon plus gros angle mort : je ne surveillais pas la brique dont tout dépend. Si elle tombe, une alerte critique part sur mon téléphone.

SSO. L’interface d’admin est publiée sur une jolie URL, derrière mon portail Authelia — le reverse-proxy du cluster route vers la machine externe (premier backend hors-Swarm de mon infra) et exige une authentification avant de laisser passer quoi que ce soit.

La rançon de la prudence : vérifier que le fournisseur est vivant

Petit aparté qui m’a coûté un détour. Pour ne pas dépendre d’un seul résolveur amont, j’en voulais deux, chiffrés (DoH) et respectueux de la vie privée. Mon choix RGPD : un résolveur européen réputé. Je le configure, je teste… il ne répond pas.

Cause : le projet avait fermé. Le service était tout simplement mort. Leçon bête mais universelle : on vérifie qu’une dépendance est vivante avant de la câbler, on ne se fie pas à sa réputation d’il y a six mois. Je suis reparti sur le DNS public souverain de l’UE, apparié à un résolveur suisse — deux juridictions, en répartition de charge.

Et la haute dispo, alors ?

Le moteur hors-cluster reste un point unique de défaillance — le DNS du LAN tient sur une seule petite machine. La réponse n’est pas un réplica Swarm (ce serait renier toute la démarche), mais un second résolveur indépendant, synchronisé sur le premier, annoncé en DNS secondaire. C’est la suite. La bonne façon de rendre le DNS hautement disponible, c’est avec les outils du DNS — pas en le noyant dans l’orchestrateur.

La leçon

Tout n’a pas vocation à vivre dans le cluster. Pour une brique fondationnelle — celle dont le démarrage de tout le reste dépend — le bon niveau d’intégration, c’est gérer sa configuration et la surveiller comme du code, en laissant son moteur dehors, isolé du domaine de panne qu’il soutient. Le meilleur des deux mondes : géré, observé, accessible — et increvable face aux soubresauts du cluster.


Mon DNS est désormais versionné, observé, alerté et en SSO — sans avoir cédé d’un pouce sur la ligne rouge. Le code (et le config.yml) est public.


📬 La newsletter homelab

Les nouveaux articles + retours d'expérience self-hosting, sans spam. Désinscription en un clic.