Ce fil de discussion de décembre 2025 regroupait plusieurs problèmes distincts liés à Pi-hole : le port 67 était déjà utilisé, les mises à jour de Gravity signalaient que la résolution DNS était indisponible, le port 80 entrait en conflit avec le tableau de bord de ZimaOS, puis une panne de courant a fait échouer à nouveau une configuration qui fonctionnait auparavant.
Le fil ne proposait pas de solution simple en une seule étape. Certaines hypothèses initiales de la communauté n’expliquaient pas les symptômes apparus plus tard. La leçon utile consiste donc à distinguer le DHCP, le DNS, la redirection de l’interface web, la résolution en amont et l’état persistant du conteneur, plutôt que de traiter tout cela comme un unique problème de port.
Le port 67 concerne le DHCP, pas le filtrage DNS habituel
L’utilisateur à l’origine du sujet a constaté qu’un processus dnsmasq était déjà lié au port 67 et ne pouvait pas l’arrêter. Les réponses de la communauté ont expliqué que Pi-hole n’a besoin du port 67 que lorsqu’il agit comme serveur DHCP. Le routeur de l’utilisateur fournissait déjà le DHCP ; Pi-hole n’avait donc pas besoin d’assumer ce rôle.
Si Pi-hole sert uniquement au filtrage DNS, laissez le DHCP sur le routeur, sauf si votre conception réseau nécessite délibérément que Pi-hole fournisse le DHCP.
Le DNS utilise le port 53
Le service DNS de Pi-hole utilise le port 53 en TCP et en UDP. La configuration communautaire présentée dans ce fil visait à exposer le DNS sur le port 53 tout en laissant le DHCP désactivé.
Consultez la documentation officielle de Pi-hole pour connaître les exigences actuelles en matière de services et de ports, plutôt que de supposer que tous les modèles de conteneurs ZimaOS de 2025 sont encore identiques.
exigences actuelles de Pi-hole en matière de services et de ports
Le port 80 était un conflit distinct avec le tableau de bord de ZimaOS
Lorsque l’utilisateur a tenté une installation propre de Pi-hole, ZimaOS a signalé que le port 80 était déjà utilisé. Zima-Jerry a confirmé que le port de l’interface web de ZimaOS pouvait être modifié.
Une autre solution plus simple, évoquée dans le fil au niveau du conteneur, consistait à laisser le tableau de bord de ZimaOS sur son port actuel et à mapper un autre port hôte vers le port web interne de Pi-hole. Cela modifie uniquement la manière d’accéder à la page d’administration de Pi-hole ; le trafic DNS sur le port 53 n’est pas modifié.
Un mappage de ports correct ne corrigeait pas automatiquement Gravity
Après avoir nettoyé les mappages de ports, l’utilisateur d’origine voyait toujours le message « La résolution DNS est indisponible ». Le fil est alors passé des conflits de ports à l’accessibilité du DNS en amont. La distinction diagnostique importante est la suivante :
- le mappage des ports détermine si les clients peuvent accéder au service Pi-hole ;
- le DNS en amont détermine si Pi-hole peut lui-même résoudre les noms et actualiser les données de Gravity.
Le fil n’a pas établi de cause racine confirmée par IceWhale pour chaque panne DNS. Évitez donc d’affirmer que le port 67 explique à lui seul l’échec d’une mise à jour de Gravity.
La configuration est de nouveau tombée en panne après une coupure de courant
L’utilisateur a ensuite indiqué que Pi-hole fonctionnait correctement avant une coupure de courant, puis qu’il était de nouveau tombé en panne après celle-ci. La communauté a suggéré que les données persistantes de l’application pouvaient survivre à une désinstallation ordinaire et reporter un état défectueux lors d’une réinstallation.
La suppression d’un répertoire AppData est une opération destructive, car elle supprime l’état persistant de l’application. La recommandation d’origine relevait du dépannage communautaire et non d’une procédure officielle de récupération d’IceWhale. Sauvegardez la configuration et vérifiez le chemin exact de l’application avant de supprimer des données persistantes.
Vérifiez l’état de santé de ZimaOS avant de reconstruire Pi-hole
La même coupure de courant a également affecté le démarrage de la machine. Une fois le système d’exploitation lui-même devenu instable, le fil a correctement distingué ce problème de celui du conteneur Pi-hole. On ne peut pas attendre d’un conteneur qu’il fonctionne normalement lorsque l’hôte ne démarre plus correctement ou que les services Docker ne sont pas opérationnels.
FAQ sur Pi-hole sur ZimaOS
Pi-hole a-t-il besoin du port 67 si mon routeur fournit déjà le DHCP ?
Non, pour la configuration de filtrage DNS uniquement décrite dans ce fil. Le port 67 concerne le service DHCP, tandis que le filtrage DNS utilise le port 53.
Que faire si ZimaOS utilise déjà le port 80 ?
Zima-Jerry a confirmé que le port de l’interface web de ZimaOS pouvait être modifié. Une autre approche consiste à mapper le port web interne de Pi-hole vers un autre port hôte.
Les listes de blocage peuvent-elles provoquer le message « La résolution DNS est indisponible » ?
Le dépannage présenté dans le fil portait sur la capacité de Pi-hole à joindre un résolveur en amont, et non sur le contenu des listes de blocage.
La désinstallation de Pi-hole garantit-elle une réinstallation propre ?
Non, si les données persistantes AppData sont conservées. Le fil a ensuite examiné la présence éventuelle d’un état persistant obsolète ou endommagé après une coupure brutale, mais la suppression de cet état doit être considérée comme une étape de récupération destructive.
