Pourquoi héberger son propre résolveur DNS Pi-hole sur VPS
Un résolveur DNS self-hosted sur VPS n'est pas réservé aux homelabs. Dès que vous opérez plusieurs conteneurs et services sur le même serveur, il devient un point de contrôle réseau central : chaque requête DNS transite par Pi-hole avant d'atteindre l'internet, ce qui vous donne une visibilité et un contrôle que vous n'avez pas avec les résolveurs publics.
Le VPS tourne 24 h/24, est accessible depuis n'importe quel nœud de votre réseau Docker ou de votre mesh VPN, et ne dépend pas de la disponibilité de votre réseau domestique. Pour un développeur qui administre plusieurs serveurs ou qui travaille en nomade, c'est l'emplacement qui fait sens.
Ce que Pi-hole apporte concrètement sur une stack self-hosted
- Bloquage réseau universel : toute requête vers des domaines de publicité, de tracking ou de malware est bloquée avant même que la connexion TCP ne s'établisse — pour tous les conteneurs du réseau Docker, sans modifier chaque application.
- Logs DNS centralisés : un tableau de bord unique affiche l'intégralité des requêtes DNS de votre infrastructure, ce qui facilite le débogage d'une application qui contacte un service externe inattendu.
- Réduction de la bande passante : les requêtes bloquées ne génèrent aucune réponse réseau. Sur un VPS avec quota de bande passante, c'est une économie mesurable pour les stacks chargées.
- Vie privée des requêtes DNS : en couplant Pi-hole à Unbound comme résolveur récursif local, vos requêtes ne transitent plus par un résolveur tiers — elles interrogent directement les serveurs DNS autoritaires.
- Intégration stack self-hosted : Pi-hole agit comme serveur DNS local pour vos services, ce qui vous permet de créer des entrées DNS personnalisées (
grafana.monserveur.local) sans modifier chaque fichier/etc/hosts. - Listes de blocage communautaires : l'écosystème Pi-hole est l'un des plus fournis en listes de blocage maintenues — Hagezi, oisd, Steven Black — actualisées automatiquement.
- Mise à jour v6 non bloquante : Pi-hole v6 maintient la compatibilité avec les clients v5 ; la migration ne coupe pas le service.
Nouveautés Pi-hole v6 — ce qui change pour les self-hosters
Pi-hole v6 a été annoncé le 18 février 2025 sur pi-hole.net. C'est une réécriture majeure, pas une mise à jour incrémentale.
Suppression de PHP et lighttpd. La version 5 reposait sur lighttpd comme serveur web et PHP pour l'interface d'administration. En v6, le binaire pihole-FTL intègre directement un serveur web basé sur Lua. Résultat : l'image Docker est plus légère, il n'y a plus de dépendance à gérer séparément, et la surface d'attaque est réduite.
Nouvelle API REST native. L'API v6 est documentée et versionnée. Elle expose les statistiques, la gestion des listes et la configuration directement depuis http://<ip>/api/. Dans une stack Docker Compose, cela permet d'automatiser la gestion de Pi-hole depuis un script ou depuis n8n sans passer par des workarounds.
Variables d'environnement FTLCONF_*. Le schéma de configuration a changé. La variable WEBPASSWORD de la v5 est remplacée par FTLCONF_webserver_api_password. Toutes les options de configuration FTL sont désormais exposées via des variables FTLCONF_<section>_<clé>, ce qui rend le docker-compose.yml autoportant et lisible.
Mode Basic / Expert. L'interface v6 distingue les réglages essentiels (mode Basic) des options avancées (mode Expert). Pour un déploiement VPS, le mode Expert donne accès au contrôle de l'interface d'écoute DNS et aux paramètres de sécurité.
Antigravity (listes d'autorisation par abonnement). En miroir de Gravity, Antigravity permet de s'abonner à des listes d'autorisation maintenues par la communauté — utile pour éviter les faux positifs sur des domaines légitimes.
Depuis le lancement de v6 en février 2025, plusieurs mises à jour ont suivi : FTL v6.5 et Web v6.5 en février 2026 (correctifs de stabilité et d'interface), FTL v6.6 en avril 2026, FTL v6.6.1 en avril 2026 avec des correctifs de sécurité. L'image Docker officielle est tagguée 2026.06.0 pour la release de juin 2026, qui inclut les correctifs de sécurité de l'année.
Prérequis VPS avant de commencer
Pi-hole v6 est conçu pour être léger — les exigences sont nettement inférieures à celles d'un SIEM ou d'une stack de monitoring.
Ressources minimales recommandées :
- 512 Mo de RAM suffisent pour un usage modéré (quelques conteneurs, moins de 10 000 requêtes/heure). Prévoyez 1 Go pour un usage intensif ou si vous activez l'historique étendu des requêtes.
- 1 vCPU suffit. Pi-hole FTL est un processus unique et efficace.
- 4 Go de disque minimum pour l'image et les bases de données de requêtes (la base SQLite croît avec le volume de requêtes).
- Accès root au VPS pour gérer Docker et la configuration réseau.
Ports réseau à considérer :
- 53/UDP et 53/TCP : port DNS. Ne pas exposer publiquement — c'est la règle la plus importante de ce guide (voir la section sécurisation).
- 80/TCP et 443/TCP : interface d'administration web, à exposer uniquement derrière un reverse proxy avec authentification.
Prérequis logiciels :
- Docker Engine 24.0+ et Docker Compose v2 (docker compose, sans tiret).
- Système d'exploitation : Debian 12 ou Ubuntu 22.04/24.04 LTS.
Vérification préalable — port 53 :
Sur Debian/Ubuntu récents, systemd-resolved écoute sur le port 53. C'est la cause numéro un d'échec au premier démarrage de Pi-hole. Vérifiez et désactivez si nécessaire :
ss -tlunp | grep ':53'
systemctl disable --now systemd-resolvedSi vous désactivez systemd-resolved, assurez-vous que /etc/resolv.conf pointe vers un résolveur fonctionnel le temps du déploiement :
echo 'nameserver 1.1.1.1' > /etc/resolv.confDéploiement Pi-hole v6 avec Docker Compose : procédure complète
Préparer le serveur et installer Docker
Mettez à jour le système et installez Docker Engine depuis le dépôt officiel :
apt-get update && apt-get upgrade -y curl -fsSL https://get.docker.com | sh docker --version && docker compose versionActivez Docker au démarrage et vérifiez que Docker Compose v2 répond (la commande est
docker compose, sans tiret) :systemctl enable --now dockerCréer la structure de répertoires
Créez un répertoire dédié et les volumes persistants pour la configuration et les bases de données Pi-hole :
mkdir -p /opt/pihole/etc-pihole cd /opt/piholeCes répertoires persistent la configuration FTL, les listes Gravity et le journal des requêtes. Sans eux, chaque recréation du conteneur repart de zéro.
Rédiger le docker-compose.yml Pi-hole v6
Créez
/opt/pihole/docker-compose.ymlavec la configuration suivante. Notez l'utilisation deFTLCONF_webserver_api_password(variable v6) etFTLCONF_dns_listeningModepour s'adapter au réseau Docker bridge :services: pihole: container_name: pihole image: pihole/pihole:2026.06.0 ports: - "127.0.0.1:53:53/tcp" - "127.0.0.1:53:53/udp" - "127.0.0.1:8080:80/tcp" environment: TZ: 'Europe/Paris' FTLCONF_webserver_api_password: 'changez-ce-mot-de-passe' FTLCONF_dns_listeningMode: 'ALL' FTLCONF_dns_upstreams: '1.1.1.1;8.8.8.8' volumes: - './etc-pihole:/etc/pihole' cap_add: - SYS_NICE restart: unless-stoppedPoint critique :
127.0.0.1:53lie le port DNS à l'interface loopback de l'hôte uniquement. Le résolveur est accessible depuis le serveur lui-même et depuis le réseau Docker interne, mais pas depuis Internet.Démarrer Pi-hole et vérifier l'état
Lancez le conteneur en arrière-plan et vérifiez qu'il est
healthy:docker compose up -d docker compose ps docker compose logs pihole | tail -30Au premier démarrage, Pi-hole télécharge les listes Gravity (quelques secondes). L'interface web est disponible sur
http://127.0.0.1:8080/admindepuis le serveur lui-même. Si vous voyezPi-hole blocking is enabled, le déploiement est fonctionnel.Configurer le DNS sur le réseau Docker interne
Pour que vos conteneurs utilisent Pi-hole comme résolveur DNS, définissez
dnsdans chaque service de vos autres stacks Docker Compose, ou configurez le démon Docker globalement.Option A — par service (recommandé pour les stacks existantes) :
services: mon-app: image: mon-image dns: - 172.17.0.1172.17.0.1est l'IP de la passerelle du réseau Docker bridge par défaut, qui correspond à l'interface de l'hôte où Pi-hole écoute.Option B — démon Docker global (/etc/docker/daemon.json) :
{ "dns": ["172.17.0.1", "1.1.1.1"] }Redémarrez Docker après modification :
systemctl restart docker. Le second résolveur1.1.1.1est un repli si Pi-hole est arrêté.Exposer le dashboard via un reverse proxy HTTPS
N'exposez jamais le dashboard Pi-hole directement sur le port 80 public. Utilisez nginx comme reverse proxy, avec un certificat Let's Encrypt :
server { listen 443 ssl; server_name pihole.votre-domaine.com; ssl_certificate /etc/letsencrypt/live/pihole.votre-domaine.com/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/pihole.votre-domaine.com/privkey.pem; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; } }Obtenez le certificat avec Certbot :
certbot --nginx -d pihole.votre-domaine.com. L'authentification Pi-hole (mot de passe défini dansFTLCONF_webserver_api_password) reste la seule porte d'entrée.Sécuriser le résolveur contre l'exposition publique
Un résolveur DNS ouvert sur Internet est un vecteur d'amplification DDoS et peut être exploité par n'importe qui. Vérifiez que le port 53 n'est pas accessible depuis l'extérieur.
Vérification depuis un poste distant :
nmap -sU -p 53 <IP_DE_VOTRE_VPS>Le port doit être
filteredouclosed. S'il estopen, votre résolveur est public.Fermer le port 53 avec ufw :
ufw deny 53/udp ufw deny 53/tcp ufw allow from 172.16.0.0/12 to any port 53La règle
allow from 172.16.0.0/12autorise les réseaux Docker internes tout en bloquant le trafic externe. La configuration127.0.0.1:53:53du Step 3 est une protection complémentaire — Docker ne forwarde pas le port à l'extérieur si vous liez à127.0.0.1.Ajouter des listes de blocage et activer la mise à jour automatique
L'interface Pi-hole v6 > Lists permet d'ajouter des listes par URL. Listes recommandées à ajouter après l'installation :
- Hagezi Multi Pro :
https://raw.githubusercontent.com/hagezi/dns-blocklists/main/adblock/pro.txt
- oisd Big :https://big.oisd.nl/
- Steven Black Unified :https://raw.githubusercontent.com/StevenBlack/hosts/master/hostsAprès ajout, déclenchez une mise à jour de Gravity :
docker exec pihole pihole -gPour automatiser la mise à jour hebdomadaire, ajoutez une entrée cron sur l'hôte :
0 3 * * 0 docker exec pihole pihole -g >> /var/log/pihole-gravity.log 2>&1
Configuration post-installation
Une fois Pi-hole opérationnel et vos services pointant sur lui, quelques ajustements renforcent l'utilité au quotidien.
DNS personnalisés pour les services internes. Dans Pi-hole > Local DNS, vous pouvez créer des entrées A qui résolvent des noms locaux : grafana.local → 127.0.0.1, n8n.local → 127.0.0.1. Cela remplace les modifications de /etc/hosts sur chaque machine.
Ajuster le niveau de journalisation. Par défaut, Pi-hole conserve 24 heures de journal. Pour étendre à 7 jours ou réduire pour limiter l'usage disque : dans Settings > System, modifiez l'option Query log. Sur un VPS avec stockage limité, désactiver les logs détaillés (tout en gardant les statistiques) est une option viable.
Tableau de bord et statistiques. Le dashboard v6 affiche en temps réel : le pourcentage de requêtes bloquées, les domaines les plus demandés, les clients les plus actifs. Ces données sont utiles pour identifier un conteneur qui effectue des requêtes inhabituelles.
Whitelist des faux positifs. Pi-hole > Domains > Allow permet d'ajouter des exceptions sans toucher aux listes, si un service interne cesse de fonctionner après activation d'une nouvelle liste.
Pi-hole v6 vs AdGuard Home — comparatif 2026
Faites défiler le tableau
| Critère | Pi-hole v6 | AdGuard Home |
|---|---|---|
| Architecture | Binaire FTL avec serveur web Lua intégré — plus de PHP ni lighttpd depuis v6 (février 2025) | Binaire Go unique, multi-plateforme (Linux, Windows, macOS, OpenWrt, FreeBSD) |
| DNS chiffré (DoH/DoT/DoQ) | Non intégré — nécessite un conteneur sidecar Unbound ou cloudflared pour DoH/DoT | Intégré nativement — DoH, DoT et DoQ disponibles sans configuration additionnelle |
| Empreinte mémoire | ~70-150 Mo en fonctionnement normal, selon le volume de requêtes et l'historique activé | ~50-100 Mo ; légèrement plus léger sur des configurations simples sans historique étendu |
| Communauté et listes | Écosystème le plus fourni : des centaines de listes compatibles (format hosts et adblock), forums actifs, documentation étendue | Compatible avec les listes au format adblock (uBlock Origin) ; écosystème en croissance mais plus jeune |
| API et automatisation | API REST native documentée en v6 ; gestion complète par variables d'environnement `FTLCONF_*` | API REST disponible ; configuration par fichier YAML ou interface web |
| Règles par client | Filtrage par client (IP ou nom de réseau), sans règles par-périphérique granulaires natives | Règles par client et par groupe nativement, parental controls intégrés |
Durcissement : les règles à ne pas négliger
Ne jamais exposer le port 53 publiquement. C'est le risque principal d'un résolveur DNS sur VPS. Un port 53 ouvert permet à n'importe qui d'utiliser votre serveur comme résolveur — et potentiellement comme vecteur d'amplification DNS dans une attaque DDoS. Vérifiez régulièrement avec nmap -sU -p 53 <IP_VPS> depuis l'extérieur.
Changer le mot de passe par défaut. La variable FTLCONF_webserver_api_password dans le Compose doit contenir un mot de passe fort. Si vous l'omettez, Pi-hole génère un mot de passe aléatoire qu'il affiche dans les logs au premier démarrage — pratique pour un test, inacceptable en production.
Mettre à jour l'image régulièrement. Les releases Pi-hole v6 en 2026 ont inclus des correctifs de sécurité (vulnérabilité de privilege escalation locale en avril 2026, corrections de XSS en interface web). Ajoutez une vérification périodique :
docker compose pull && docker compose up -dPas de DHCP en production sur VPS. La fonctionnalité DHCP est conçue pour les réseaux locaux. L'activer par erreur (cap_add: NET_ADMIN) peut créer des conflits réseau avec l'infrastructure de l'hôte.
Dépannage : les erreurs courantes
Voici les problèmes les plus fréquents lors d'un déploiement Pi-hole v6 sur VPS, avec les causes exactes et les corrections.
1. Le port 53 est déjà utilisé — bind: address already in use
Cause : systemd-resolved écoute sur 127.0.0.53:53. Vérifiez avec ss -tlunp | grep ':53'. Solution : désactivez systemd-resolved (systemctl disable --now systemd-resolved) et remplacez /etc/resolv.conf par un fichier statique pointant vers 1.1.1.1 le temps du déploiement. Sous Ubuntu 22.04+, la procédure recommandée est de remplacer le symlink /etc/resolv.conf par un fichier statique.
2. Les requêtes DNS depuis les conteneurs ne passent pas par Pi-hole
Cause : les conteneurs utilisent le résolveur par défaut de Docker (127.0.0.11), pas Pi-hole. Vérifiez depuis un conteneur : docker exec <conteneur> cat /etc/resolv.conf. S'il affiche 127.0.0.11, l'option dns: n'est pas configurée dans votre Compose ou dans /etc/docker/daemon.json.
3. Le dashboard est inaccessible après démarrage
Cause fréquente : le port 8080 est lié à 127.0.0.1 (inaccessible depuis l'extérieur) mais le reverse proxy n'est pas encore configuré. Vérifiez localement : curl http://127.0.0.1:8080/admin/. Si ça répond, le problème est côté reverse proxy ou certificat TLS.
4. FTLCONF_webserver_api_password ignorée après recréation du conteneur
Cause : Pi-hole stocke sa configuration dans /etc/pihole/pihole.toml. Si ce fichier existe déjà dans le volume ./etc-pihole avec un ancien mot de passe, la variable d'environnement ne le remplace pas. Correctif : supprimer le fichier pihole.toml (perte de configuration) ou changer le mot de passe depuis l'interface web.
5. La mise à jour Gravity échoue — Could not access the internet
Cause : le conteneur Pi-hole ne peut pas résoudre les URL des listes, généralement parce que FTLCONF_dns_upstreams n'est pas configuré ou parce que le conteneur lui-même utilise Pi-hole comme résolveur (boucle). Vérifiez que FTLCONF_dns_upstreams pointe vers un résolveur externe (1.1.1.1;8.8.8.8) dans votre Compose.
Intégrer Pi-hole dans votre stack de sécurité
Pi-hole est une couche de filtrage DNS, pas un système de détection d'intrusion. Son périmètre est précis : il agit sur les requêtes de noms de domaine avant l'établissement de la connexion. Il est complémentaire à d'autres outils, pas substituable.
Associé à Wazuh ou CrowdSec, Pi-hole couvre le filtrage préventif tandis que les autres outils analysent le comportement réseau et système en temps réel. Un conteneur compromis qui contacte un domaine de command-and-control connu sera bloqué par Pi-hole — et l'absence de réponse DNS peut déclencher une alerte dans Wazuh si vous avez configuré la surveillance des logs Pi-hole.
Associé à NetBird ou WireGuard, Pi-hole peut devenir le résolveur DNS de l'ensemble de votre mesh VPN privé. Tout appareil connecté au VPN bénéficie alors du filtrage, y compris depuis un poste distant.
Pour héberger Pi-hole sur un VPS avec accès root complet et Docker préinstallé, consultez les offres VPS ServOrbit. Pi-hole v6 tourne confortablement à partir du plan d'entrée de gamme.
Articles connexes : mises à jour de sécurité automatiques sur VPS Debian/Ubuntu, VPN mesh sans port ouvert avec NetBird, Wazuh SIEM open source sur VPS.
