Community-Lösung

Pi-hole auf ZimaOS: Port 67, DNS-Fehler, Konflikte bei Web-Ports und Einschränkungen bei der sauberen Neuinstallation

A Pi-hole troubleshooting thread covering a system-owned port 67, DNS resolution failures during Gravity updates, a port 80 conflict with the ZimaOS dashboard, and persistent Pi-hole state after an unexpected power outage.

Dieser Thread vom Dezember 2025 behandelte mehrere unterschiedliche Pi-hole-Probleme: Port 67 war bereits belegt, Gravity-Updates meldeten, dass die DNS-Auflösung nicht verfügbar war, Port 80 kollidierte mit dem ZimaOS-Dashboard, und ein späterer Stromausfall führte dazu, dass die zuvor funktionierende Einrichtung erneut ausfiel.

Der Thread bot keine saubere Ein-Schritt-Lösung. Einige frühe Annahmen der Community erklärten die späteren Symptome des Benutzers nicht. Die wichtigste Erkenntnis ist daher, DHCP, DNS, Weboberflächen-Zuordnung, Upstream-Auflösung und den persistenten Containerstatus getrennt zu betrachten, statt all dies als ein einziges Portproblem zu behandeln.

Port 67 betrifft DHCP, nicht die normale DNS-Filterung

Der ursprüngliche Benutzer stellte fest, dass ein dnsmasq-Prozess bereits an Port 67 gebunden war und nicht beendet werden konnte. Antworten aus der Community erklärten, dass Pi-hole Port 67 nur benötigt, wenn es als DHCP-Server fungiert. Der Router des Benutzers stellte bereits DHCP bereit, daher musste Pi-hole diese Rolle nicht übernehmen.

Wenn Pi-hole nur zur DNS-Filterung verwendet wird, sollte DHCP auf dem Router aktiviert bleiben, sofern kein bewusst geplantes Netzwerkdesign Pi-hole als DHCP-Server erfordert.

DNS verwendet Port 53

Der DNS-Dienst von Pi-hole verwendet Port 53 über TCP und UDP. Die Community-Konfiguration in diesem Thread konzentrierte sich darauf, DNS über Port 53 bereitzustellen und DHCP deaktiviert zu lassen.

Für aktuelle Anforderungen an Dienste und Ports sollte die offizielle Dokumentation von Pi-hole herangezogen werden, statt davon auszugehen, dass jedes ZimaOS-Container-Template aus dem Jahr 2025 noch identisch ist.

aktuelle Anforderungen an Pi-hole-Dienste und -Ports

Port 80 war ein separates Konfliktproblem mit dem ZimaOS-Dashboard

Als der Benutzer eine saubere Pi-hole-Installation versuchte, meldete ZimaOS, dass Port 80 bereits verwendet wurde. Zima-Jerry bestätigte, dass der WebUI-Port von ZimaOS geändert werden kann.

Benutzerdefinierte Pi-hole-App-Einstellungen in ZimaOS: Port 53 wird akzeptiert, während Host-Port 80 als nicht verfügbar markiert ist
Der Screenshot aus der Quelle zeigt, dass DNS-Port 53 akzeptiert wird, während Host-Port 80 mit einem anderen Dienst auf dem ZimaOS-Host kollidiert.

Eine im Thread besprochene einfachere Alternative auf Containerseite bestand darin, das ZimaOS-Dashboard an seinem bestehenden Port zu belassen und stattdessen einen anderen Host-Port auf den internen Web-Port von Pi-hole abzubilden. Dadurch ändert sich nur, wie die Pi-hole-Administrationsseite aufgerufen wird; der DNS-Datenverkehr über Port 53 bleibt unverändert.

Pi-hole-Portzuordnungen in ZimaOS mit TCP und UDP 53 sowie Host-Port 8081, der auf Container-Port 80 abgebildet wird
Ein späterer Screenshot zeigt die von der Community verwendete Konfiguration mit TCP/UDP 53 für DNS und Host-Port 8081 für Pi-holes Container-Web-Port 80.

Eine korrekte Portzuordnung behob den Gravity-Fehler nicht automatisch

Auch nach der Bereinigung der Portzuordnungen sah der ursprüngliche Benutzer weiterhin die Meldung „DNS resolution is unavailable“. Danach verlagerte sich die Fehlersuche von Portkonflikten auf die Erreichbarkeit des Upstream-DNS. Die wichtige diagnostische Unterscheidung lautet:

  • Die Portzuordnung steuert, ob Clients den Pi-hole-Dienst erreichen können;
  • Der Upstream-DNS steuert, ob Pi-hole selbst Namen auflösen und Gravity-Daten aktualisieren kann.

Der Thread nannte keine von IceWhale bestätigte Ursache für jeden einzelnen DNS-Fehler. Behaupten Sie daher nicht, dass allein Port 67 ein fehlgeschlagenes Gravity-Update erklärt.

Nach einem Stromausfall fiel die Einrichtung erneut aus

Der Benutzer berichtete später, dass Pi-hole vor dem Stromausfall ordnungsgemäß funktioniert hatte, danach jedoch erneut ausfiel. Als Ursache wurde in der Community vermutet, dass persistente AppData einen normalen Deinstallationsvorgang überstehen und fehlerhafte Zustände in eine Neuinstallation übernehmen können.

Das Löschen eines AppData-Verzeichnisses ist destruktiv, da dadurch der persistente Anwendungsstatus entfernt wird. Die Empfehlung aus der Quelle war eine Fehlersuche durch die Community und kein offizielles Wiederherstellungsverfahren von IceWhale. Sichern Sie die Konfiguration und überprüfen Sie den genauen Anwendungspfad, bevor Sie persistente Daten entfernen.

Überprüfen Sie den Zustand von ZimaOS, bevor Sie Pi-hole neu aufsetzen

Der gleiche Stromausfall beeinträchtigte auch das Startverhalten des Systems. Sobald das Betriebssystem selbst instabil wurde, trennte der Thread dies zu Recht vom Problem mit dem Pi-hole-Container. Von einem Container kann kein normales Verhalten erwartet werden, wenn der Host nicht ordnungsgemäß startet oder die Docker-Dienste nicht fehlerfrei laufen.

FAQ zu Pi-hole auf ZimaOS

Benötigt Pi-hole Port 67, wenn mein Router bereits DHCP bereitstellt?

Nein, nicht für die in diesem Thread besprochene Einrichtung, die nur DNS filtert. Port 67 ist für den DHCP-Dienst relevant, während die DNS-Filterung Port 53 verwendet.

Was ist, wenn ZimaOS bereits Port 80 verwendet?

Zima-Jerry bestätigte, dass der ZimaOS-WebUI-Port geändert werden kann. Eine weitere Möglichkeit besteht darin, Pi-holes internen Web-Port auf einen anderen Host-Port abzubilden.

Können Blocklisten die Meldung „DNS resolution is unavailable“ verursachen?

Bei der Fehlersuche im Thread ging es darum, ob Pi-hole einen Upstream-Resolver erreichen kann, nicht um den Inhalt der Blocklisten.

Garantiert die Deinstallation von Pi-hole eine saubere Neuinstallation?

Nein, nicht wenn persistente AppData erhalten bleiben. Im weiteren Verlauf des Threads wurden nach einem harten Stromausfall veraltete oder beschädigte persistente Zustände untersucht. Das Löschen dieses Zustands sollte jedoch als destruktiver Wiederherstellungsschritt betrachtet werden.