Vaultwarden était « down ». En fait, c'était le DNS qui mentait.

Mes Raspberry Pi sont nomades : je les déplace physiquement un par un, à chaud. Avant de débrancher un nœud, je lance un drill — je vérifie que tout bascule proprement sur les deux autres. Ce jour-là, je fais le tour de mes apps après la coupure d’rpi51, et je tombe sur ça : vaultwarden.zebbox.net ne répond pas. Mon gestionnaire de mots de passe. Le service que tu ne veux surtout pas voir tomber.

Branle-bas de combat. Sauf que… le cluster allait très bien. C’est le DNS qui me mentait.

Premier réflexe : accuser le bon suspect

Vaultwarden est volontairement épinglé au nœud que je venais d’éteindre (ses clés RSA et ses pièces jointes sont en local). Donc « down pendant le drill », c’était attendu. Logique, je passe à autre chose. Sauf qu’après avoir rallumé le nœud et tout revérifié, l’URL restait morte. Là, ça ne collait plus.

J’ouvre les logs côté cluster. Le conteneur tourne, healthcheck vert. En interne, Traefik le sert : /alive renvoie 200. Le service va parfaitement bien. Mais depuis mon poste, https://vaultwarden.zebbox.net ne se connecte même pas — curl n’obtient aucune réponse.

Le détail qui change tout : le bon nom

curl -v finit par cracher la vérité :

vaultwarden.zebbox.net  →  192.168.0.40   (.zebbox.local !)

Deux choses sautent aux yeux. Un : ce n’est pas une IP Cloudflare comme mes autres services, c’est une IP du LAN. Deux : le suffixe .zebbox.local accolé au nom.

Et là, le déclic — doublé d’une gifle : vaultwarden.zebbox.net n’existe pas. Le vrai domaine, c’est vault.zebbox.net (qui, lui, renvoie un sobre 200). Je chassais un fantôme depuis le début.

Mais pourquoi un nom inexistant résout-il vers une IP du LAN plutôt qu’en NXDOMAIN ?

Le mécanisme : domaine de recherche + jokers oubliés

Mon DHCP distribue un domaine de recherche : zebbox.local. Quand un nom public ne résout pas, le résolveur ré-essaie en lui accolant ce suffixe. Donc :

1.  vaultwarden.zebbox.net               → pas de réponse publique (NXDOMAIN)
2.  vaultwarden.zebbox.net.zebbox.local  → MATCH

Et ce *.zebbox.local, il matchait une réécriture dans mon AdGuard :

- domain: '*.zebbox.local'
  answer: 192.168.0.40

Un relic. À l’époque où je faisais tourner des stacks Docker sur mes NAS Synology, j’avais ajouté ce joker « par commodité ». Les NAS ? Éteints (il faisait chaud). Donc : n’importe quel *.zebbox.net sans enregistrement public retombait silencieusement sur un NAS mort. Un piège que je m’étais tendu des mois plus tôt.

Pendant qu’on y est : l’IPv6 contournait le filtre

En auditant le résolveur, deuxième surprise. AdGuard renvoyait toujours les enregistrements AAAA, et ma box distribuait de l’IPv6 — avec, parfois, le résolveur IPv6 du FAI. Or les machines préfèrent l’IPv6. Conséquence : une partie des requêtes DNS partait chez le FAI, court-circuitant AdGuard — donc ni filtrage, ni mes réécritures. De façon intermittente et invisible. Le genre de fuite qui explique les « parfois ça bloque, parfois non » qu’on n’arrive jamais à reproduire.

Le ménage

Problème	Correction
Réécriture `*.zebbox.local` → NAS mort	supprimée (relic Docker-sur-NAS)
Le nom que je croyais juste	c’était `vault.zebbox.net`, pas `vaultwarden.…`
Upstreams DNS en clair (FAI)	DoH only — Quad9 🇨🇭 + DNS4EU 🇪🇺, deux juridictions
Fuite IPv6 (bypass d’AdGuard)	`aaaa_disabled` + IPv6 coupé sur la box

La leçon

Un service en bonne santé peut paraître mort à cause d’une couche qui n’a rien à voir avec lui. Ici, trois pièges empilés : un nom que je croyais connaître, un domaine de recherche que j’avais oublié, et une réécriture-zombie vers une machine débranchée.

La morale que je garde : avant d’accuser l’application, vérifie ce que le nom résout vraiment. Un curl -v ou un getent hosts t’épargne une heure de fausse piste. Et un DNS, ça se tient propre — les vieilles entrées « par commodité » deviennent les chausse-trappes de demain.

Épilogue heureux : Vaultwarden n’était jamais tombé. Et ce gros nettoyage DNS a lancé un chantier plus ambitieux — faire de mon résolveur un citoyen de première classe de l’infra, sans pour autant le mettre dans le cluster. Mais ça, c’est l’autre billet. Le code est public.