Unbound sous Linux, le DNS local répond-il ?

Unbound peut être actif dans systemctl et ne servir à aucune requête du poste. Sur une VM Debian ou Ubuntu, le symptôme est banal : le service tourne, mais les requêtes DNS restent lentes, ou une application ne résout plus rien.

Avant de modifier /etc/resolv.conf ou de bousculer systemd-resolved, faites d’abord un diagnostic local. Vérifiez la configuration et le port, puis interrogez Unbound directement. Le DNS du système reste en place pendant ces contrôles.

Lire la configuration avant de toucher au port 53

Sur Debian et Ubuntu, la configuration principale passe souvent par /etc/unbound/unbound.conf, avec des inclusions dans /etc/unbound/unbound.conf.d/. Ne partez pas du principe qu’Unbound écoute sur 127.0.0.1:53.

Le port 53 peut déjà être pris par systemd-resolved, dnsmasq ou BIND. Le risque est simple : en changeant le résolveur système trop tôt, vous pouvez couper la résolution DNS du poste alors qu’Unbound n’écoute pas au bon endroit.

sudo unbound-checkconf /etc/unbound/unbound.conf
sudo unbound-checkconf -o interface /etc/unbound/unbound.conf
sudo unbound-checkconf -o port /etc/unbound/unbound.conf
sudo ss -lntup 'sport = :53'

unbound-checkconf lit la configuration et renvoie une erreur si une directive bloque le chargement. D’après la page de manuel officielle, un code retour 0 valide le fichier. Les options -o interface et -o port affichent les valeurs effectives.

ss montre le processus qui écoute réellement. Si vous voyez 127.0.0.53:53 côté systemd-resolved alors qu’Unbound doit répondre sur 127.0.0.1:53, vous avez un conflit concret à traiter.

Avant une modification, gardez une copie lisible du fichier principal :

sudo cp -a /etc/unbound/unbound.conf /etc/unbound/unbound.conf.before-local-test

Interroger Unbound sans changer le DNS du poste

Un service actif ne suffit pas. Unbound peut écouter sur une autre interface, utiliser un autre port, ou répondre en échec parce que les serveurs amont ou DNSSEC posent problème.

L’état du service et les journaux du démarrage en cours donnent le premier tri. Envoyez ensuite une requête au résolveur local, sans passer par la configuration DNS du système :

sudo systemctl status unbound --no-pager
sudo journalctl -u unbound -b -n 50 --no-pager
dig @127.0.0.1 example.net A +noall +comments +answer
dig @127.0.0.1 example.net A +noall +stats

Adaptez 127.0.0.1 et ajoutez -p 5335 si votre configuration affiche un autre port. Une réponse avec status: NOERROR et une section ANSWER prouve qu’Unbound a répondu pour ce nom.

connection refused renvoie au service ou au port. SERVFAIL indique que le démon a reçu la requête, mais qu’il n’a pas pu résoudre le nom. Les journaux aident alors à séparer panne réseau, validation DNSSEC et configuration des serveurs amont.

Relancez ensuite la même requête. Un temps plus court au second passage peut venir du cache d’Unbound. Ce test ne mesure pas la performance du résolveur ; il confirme seulement que vous parlez à la bonne instance.

Raccorder le résolveur système seulement après le test direct

Si dig @127.0.0.1 répond mais que les applications échouent encore, Unbound n’est probablement pas dans la chaîne utilisée par le système. Lisez cette chaîne avant de modifier le réseau.

• resolvectl status affiche les DNS connus par systemd-resolved.
• resolvectl query example.net teste la résolution depuis le résolveur système.
• cat /etc/resolv.conf montre le fichier présenté aux applications classiques.

Sur un serveur, je garderais Unbound sur une adresse et un port documentés, puis je raccorderais le résolveur système une fois les tests directs validés. Sur un poste de travail, systemd-resolved peut rester devant Unbound si cette couche simplifie le Wi-Fi, le VPN ou les profils réseau.

Un test local ne dit rien sur la résolution publique du domaine. Avant de mettre une application derrière un reverse proxy Caddy avec HTTPS, vérifiez aussi la réponse vue depuis Internet.

La documentation unbound-checkconf couvre les contrôles de configuration. Le guide officiel du résolveur local détaille l’intégration avec le système. Gardez la sauvegarde tant que le test direct et le test système ne donnent pas le même résultat.