Deze thread uit december 2025 combineerde verschillende Pi-hole-problemen: poort 67 was al in gebruik, bij updates van Gravity werd gemeld dat DNS-resolutie niet beschikbaar was, poort 80 conflicteerde met het ZimaOS-dashboard en een latere stroomstoring zorgde ervoor dat de eerder werkende configuratie opnieuw uitviel.
De thread bood geen eenvoudige oplossing in één stap. Sommige vroege aannames uit de community verklaarden de latere symptomen van de gebruiker niet. De nuttige les is daarom om DHCP, DNS, toewijzing van de webinterface, upstream-resolutie en persistente containerstatus afzonderlijk te bekijken in plaats van alles als één poortprobleem te behandelen.
Poort 67 gaat over DHCP, niet over normale DNS-filtering
De gebruiker ontdekte dat een dnsmasq-proces poort 67 al gebruikte en kon dit proces niet beëindigen. Antwoorden uit de community legden uit dat Pi-hole poort 67 alleen nodig heeft wanneer het als DHCP-server fungeert. De router van de gebruiker verzorgde DHCP al, dus Pi-hole hoefde die rol niet over te nemen.
Als Pi-hole alleen voor DNS-filtering wordt gebruikt, laat je DHCP op de router staan, tenzij je bewust een netwerkontwerp gebruikt waarvoor Pi-hole DHCP moet verzorgen.
DNS gebruikt poort 53
De DNS-service van Pi-hole gebruikt poort 53 via TCP en UDP. De configuratie uit de community in deze thread was gericht op het beschikbaar stellen van DNS op poort 53, terwijl DHCP uitgeschakeld bleef.
Gebruik de eigen documentatie van Pi-hole voor de actuele vereisten voor services en poorten, in plaats van ervan uit te gaan dat elke container-template voor ZimaOS uit 2025 nog identiek is.
actuele vereisten voor Pi-hole-services en -poorten
Poort 80 was een afzonderlijk conflict met het ZimaOS-dashboard
Toen de gebruiker Pi-hole opnieuw schoon probeerde te installeren, meldde ZimaOS dat poort 80 al in gebruik was. Zima-Jerry bevestigde dat de WebUI-poort van ZimaOS kan worden gewijzigd.
Een eenvoudiger alternatief aan de containerzijde dat in de thread werd besproken, was om het ZimaOS-dashboard op de bestaande poort te laten staan en een andere hostpoort aan de interne webpoort van Pi-hole te koppelen. Dit verandert alleen hoe de beheerpagina van Pi-hole wordt bereikt; het verandert niets aan DNS-verkeer op poort 53.
Een correcte poorttoewijzing loste Gravity niet automatisch op
Nadat de poorttoewijzingen waren opgeschoond, zag de oorspronkelijke gebruiker nog steeds de melding “DNS-resolutie is niet beschikbaar”. De thread verschoof vervolgens van poortconflicten naar de bereikbaarheid van upstream-DNS. Het belangrijke diagnostische onderscheid is:
- poorttoewijzing bepaalt of clients de Pi-hole-service kunnen bereiken;
- upstream-DNS bepaalt of Pi-hole zelf namen kan oplossen en de gegevens van Gravity kan vernieuwen.
De thread publiceerde geen door IceWhale bevestigde hoofdoorzaak voor elke DNS-storing. Beweer daarom niet dat alleen poort 67 een mislukte Gravity-update verklaart.
De configuratie viel na een stroomstoring opnieuw uit
De gebruiker meldde later dat Pi-hole vóór een stroomstoring correct had gewerkt, maar daarna opnieuw uitviel. Advies uit de community suggereerde dat persistente AppData een gewone verwijdering kan overleven en beschadigde status kan meenemen naar een nieuwe installatie.
Het verwijderen van een AppData-map is destructief, omdat hiermee persistente applicatiestatus wordt verwijderd. De aanbeveling uit de bron was bedoeld voor probleemoplossing door de community en was geen officiële herstelprocedure van IceWhale. Maak een back-up van de configuratie en controleer het exacte applicatiepad voordat je persistente gegevens verwijdert.
Controleer de gezondheid van ZimaOS voordat je Pi-hole opnieuw opbouwt
Dezelfde stroomstoring had ook gevolgen voor het opstartgedrag van de machine. Toen het besturingssysteem zelf instabiel werd, maakte de thread terecht onderscheid tussen dat probleem en het probleem met de Pi-hole-container. Je kunt niet verwachten dat een container normaal werkt wanneer de host niet goed opstart of Docker-services niet gezond zijn.
Veelgestelde vragen over Pi-hole op ZimaOS
Heeft Pi-hole poort 67 nodig als mijn router al DHCP verzorgt?
Nee, niet voor de configuratie met alleen DNS-filtering die in deze thread werd besproken. Poort 67 is relevant voor DHCP-services, terwijl DNS-filtering poort 53 gebruikt.
Wat als ZimaOS poort 80 al gebruikt?
Zima-Jerry bevestigde dat de WebUI-poort van ZimaOS kan worden gewijzigd. Een andere aanpak is om de interne webpoort van Pi-hole aan een andere hostpoort te koppelen.
Kunnen blokkeerlijsten de melding “DNS-resolutie is niet beschikbaar” veroorzaken?
De probleemoplossing in de thread richtte zich op het vermogen van Pi-hole om een upstream-resolver te bereiken, niet op de inhoud van de blokkeerlijsten.
Gaat het verwijderen van Pi-hole gegarandeerd gepaard met een schone herinstallatie?
Nee, niet als persistente AppData blijft staan. De thread onderzocht later verouderde of beschadigde persistente status na een harde stroomuitval, maar het verwijderen van die status moet als een destructieve herstelstap worden beschouwd.
