On l’oublie parfois, mais même si ton serveur est bétonné niveau SSH, HTTP, firewall, fail2ban et compagnie, il continue souvent à utiliser les DNS du fournisseur… sans aucune forme de chiffrement. Résultat : toutes les requêtes DNS partent en clair, visibles par ton hébergeur, voire interceptables si quelqu’un s’amuse sur le réseau.
Et ça, franchement, en 2025, ça pique un peu.
Heureusement, il existe une solution propre, légère et efficace : Unbound, configuré en résolveur local qui utilise le DNS-over-TLS (DoT) pour aller interroger les serveurs DNS upstream. Ton système garde ses habitudes (127.0.0.1 en DNS), mais les requêtes, elles, partent chiffrées.
Allez, on met ça en place ensemble.
Pourquoi ne pas utiliser directement 1.1.1.1 ou 9.9.9.9 ?
Tu pourrais te contenter de mettre 1.1.1.1 dans /etc/resolv.conf et basta. Sauf que :
- Ce n’est pas chiffré
- Ce n’est pas en cache (chaque requête repart vers Internet)
- Tu exposes toutes tes requêtes à un tiers (Cloudflare ou autre)
Avec unbound, tu gardes un cache local, tu peux forcer les certificats, et interroger plusieurs fournisseurs DNS sans modifier ton système toutes les 5 minutes.
Étape 1 – Installer Unbound
Sur Debian, Ubuntu, etc. :
sudo apt update
sudo apt install unboundSur CentOS / Rocky / Fedora :
sudo dnf install unboundTu peux vérifier que le service tourne :
sudo systemctl status unboundÉtape 2 – Config de base
On va écraser la config par défaut pour faire quelque chose de propre.
📁 Éditer /etc/unbound/unbound.conf.d/resolver.conf
sudo nano /etc/unbound/unbound.conf.d/resolver.confVoici un exemple de configuration complète et commentée :
server:
verbosity: 1
interface: 127.0.0.1
port: 53
do-ip4: yes
do-ip6: no
do-tcp: yes
do-udp: yes
access-control: 127.0.0.0/8 allow
hide-identity: yes
hide-version: yes
harden-glue: yes
harden-dnssec-stripped: yes
cache-min-ttl: 3600
cache-max-ttl: 86400
prefetch: yes
qname-minimisation: yes
use-caps-for-id: no
forward-zone:
name: "."
forward-tls-upstream: yes
forward-addr: 1.1.1.1@853 # Cloudflare
forward-addr: 9.9.9.9@853 # Quad9
forward-addr: 94.140.14.14@853 # AdGuard DNS
forward-addr: 2620:fe::fe@853 # Quad9 (IPv6 si activé)
🔒
forward-tls-upstream: yesest LA ligne clé : c’est elle qui active DNS-over-TLS
Tu peux aussi ajouter :
tls-cert-bundle: /etc/ssl/certs/ca-certificates.crt…pour t’assurer que les certificats racine sont bien vérifiés.
Étape 3 – Redémarrer et tester
sudo systemctl restart unboundPuis vérifie qu’il écoute bien en local :
dig @127.0.0.1 www.google.comSi tu vois une réponse rapide et sans erreur, c’est bon.
Étape 4 – Forcer ton système à utiliser Unbound
Édite /etc/resolv.conf (ou via systemd-resolved selon ta distro) :
nameserver 127.0.0.1⚠️ Attention : certaines distros régénèrent ce fichier à chaque reboot. Pour éviter ça :
- Utilise
chattr +i /etc/resolv.conf(efficace mais un peu bourrin) - Ou configure NetworkManager / systemd-resolved proprement
Tu peux aussi désactiver complètement systemd-resolved si tu veux garder la main.
Étape 5 – Vérifier que le DNS est bien chiffré
Tu peux activer les logs DNS-over-TLS temporairement pour voir si tout passe bien :
sudo unbound -d -vvOu utiliser tcpdump pour surveiller les flux sortants vers le port 853 :
sudo tcpdump -i eth0 port 853Si tu vois passer des connexions vers 1.1.1.1:853 ou 9.9.9.9:853, c’est bon signe.
Bonus : config parano
Tu peux aller plus loin et filtrer certains domaines (style trackers ou pub) en ajoutant :
local-zone: "doubleclick.net" static
local-zone: "facebook.com" refuseTu peux aussi charger une liste de blocage avec un script automatique (similaire à Pi-hole), ou coupler ça avec dnscrypt-proxy si tu veux gérer DoH + DoT + anonymisation.
Est-ce que ça marche bien sur un VPS ou un dédié ?
Absolument. Unbound est ultra léger. Tu peux le faire tourner sans problème sur un petit VPS 1 vCPU / 512 Mo comme chez Hetzner, D4.FR, OVHcloud ou Scaleway.
Et si tu veux l’intégrer dans un container Docker, c’est aussi très facile (je peux te filer un Dockerfile si tu veux).
