[Pi-Hole] Ervaringen & discussie

[DjoeC]

mcmd schreef op woensdag 18 februari 2026 @ 10:01:
[...]

Natuurlijk niet wenselijk,maar desondanks wil je een security fix natuurlijk wel meteen doorvoeren om het geheel security robuust te houden.

Natuurlijk. Maar gezien mijn omgeving mag dit meelopen in de reguliere container update cyclus. Watchtower zal het nieuwe image dit weekend wel binnenhalen.... Ik doe voor containers nooit geautomatiseerde updates want als de boel gaat hangen wil ik weten wat de oorzaak is

[Freee!!]

DjoeC schreef op woensdag 18 februari 2026 @ 12:35:
[...]
Natuurlijk. Maar gezien mijn omgeving mag dit meelopen in de reguliere container update cyclus. Watchtower zal het nieuwe image dit weekend wel binnenhalen.... Ik doe voor containers nooit geautomatiseerde updates want als de boel gaat hangen wil ik weten wat de oorzaak is

Voor mijn Pi-Hole containers doe ik wel geautomatiseerde updates, maar maar voor twee van de vier.

[DjoeC]

Freee!! schreef op woensdag 18 februari 2026 @ 14:53:
[...]

Voor mijn Pi-Hole containers doe ik wel geautomatiseerde updates, maar maar voor twee van de vier.

Ja, ik weet dat je met labels eea kunt sturen maar ik houd t graag in eigen hand. Ben al eerder eens (na handmatige update) de bietenbrug op gegaan en omdat sommige zaken hier afhankelijk zijn van het werkelijk goed werken van containers gebeurt er qua updates zo weinig mogelijk automagisch. Best lullig als je partner 's ochtend vroeg beneden komt terwijl ik me nog eens omdraai en dan hoor: Waarom doet t internet t niet???? Dat HOEFT natuurlijk niet aan iets in mijn invloedsfeer te liggen, maar toch ben ik by default wel de gebeten hond. Nee dank u

[Freee!!]

DjoeC schreef op woensdag 18 februari 2026 @ 15:24:
[...]
Ja, ik weet dat je met labels eea kunt sturen maar ik houd t graag in eigen hand. Ben al eerder eens (na handmatige update) de bietenbrug op gegaan en omdat sommige zaken hier afhankelijk zijn van het werkelijk goed werken van containers gebeurt er qua updates zo weinig mogelijk automagisch. Best lullig als je partner 's ochtend vroeg beneden komt terwijl ik me nog eens omdraai en dan hoor: Waarom doet t internet t niet???? Dat HOEFT natuurlijk niet aan iets in mijn invloedsfeer te liggen, maar toch ben ik by default wel de gebeten hond. Nee dank u

Niet eens met labels, vastgezette versies, die ik handmatig bijwerk als het een tijdje goed gaat.

[sweetdude]

n.a.v. dit artikel op de frontpage:
review: Providers als poortwachter tegen online fraude: Anti Phishing Shield uitgelegd

Is er al ergens bekend welke lijst gehanteerd wordt? Mogelijk handig als deze al niet in de andere bekende lijsten zit om toe te voegen.

[DjoeC]

sweetdude schreef op dinsdag 31 maart 2026 @ 15:48:
n.a.v. dit artikel op de frontpage:
review: Providers als poortwachter tegen online fraude: Anti Phishing Shield uitgelegd

Is er al ergens bekend welke lijst gehanteerd wordt? Mogelijk handig als deze al niet in de andere bekende lijsten zit om toe te voegen.

Het "nadeel" van een lijst die elke 15 minuten wordt bijgewerkt is voor Pi-Hole dat die zich normaliter maar 1x per week bijwerkt. Daarnaast kan ik me voorstellen dat zowel het NCSC als de providers niet zitten te wachten op (tien)duizenden downloads per 15 minuten...... Ik denk trouwens dat hetzelfde geldt voor Github cs omdat je bij Pi-Hole niet 1 individuele lijst kunt bijwerken.

[ Voor 3% gewijzigd door DjoeC op 31-03-2026 17:22 ]

[Webgnome]

Github zal er niet om malen dat er zoveel mensen dingen downloaden. Enig idee hoeveel gebruik er van Github word gemaakt door geautomatiseerde systemen etc. Ik kan mij herinneren dat het NCSC een tijd terug een flubot repo had ingesteld. Die heb ik tijden lang gebruikt als pihole list en dat werkte goed. Nooit problemen mee gehad.

[Toet3r]

Er is weer een update verschenen
met oa enkele security fixes.
Changelog: https://pi-hole.net/blog/...and-core-v6-4-1-released/

[ Voor 10% gewijzigd door Toet3r op 03-04-2026 20:03 ]

[ID-College]

Kan iemand mij een klein beetje in de goede richting duwern voor een goede tutorial om Pi-Hole in meerdere VLAN's te draaien? Ik heb een Unifi dream router met 4 VLAN's (Main/IoT/IPTV/Guest) en de Pi-Hole draaien in main. De DNS van main gaat naar de Pi-Hole maar de overige 3 VLAN's kunnen er niet bij uiteraard momenteel. Wat is de beste setup:
1. firewall rules instellen voor access bij overige VLANS naar Pi-Hole en deze in Main laten draaien; of
2. per VLAN een eigen listener?

Optie 2 klinkt als de beste oplossing als ik zo lees maar krijg het niet 1,2,3 voor elkaar om eerlijk te zijn. Is optie 1 een slechte optie of heeft iemand een goede turorial ergens voor optie 2 die zich makkelijk laat volgen? Het liefste wil ik de clients zien in pi-hole maar niet per se een must. Ik begrijp dat dit alleen met optie 2 kan of zit ik er dan naast?

[ Voor 8% gewijzigd door ID-College op 12-04-2026 11:31 ]

[lier]

Kies optie 3: PiHole in een eigen VLAN en daar vanuit alle VLAN's toegang aan geven. Welke firewall gebruik je?

[Toet3r]

@ID-College
Er zijn meerdere manieren om dit voor elkaar te krijgen.
Dit hangt ook af of je pi-hole native hebt draaien of in een docker container. Zelf draai ik pi-hole in een docker container. Heb methode 2 daar laatst geprobeerd werkend te krijgen maar zonder success.

methode 1:
In je router alle vlans die je gebruik wil laten maken van pi-hole het ip van je pi-hole instellen als dns server voor die vlans.
In de firewall van je router vanaf die vlans poort 53 tcp/udp toestaan naar je pihole.

methode 2:
Je raspberry pi in alle vlans hangen, door op je raspberry pi een vlan te maken voor alle vlans waar je pi-hole wil gebruiken.
bijv.
eth0.10 - 192.168.10.250
eth0.20 - 192.168.20.250
etc.

Hierna stel je op je router voor elk van die vlans het bijbehorende ip in als dns server.

Zie deze tutorial: Toet3r in "[Pi-Hole] Ervaringen & discussie"

Success

[ Voor 20% gewijzigd door Toet3r op 12-04-2026 11:55 ]

[ID-College]

Toet3r schreef op zondag 12 april 2026 @ 11:41:
@ID-College
Er zijn meerdere manieren om dit voor elkaar te krijgen.
Dit hangt ook af of je pi-hole native hebt draaien of in een docker container. Zelf draai ik pi-hole in een docker container. Heb methode 2 daar laatst geprobeerd werkend te krijgen maar zonder success.

methode 1:
In je router alle vlans die je gebruik wil laten maken van pi-hole het ip van je pi-hole instellen als dns server voor die vlans.
In de firewall van je router vanaf die vlans poort 53 tcp/udp toestaan naar je pihole.

methode 2:
Je raspberry pi in alle vlans hangen, door op je raspberry pi een vlan te maken voor alle vlans waar je pi-hole wil gebruiken.
bijv.
eth0.10 - 192.168.10.250
eth0.20 - 192.168.20.250
etc.

Hierna stel je op je router voor elk van die vlans het bijbehorende ip in als dns server.

Zie deze tutorial: Toet3r in "[Pi-Hole] Ervaringen & discussie"

Success

Ik denk dat die post erg kan helpen! Vanavond even kijken ik draai PiHole op een raspberry pi dus niet in een docker container! Optie 2 heeft nu mijn voorkeur maar ik mis wel een goede setup om dit te regelen nog

@lier : waarom is dit precies beter? Maakt het toch alleen maar ingewikkelder? Ik gebruik de zone-based firewall van Unifi..

[Airw0lf]

ID-College schreef op zondag 12 april 2026 @ 11:30:
Kan iemand mij een klein beetje in de goede richting duwern voor een goede tutorial om Pi-Hole in meerdere VLAN's te draaien? Ik heb een Unifi dream router met 4 VLAN's (Main/IoT/IPTV/Guest) en de Pi-Hole draaien in main. De DNS van main gaat naar de Pi-Hole maar de overige 3 VLAN's kunnen er niet bij uiteraard momenteel. Wat is de beste setup:
1. firewall rules instellen voor access bij overige VLANS naar Pi-Hole en deze in Main laten draaien; of
2. per VLAN een eigen listener?

Optie 2 klinkt als de beste oplossing als ik zo lees maar krijg het niet 1,2,3 voor elkaar om eerlijk te zijn. Is optie 1 een slechte optie of heeft iemand een goede turorial ergens voor optie 2 die zich makkelijk laat volgen? Het liefste wil ik de clients zien in pi-hole maar niet per se een must. Ik begrijp dat dit alleen met optie 2 kan of zit ik er dan naast?

Mijn 0,500 Euro (zo gebruikt ik het nu een jaar of 5):
De Pihole webui gebruiken voor de management vlan instellingen.
En alle andere vlans gaan buiten de pihole-webui om via dnsmasq scriptjes.
Wel komen alle clients terug in de dashboards.

Randvoorwaarde is wel dat je voor elk vlan een interface actief hebt - bijvoorbeeld eth0.100, eth0.200, eth0.300 voor resp. vlan 100, 200 en 300 - althans dat is zoals ik het gedaan heb via systemd-networkd.

Ik wil het toml bestand en het dnsmasq bestand wel delen.
Maar ze zijn te groot/lang om hier te posten - iemand suggesties?

[ Voor 7% gewijzigd door Airw0lf op 12-04-2026 12:22 ]

[ID-College]

@Toet3r dat stappenplan was een makkie eigenlijk. Het werkt nu idd.. Ben niet zon extreme netwerkguru, ben wel benieuwd wat de voor- (en nadelen) van de verschillende opties zijn.. Voor nu zie ik idd de daadwerkelijke clients in pihole en worden de adds geblokkeerd op alle vlan's

[The Eagle]

Je issue is dat een pihole standaard maar requests accepteert van local devices (max 1 hop afstand).
Zet in pihole onder dns settings de optie aan "Permit all origins" en je bent er ook.

[ID-College]

The Eagle schreef op maandag 13 april 2026 @ 21:43:
Je issue is dat een pihole standaard maar requests accepteert van local devices (max 1 hop afstand).
Zet in pihole onder dns settings de optie aan "Permit all origins" en je bent er ook.

Dat is idd een alternatief maar ik werd huiverig omdat je ook lees dat je Pi-Hole een open DNS server worden voor het hele internet. Nu kan (als het goed is) niemand erbij, maar heb toch de voorkeur om het iets gecontroleerd te houden (ipv alles maar open te zetten). Deze optie had dus niet per se mijn voorkeur

[Webgnome]

@ID-College zo lang je niet je router open gooit of een poortje (53) open zet voor het internet naar je pihole dan is vrij weinig aan de hand..

[Webgnome]

sweetdude schreef op dinsdag 31 maart 2026 @ 15:48:
n.a.v. dit artikel op de frontpage:
review: Providers als poortwachter tegen online fraude: Anti Phishing Shield uitgelegd

Is er al ergens bekend welke lijst gehanteerd wordt? Mogelijk handig als deze al niet in de andere bekende lijsten zit om toe te voegen.

Heb je hier nog naar gezocht of er iets te vinden is voor pihole?

[sweetdude]

Webgnome schreef op dinsdag 14 april 2026 @ 08:55:
[...]


Heb je hier nog naar gezocht of er iets te vinden is voor pihole?

Ja wel nog naar gezocht, maar niet specifiek die lijst ergens gevonden helaas Het lijkt alsof deze alleen met providers wordt gedeeld.

Ik heb wel deze gevonden, ik kende hem niet en hij blokkeert toch wat extra's t.o.v. mijn gebruikte lijsten (zoals oisd.nl, stevenblack, firebog, easylist etc.)
https://phishing.army/

[Raven]

Kent iemand een manier van hoe je 2 Pi-Hole 6 installaties draaiende onder Raspberry Pi OS, zónder iets dat in Docker draait, met elkaar in sync kan houden?

[blackd]

@Raven nebula-sync kan standalone draaien zonder docker.

[Raven]

@blackd Ik kom alleen Docker-tutorials tegen

[blackd]

@Raven op de github README staat dat je de release kunt downloaden en standalone kunt uitvoeren.
https://github.com/lovela...e-ov-file#linuxosx-binary
De environment variabelen in een .env file zetten en het commando met --env-file flag uitvoeren.

[Raven]

@blackd Begint al goed:

Bash:

./nebula-sync run --env-file .env
2026-04-17T18:41:22+02:00 INF Starting nebula-sync v0.11.1
2026-04-17T18:41:22+02:00 INF Running sync mode=selective replicas=1
2026-04-17T18:41:22+02:00 INF Authenticating clients...
2026-04-17T18:41:23+02:00 INF Invalidating sessions...
2026-04-17T18:41:23+02:00 WRN Failed to invalidate session for target: https://tara.ravenslair.nl
2026-04-17T18:41:25+02:00 WRN Failed to invalidate session for target: https://kennedy.ravenslair.nl
2026-04-17T18:41:25+02:00 FTL Sync failed error="authenticate: https://tara.ravenslair.nl/api/auth: Post \"https://tara.ravenslair.nl/api/auth\": tls: failed to verify certificate: x509: certificate signed by unknown authority"

Blijkbaar geen support voor Let's Encrypt wildcard certificaat, update-ca-certificates hielp ook niet, en ik zie daarnaast geen optie om m.b.t. DNS alléén Local DNS records te syncen, iets waarbij ik niet de enige ben.

edit: De foutmelding werd veroorzaakt doordat /etc/pihole/tls.pem alleen de Let's Encrypt cert en privkey bevat, niet ook de chain, terwijl de webinterface van PiHole zonder chain prima werkt, in browsers.

Later ff uitzoeken waarom Pi nr 2 dwarsligt, die geeft nog wel een TLS error.

[ Voor 13% gewijzigd door Raven op 17-04-2026 18:53 ]

[jojost1]

Raven schreef op donderdag 16 april 2026 @ 19:02:
Kent iemand een manier van hoe je 2 Pi-Hole 6 installaties draaiende onder Raspberry Pi OS, zónder iets dat in Docker draait, met elkaar in sync kan houden?

Ik gebruik op iOS ‘Pi-hole Remote’ die een aantal dingen kan syncen. Blijft een handmatige actie, maar zo heb je geen andere programma’s nodig.

[Raven]

@jojost1 Helaas geen Apple-devices hier. Alhoewel, er ligt ergens een AR9380 met merknaam Apple erin
(Dat was een WTF toen ik tijdens het booten van Debian in de bootmessages ineens Apple voorbij zag komen)

[DjoeC]

Raven schreef op donderdag 16 april 2026 @ 19:02:
Kent iemand een manier van hoe je 2 Pi-Hole 6 installaties draaiende onder Raspberry Pi OS, zónder iets dat in Docker draait, met elkaar in sync kan houden?

In de meest simpele vorm zou ik zeggen: 1 hoofdinstantie, regelmatig als batchscript Teleporter draaien, laden in 2e instantie, gravity update en klaar. Ik draai dagelijk een Teleporter script als configuratie backup.

[Gunner]

jojost1 schreef op zaterdag 18 april 2026 @ 07:33:
[...]

Ik gebruik op iOS ‘Pi-hole Remote’ die een aantal dingen kan syncen. Blijft een handmatige actie, maar zo heb je geen andere programma’s nodig.

Mooie tool inderdaad. Ik doneer regelmatig aan de maker, een Nederlander, die ook wel eens feedback van me gebruikt heeft om iets aan te passen.

[Raven]

@blackd Inmiddels gelukt met nebula-sync (na SSL/TLS issue op 2e Pi gefixed te hebben). Het script stopt echter niet, blijft runnen na "INF Sync completed" ...... https://github.com/lovelaze/nebula-sync/discussions/217 ah dat is vanwege cron in de environment file.

[Toet3r]

Er is weer een update uitgebracht
changelog: https://discourse.pi-hole...ore-v6-4-2-released/85843

[ Voor 36% gewijzigd door Toet3r op 25-04-2026 00:19 ]

[MAdD]

Zijn er meer mensen, waarop in eens de web-pagina van Pi-Hole niet meer lekker werkt?

Ik draai versie Core v6.4.2, FTL v6.6.1, Web interface v6.5

het probleem is alsvolgt:

[W1ck1e]

MAdD schreef op dinsdag 5 mei 2026 @ 11:26:
Zijn er meer mensen, waarop in eens de web-pagina van Pi-Hole niet meer lekker werkt?

Ik draai versie Core v6.4.2, FTL v6.6.1, Web interface v6.5

het probleem is alsvolgt:

[Afbeelding]

Dat is een mooie afbeelding, maar ik ben meer van de "plaatjes met een praatje". Oftewel wat wil je en wat is het probleem ?

btw: ik heb die versies ook, gisteren geinstalleerd. Had je bij de vorige versie ook het probleem ?

[ Voor 5% gewijzigd door W1ck1e op 05-05-2026 11:44 ]

[DjoeC]

MAdD schreef op dinsdag 5 mei 2026 @ 11:26:
Zijn er meer mensen, waarop in eens de web-pagina van Pi-Hole niet meer lekker werkt?

Ik draai versie Core v6.4.2, FTL v6.6.1, Web interface v6.5

het probleem is alsvolgt:

[Afbeelding]

Ik kan wel "ongeveer" hetzelfde scherm produceren, maar - wat werkt er dan niet goed???

Ik ga naar query log, klik dan op het plusje voor advanced filtering, vervolgens op de 3 streepjes rechtsboven om de info te krijgen. Klik in dat blokje om de info weer weg te halen en op het minnetje in advanced filtering om het scherm weer "normaal" te krijgen.

Ik "zie" je probleem nog niet?

=> Aanvulling: Ah, gaat het erom dat je paginering verticaal staat ipv horizontaal?

Ik zie ook het "draaiwiel" bij jou inclusief wat lijkt op een "close" knop? Dat heb ik nog nooit gezien....

[ Voor 7% gewijzigd door DjoeC op 05-05-2026 12:12 ]

[Lizard]

MAdD schreef op dinsdag 5 mei 2026 @ 11:26:
Zijn er meer mensen, waarop in eens de web-pagina van Pi-Hole niet meer lekker werkt?

Ik draai versie Core v6.4.2, FTL v6.6.1, Web interface v6.5

het probleem is alsvolgt:

[Afbeelding]

Lijkt erop alsof bepaalde css o.i.d. niet geladen wordt.
In het linkermenu bij Tools en bovenaan bij '<<' zie je een oranje balkje wat bij mij rond is met een getal erin.
Ook de opmaak van de statistieken aan de linkerkant is verkeerd.
Als je via de browser tools kijkt, zie je dan wat geblokkeerd worden?
Niet toevallig uBlock Origin die iets blokkeert ofzo?

[DaRk PoIsOn]

Hebben jullie deze al gezien?

Iemand op Reddit heeft een soort Space Invaders gemaakt.
Alle geblockte queries worden door een ruimteschip met een laserstraal kapotgeschoten terwijl de andere queries worden doorgelaten. De sterrenhemel is real life met 12,200 sterren en af en toe komt het ISS voorbij

https://www.reddit.com/r/pihole/s/oGm69B5Xxk

[Wylana]

DaRk PoIsOn schreef op woensdag 6 mei 2026 @ 01:24:
Hebben jullie deze al gezien?

Iemand op Reddit heeft een soort Space Invaders gemaakt.
Alle geblockte queries worden door een ruimteschip met een laserstraal kapotgeschoten terwijl de andere queries worden doorgelaten. De sterrenhemel is real life met 12,200 sterren en af en toe komt het ISS voorbij

https://www.reddit.com/r/pihole/s/oGm69B5Xxk

GE NI AAL!!!!😂

[MAdD]

Lizard schreef op dinsdag 5 mei 2026 @ 22:25:
[...]

Lijkt erop alsof bepaalde css o.i.d. niet geladen wordt.
In het linkermenu bij Tools en bovenaan bij '<<' zie je een oranje balkje wat bij mij rond is met een getal erin.
Ook de opmaak van de statistieken aan de linkerkant is verkeerd.
Als je via de browser tools kijkt, zie je dan wat geblokkeerd worden?
Niet toevallig uBlock Origin die iets blokkeert ofzo?

Het probleem lijkt weer opgelost.... ik draai alleen Pi-Hole ... merk dat er meerdere zaken op mijn machine in Edge niet goed gaan.... zal wel een omgevallen bitje/byteje zijn die nu weer goed staat....

[Toet3r]

Er is weer een update uitgebracht met een aantal CVE fixes.

https://github.com/pi-hole/FTL/releases/tag/v6.6.2

CVE-2026-2291 — Heap OOB write in struct bigname. The on-heap namebuffer was sized for the wire form of a domain name (MAXDNAME) rather than its escaped internal form (MAXDNAME*2 + 1). A remote peer that can send or answer DNS queries could cause a large out-of-bounds write on the heap. Reported by Andrew S. Fasano.

CVE-2026-4890 — DNSSEC denial of service via NSEC bitmap parsing.The window-iteration step omitted the 2-byte window header, so a crafted NSEC record with bitmap_length == 0 produced an infinite loop and dnsmasq stopped answering queries. Reachable before RRSIG validation,so no valid signatures are required to trigger it. Reported by Royce M.

CVE-2026-4891 — DNSSEC crash via crafted RRSIG. A packet declaring an rdlen smaller than the fixed RRSIG header plus signer's name produced a negative signature length and a subsequent crash. Reported by Royce M.

CVE-2026-4892 — Privileged buffer overflow in the DHCP helper.When --dhcp-script is configured, hex-encoded DHCPv6 client identifiers (up to 65535 bytes) were written into a 5131-byte buffer in the root-privileged helper. Reported by Royce M.

CVE-2026-4893 — EDNS Client Subnet validation bypass. With--add-subnet enabled, process_reply() passed the OPT record length(~23 bytes) to check_source() instead of the packet length, causing every internal bounds check to fail and the validation routine to always return success. ECS source validation per RFC 7871 §9.2 was effectively disabled. Reported by Royce M.

CVE-2026-5172 — Heap OOB read in extract_addresses(). A mismatched RR rdlen allowed extract_name() to advance past the computed end of the record, underflowing the remaining-bytes calculation and producing a large OOB read with certain crash.Reported by Hugo Martinez Ray.

[Pietervs]

Toet3r schreef op maandag 11 mei 2026 @ 22:36:
Er is weer een update uitgebracht met een aantal CVE fixes.

https://github.com/pi-hole/FTL/releases/tag/v6.6.2

[...]

Lijkt erop dat de maker(s) dus deze aangepakt hebben
De problemen lijken dus in dnsmasq te zitten. Wat best bijzonder is: Pihole gebruikt dnsmasq toch niet? Tenzij pihole-FTL een fork is van dnsmasq natuurlijk.

[Airw0lf]

Pietervs schreef op dinsdag 12 mei 2026 @ 11:23:
[...]

Lijkt erop dat de maker(s) dus deze aangepakt hebben
De problemen lijken dus in dnsmasq te zitten. Wat best bijzonder is: Pihole gebruikt dnsmasq toch niet? Tenzij pihole-FTL een fork is van dnsmasq natuurlijk.

Jawel hoor - sterker nog - zonder dnsmasq geen pihole...

[Pietervs]

Airw0lf schreef op dinsdag 12 mei 2026 @ 11:27:
[...]

Jawel hoor - sterker nog - zonder dnsmasq geen pihole...

weet je dat zeker?
Als ik dit lees (is wel uit 2020, dus misschien verouderd?) zie ik dat het ook znder dnsmasq zou kunnen werken: If you decide to keep your existing dnsmasq, have it distribute your Pi-hole's IP address as the sole DNS server via DHCP, and configure Pi-hole to use your dnsmasq instance as its sole upstream.

Maar ook de documentatie van Pihole zegt: FTLDNS comes with a lightweight but powerful inbuilt DNS/DHCP/TFTP/... server eliminating the need to install dnsmasq separately

edit:
overigens lees ik daar nu ook "As we maintain our own fork of dnsmasq". Dus pihole-FTL is inderdaad een fork wat de kwetsbaarheid verklaart die nu gefixed is

[ Voor 9% gewijzigd door Pietervs op 12-05-2026 12:34 ]

[Toet3r]

Pietervs schreef op dinsdag 12 mei 2026 @ 11:23:
[...]

Lijkt erop dat de maker(s) dus deze aangepakt hebben
De problemen lijken dus in dnsmasq te zitten. Wat best bijzonder is: Pihole gebruikt dnsmasq toch niet? Tenzij pihole-FTL een fork is van dnsmasq natuurlijk.

Pi-hole gebruikt een gemodificeerde versie van dnsmasq die ze FTL dns hebben genoemd.

[ Voor 3% gewijzigd door Toet3r op 12-05-2026 12:56 ]

[jpgview]

pihole-FTL heeft een aantal onderdelen die je vroeger apart moest installeren (voorbeeld sqlite3) nu zelf aan boord (embedded).

Als je het commando pihole-FTL -vv uitvoert, krijg je een overzicht van de onderdelen en de versie ervan.

Alle functionaliteit die dnsmasq bied (zie dnsmasq man page) is beschikbaar voor gebruik wanneer pihole-FTL draait. Je zal echter zelden ook de dnsmasq binary op dat systeem vinden (which dnsmasq), vind je die wel, dan is die naar alle waarschijnlijkheid disabled.

[sweetdude]

Voor de mensen die DietPi gebruiken als OS voor PiHole.

Volgens mij is dit een mogelijke (breaking?) change met impact:

• DietPi-Software | Unbound: We push our own up-to-date Unbound packages via our APT server now. This means, that also users who did not install Unbound via dietpi-software get our default config and reduced Debian-only content. Please let us know if you face any issues.

Als ze de bestaande config gaan overschrijven.

[ Voor 5% gewijzigd door sweetdude op 18-05-2026 13:24 ]

[W1ck1e]

sweetdude schreef op maandag 18 mei 2026 @ 13:24:
Voor de mensen die DietPi gebruiken als OS voor PiHole.

Volgens mij is dit een mogelijke (breaking?) change met impact:

• DietPi-Software | Unbound: We push our own up-to-date Unbound packages via our APT server now. This means, that also users who did not install Unbound via dietpi-software get our default config and reduced Debian-only content. Please let us know if you face any issues.

Als ze de bestaande config gaan overschrijven.

Ik gebruik geen Unbound. Dan neem ik even aan dat ik niks ga merken. Toch ?

[TheCeet]

Voor de Hagezi blocklist users, ter info:

quote: https://www.reddit.com/r/.../1txbjh0/comment/opuoc3u/

GitHub forced a password reset and locked my repository. It feels like some automated system jumped into action after one person submitted multiple reports from different accounts, and GitHub seems to respond to those reports before fully investigating.

I completed the reset and now have access again - I can view the repository and push updates. However, it’s still showing a 404 error for everyone else. I’ve opened a support ticket with GitHub. What a hassle.

Mirror is online: https://gitlab.com/hagezi/mirror

[Webgnome]

Ah, zijn er misschien ook andere wijzigingen geweest op die lijst? Ik kreeg vanmorgen een hele bak aan errors op 1password domeinen. En die bleken allemaal uit die list te komen?

[DjoeC]

TheCeet schreef op vrijdag 5 juni 2026 @ 09:30:
Voor de Hagezi blocklist users, ter info:


[...]

Net een Gravity update gedaan en de Hagezi lijsten komen correct binnen.

[TheCeet]

Klopt, sinds +-16:15 zijn de lijsten terug beschikbaar op Github

[Raven]

Weet iemand of PiHole 6 de clientnaam "pi.hole" in de query log ergens hardcoded heeft staan? Ik wil in het query log graag de hostnaam met lokaal gebruikte domein en tld daar graag zien, net als bij andere devices, PiHole blijft echter vasthouden aan de clientnaam pi.hole van de Pi waar ie op draait.

Ik heb in pihole.toml deze al hernoemd, daarnaast een entry toegevoegd in de List of local DNS records, maar nog steeds blijft de naam pi.hole verschijnen. Is dit gewoon hardcoded of is er ergens een instelling die ik nog niet gevonden heb?

[ Voor 3% gewijzigd door Raven op 21-06-2026 16:20 ]

[Witlof]

Kijk eens in de all settings (expert mode) bij de PTR settings wat daar staat. Wellicht is dat de oplossing die je zoekt.

[Raven]

@Witlof Daar lijkt het inderdaad te zitten , nu krijg ik de hostnaam, echter nog niet die wat ik incl domein en tld heb ingesteld in de local DNS records lijst. Bij alle andere apparaten werkt dat wel, daar wordt op basis van IP-adres de naam.domein.tld uit die lijst in de query log weergegeven.

edit: Op None zetten was de oplossing

[ Voor 6% gewijzigd door Raven op 21-06-2026 17:22 ]

[W1ck1e]

Raven schreef op zondag 21 juni 2026 @ 17:21:
@Witlof Daar lijkt het inderdaad te zitten , nu krijg ik de hostnaam, echter nog niet die wat ik incl domein en tld heb ingesteld in de local DNS records lijst. Bij alle andere apparaten werkt dat wel, daar wordt op basis van IP-adres de naam.domein.tld uit die lijst in de query log weergegeven.

edit: Op None zetten was de oplossing

Bedoel je deze instelling ?

[Raven]

W1ck1e schreef op zondag 21 juni 2026 @ 17:51:
[...]

Bedoel je deze instelling ?

[Afbeelding]

dns.piholePTR , waar "PI.HOLE" de default is, andere opties zijn hostname, hostnameFQDN en none.

Die instelling geeft het in uppercase aan (vandaar dat het niet opviel), echter zie ik daar dit bij staan: Respond with "pi.hole".

[ Voor 13% gewijzigd door Raven op 21-06-2026 17:57 ]

[W1ck1e]

Raven schreef op zondag 21 juni 2026 @ 17:56:
[...]

dns.piholePTR , waar "PI.HOLE" de default is, andere opties zijn hostname, hostnameFQDN en none.

Die instelling geeft het in uppercase aan (vandaar dat het niet opviel), echter zie ik daar dit bij staan: Respond with "pi.hole".

Dus bij "All Settings" / "DNS server" tabblad



Ik heb 3 piholes en die staan allemaal op "pi.hole" Dat kan dus beter

[Raven]

W1ck1e schreef op zondag 21 juni 2026 @ 18:08:
[...]

Dus bij "All Settings" / "DNS server" tabblad

[Afbeelding]

Ik heb 3 piholes en die staan allemaal op "pi.hole" Dat kan dus beter

Check, die staat daar dus standaard op en daardoor negeert PiHole wat in de local DNS lijst staat....

[Raven]

Zou iemand een reden kunnen bedenken waarom de local DNS lijst niet altijd gebruikt lijkt te worden om de client IP adressen te resolven in de query log?

Ik heb alle Shelly's in de local DNS lijst gezet in beide PiHoles, nu zijn er Shelly's in de query log waarvan de client IP wel wordt geresolved naar wat ik in de local DNS lijst heb gezet, echter zijn er ook Shelly's die niet worden geresolved terwijl de IP-adressen wel in de local DNS lijst staan

[W1ck1e]

Raven schreef op dinsdag 23 juni 2026 @ 10:34:
Zou iemand een reden kunnen bedenken waarom de local DNS lijst niet altijd gebruikt lijkt te worden om de client IP adressen te resolven in de query log?

Ik heb alle Shelly's in de local DNS lijst gezet in beide PiHoles, nu zijn er Shelly's in de query log waarvan de client IP wel wordt geresolved naar wat ik in de local DNS lijst heb gezet, echter zijn er ook Shelly's die niet worden geresolved terwijl de IP-adressen wel in de local DNS lijst staan

Maak eens een mooi plaatje met de piholes (en hun relatie) en welke de dhcp server is (there can be only one). En gebruiken die "shelly's" dhcp of zijn ze static geconfigureerd op het device zelf ?

[Raven]

W1ck1e schreef op dinsdag 23 juni 2026 @ 10:42:
[...]

Maak eens een mooi plaatje met de piholes (en hun relatie) en welke de dhcp server is (there can be only one). En gebruiken die "shelly's" dhcp of zijn ze static geconfigureerd op het device zelf ?

De DHCP-server is de router-pc, niet een van de PiHoles. Beide PiHoles hebben een statisch IP-adres (de een *.*.*.253 de ander *.*.*.254), de Shelly's maken gebruik van static DHCP. De IP-adressen van de Shelly's komen exact overeen met wat in de local DNS lijst staat.

Voorbeeld uit log:

code:

2026-06-22 12:08:19         A   updates.shelly.cloud    lamp.computerkamer.domain.nl    12.8 ms 
2026-06-22 12:04:51         A   updates.shelly.cloud    10.0.5.19   13.3 ms 
2026-06-22 12:04:03         A   updates.shelly.cloud    lamp.rommelkamer.domein.nl  5.5 ms  
2026-06-22 12:00:33         A   updates.shelly.cloud    10.0.5.25   11.9 ms 
2026-06-22 12:00:33         A   updates.shelly.cloud    10.0.5.20   12.0 m

Stukje uit de local DNS lijst van de PiHoles:

code:

lamp.rommelkamer.domein.nl  10.0.5.4
lamp.computerkamer.domein.nl    10.0.5.9
vriezer.keuken.domein.nl    10.0.5.19
ont.woonkamer.domein.nl 10.0.5.20
lamp3.woonkamer.domein.nl   10.0.5.25

[W1ck1e]

@Raven Wat is de gemeenschappelijke factor van de 2 die wel resolven die ze onderscheidt van de 3 die niet resolven ? Ik denk dat je het in die richting moet zoeken.

[Raven]

@W1ck1e
lamp.computerkamer.domain.nl -> 1PM Mini Gen4
lamp.rommelkamer.domein.nl -> 1PM Mini Gen4
10.0.5.19 (vriezer.keuken.domein.nl) -> PM Mini Gen3
10.0.5.20 (ont.woonkamer.domein.nl) -> PM Mini Gen3
10.0.5.25 (lamp3.woonkamer.domein.nl) -> PlusPlugS

Instellingen zijn hetzelfde, zelfde VLAN, zelfde subnet, zelfde DNS, zelfde NTP server ..... ik heb geen idee wat er verschillend zou kunnen zijn dat dit kan verklaren. Dit zijn er echter maar een paar (van de 30+ Shelly's), zijn er meer die niet resolven en ook de nodige die wel resolven. Ik zie vooralsnog geen patroon.

[Airw0lf]

Raven schreef op dinsdag 23 juni 2026 @ 10:54:
[...]

De DHCP-server is de router-pc, niet een van de PiHoles. Beide PiHoles hebben een statisch IP-adres (de een *.*.*.253 de ander *.*.*.254), de Shelly's maken gebruik van static DHCP. De IP-adressen van de Shelly's komen exact overeen met wat in de local DNS lijst staat.

Voorbeeld uit log:

code:

2026-06-22 12:08:19         A   updates.shelly.cloud    lamp.computerkamer.domain.nl    12.8 ms 
2026-06-22 12:04:51         A   updates.shelly.cloud    10.0.5.19   13.3 ms 
2026-06-22 12:04:03         A   updates.shelly.cloud    lamp.rommelkamer.domein.nl  5.5 ms  
2026-06-22 12:00:33         A   updates.shelly.cloud    10.0.5.25   11.9 ms 
2026-06-22 12:00:33         A   updates.shelly.cloud    10.0.5.20   12.0 m

Stukje uit de local DNS lijst van de PiHoles:

code:

lamp.rommelkamer.domein.nl  10.0.5.4
lamp.computerkamer.domein.nl    10.0.5.9
vriezer.keuken.domein.nl    10.0.5.19
ont.woonkamer.domein.nl 10.0.5.20
lamp3.woonkamer.domein.nl   10.0.5.25

Mijn inschatting is dat je router-pc de "echte" dns server is omdat die altijd weet heeft van het "laatst" uitgegeven (static-)dhcp adres. Het advies is dan ook om in beide pihole configs de volgende regels toe te voegen:

code:

server=/domein.nl/<ip-van-router-pc>
rev-server=10.0.0.0/8,<ip-van-router-pc>

Wel nog even tjekke of 10.0.0.0/8 in jouw geval klopt.

Overigens lijkt het me goed om nog eens kritisch te kijken naar je pihole settings - dit i.v.m. een .nl domein voor een private netwerk - iets met .lan is handiger. Gekoppeld aan de instellingen die er voor zorgen dat er altijd met fqdn's gewerkt wordt. Dus alleen vriezer of lamp3 zonder het volledige domein wordt geweigerd door pihole/dnsmasq.

Als je met vlans werkt en je wil pihole/dnsmasq voor alle vlans gebruiken zul je aan de slag moeten met een vlan config bestandje in /etc/dnsmasq.d/.

[ Voor 8% gewijzigd door Airw0lf op 23-06-2026 11:30 ]

[Raven]

@Airw0lf Ik gebruik een Let's Encrypt wildcard in mijn netwerk, voor de apparaten die https doen dan, vandaar de domeinnaam. Buiten dat, in het geval van de Shelly's gaat het voornamelijk om identificatie in de query log, ken jij van elke Shelly (of welk IoT device dan ook) het IP-adres uit het hoofd?

In PiHole 5 werkte dit resolven in de query log prima, nu werkt het maar half.

edit: @Airw0lf @W1ck1e Zit net bij Tools -> Network te kijken in PiHole, daar worden de links tussen IP-adres en local DNS lijst wél gelegd.

[ Voor 16% gewijzigd door Raven op 23-06-2026 11:53 ]

[Airw0lf]

Raven schreef op dinsdag 23 juni 2026 @ 11:32:
@Airw0lf Ik gebruik een Let's Encrypt wildcard in mijn netwerk, voor de apparaten die https doen dan, vandaar de domeinnaam. Buiten dat, in het geval van de Shelly's gaat het voornamelijk om identificatie in de query log, ken jij van elke Shelly (of welk IoT device dan ook) het IP-adres uit het hoofd?

In PiHole 5 werkte dit resolven in de query log prima, nu werkt het maar half.

Het gebruik van Lets Encrypt voor een "private" .nl domein is eleganter(?) op te lossen met de inzet van een reverse proxy (naast pihole). Daarmee kan je nog steeds Lets Encrypt gebruiken - ook voor private vlans die geen .nl domein hebben.

En nee - ik ken niet alle IP's uit mijn hoofd. Ik maak al jaren dankbaar gebruik van pihole/dnsmasq en een reverse proxy voor dit vraagstuk.

De genoemde suggestie om je resolving probleem op te lossen heeft te maken met het feit dat in pihole 6 het nodige is veranderd waardoor een pihole 5 config niet meer werkt.

[Airw0lf]

Raven schreef op dinsdag 23 juni 2026 @ 11:32:

edit: @Airw0lf @W1ck1e Zit net bij Tools -> Network te kijken in PiHole, daar worden de links tussen IP-adres en local DNS lijst wél gelegd.

Je hebt een forward lookup en een reverse lookup - wat in die lijst staat bepaald niet of die lookups op enig moment gaan werken. Het zegt alleen maar iets over wat er op enig moment eens voorbij is gekomen.

Ook kan er een moment geweest zijn dat een van die twee lookups even niet heeft gewerkt. Vanaf dat moment werken alle soortgelijke lookups niet meer => pihole/dnsmasq moeten dan een handje geholpen worden met een herstart. Maar dat heeft pas zin als er maar een waarheid is voor de combinatie dhcp en dns. En ik gok dat die ene waarheid bij je router-pc ligt - niet bij pihole/dnsmasq.

[ Voor 3% gewijzigd door Airw0lf op 23-06-2026 12:32 ]

[Raven]

@Airw0lf

"Ik maak al jaren dankbaar gebruik van pihole/dnsmasq en een reverse proxy voor dit vraagstuk."
En ik dus de local DNS lijst in PiHole, wat voor mij werkt

" De genoemde suggestie om je resolving probleem op te lossen heeft te maken met het feit dat in pihole 6 het nodige is veranderd waardoor een pihole 5 config niet meer werkt. "
Beide Pi's draaien een schone v6, ik heb niet de config van een v5 installatie geprobeerd te importeren, de local DNS lijst heb ik met de hand opnieuw aangemaakt.

Misschien maar even paar dagen aankijken, kijken of het verbeterd.

[W1ck1e]

@Raven

heb je hier wat aan ?

ik gebruik op dit moment een 3tal rpi's voor mijn dhcp en piholes
mijn dhcp rpi draait ook pihole maar dan zonder block lists
de pihole dhcp software heeft een aantal opties die ik gebruik. ik draaide in het verleden mijn dhcp op een buffalo router (als access point)

de 2 pihole rpi's hebben wel block list en maken naast een aantal publieke dns servers gebruik van de dhcp rpi als upstream dns servers

code:

ipa.ddr.ess.001     geanonimiseerd ip adres
ma:ca:dd:re:ss:01   geanonimiseerd mac adres

de dhcp server rpi is leading voor de lokale dns namen
daar heb ik een /etc/hosts bestand met onder meer:

code:

127.0.0.1 localhost
127.0.1.1 dhcp
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

&

code:

ipa.ddr.ess.001   p1mon
ipa.ddr.ess.002   router
ipa.ddr.ess.003   dhcp
192.168.178.1     modem

deze apparaten hebben een lokaal ingesteld static ipadres of doen een beetje moeilijk

op de dhcp server rpi heb ik een /etc/dnsmasq.d/01-buffalo.conf bestand met onder meer:

code:

dhcp-host=ma:ca:dd:re:ss:01,Kindle
dhcp-host=ma:ca:dd:re:ss:02,Tablet1
dhcp-host=ma:ca:dd:re:ss:03,Tablet2

deze apparaten krijgen een ipadres dat mij niet boeit, en ik wil ze kunnen herkennen aan de hostnaam
ze verschijnen onder tools / network met ".local" achter de hostnaam

op de pihole rpi's heb ik een /etc/hosts bestand met alleen dit :

code:

127.0.0.1 localhost
127.0.1.1 Pihole3
#::1 localhost ip6-localhost ip6-loopback
#ff02::1 ip6-allnodes
#ff02::2 ip6-allrouters

in de web config van de pihole rpi's heb ik

code:

Pi-hole domain name
domain : local

code:

Conditional forwarding :
true,ipa.ddr.ess.0/24,ipa.ddr.ess.003,local

ik kan al mijn apparaten benaderen met en zonder ".local"
ik doe niets met reverse proxies

[ Voor 4% gewijzigd door W1ck1e op 23-06-2026 13:34 ]

[Airw0lf]

Raven schreef op dinsdag 23 juni 2026 @ 12:53:
@Airw0lf

"Ik maak al jaren dankbaar gebruik van pihole/dnsmasq en een reverse proxy voor dit vraagstuk."
En ik dus de local DNS lijst in PiHole, wat voor mij werkt

" De genoemde suggestie om je resolving probleem op te lossen heeft te maken met het feit dat in pihole 6 het nodige is veranderd waardoor een pihole 5 config niet meer werkt. "
Beide Pi's draaien een schone v6, ik heb niet de config van een v5 installatie geprobeerd te importeren, de local DNS lijst heb ik met de hand opnieuw aangemaakt.

Misschien maar even paar dagen aankijken, kijken of het verbeterd.

Ik heb gemerkt dat pihole 6 op sommige functies anders werkt dan pihole 5.

Een local dns lijst kan natuurlijk prima - het voordeel van een reverse proxy is dat je die dns lijsten niet meer hoeft te administreren - alles wordt automagicaly opgepakt middels een regex in de reverse proxy config. En een autorenew (i.c.m. Cloudflare) van de certs.

[Raven]

@W1ck1e @Airw0lf Nu worden de domeinnamen uit de local DNS lijst wel overal weergegeven in de query log, blijkbaar zit er enige vertraging in bij het oppikken daarvan?

offtopic:
Later eens uitzoeken waarom Raspberry Pi OS het vertikt mijn router-pc als primary NTP Server te gebruiken, kan aan de queries in PiHole zien dat beide Pi's de voorkeur geven aan fallback pool.ntp.org

edit:
@W1ck1e @Airw0lf
Dat van NTP lijkt bij PiHole te liggen. Wanneer het IP-adres van de router-pc uit de local DNS lijst in PiHole wordt opgevraagd ("Served from cache") duurt dit iets meer dan 1ms, de aanvraag van pool.ntp.org ("Served by cache optimizer") duurt in de microseconden, vandaar dat de NTP client de voorkeur geeft aan pool.ntp.org.

[ Voor 31% gewijzigd door Raven op 25-06-2026 10:43 ]

[Toet3r]

Er is weer een update uitgebracht
Changelog: https://pi-hole.net/blog/...and-core-v6-4-3-released/

[Church of Noise]

Raven schreef op woensdag 24 juni 2026 @ 22:20:
@W1ck1e @Airw0lf Nu worden de domeinnamen uit de local DNS lijst wel overal weergegeven in de query log, blijkbaar zit er enige vertraging in bij het oppikken daarvan?

offtopic:
Later eens uitzoeken waarom Raspberry Pi OS het vertikt mijn router-pc als primary NTP Server te gebruiken, kan aan de queries in PiHole zien dat beide Pi's de voorkeur geven aan fallback pool.ntp.org

edit:
@W1ck1e @Airw0lf
Dat van NTP lijkt bij PiHole te liggen. Wanneer het IP-adres van de router-pc uit de local DNS lijst in PiHole wordt opgevraagd ("Served from cache") duurt dit iets meer dan 1ms, de aanvraag van pool.ntp.org ("Served by cache optimizer") duurt in de microseconden, vandaar dat de NTP client de voorkeur geeft aan pool.ntp.org.

Ik vermoed dat dit bij mij ook gebeurt, maar mijn router/firewall onderschept de NTP requests dan weer... (FYI, DNS server aan WAN zijde is uiteraard NIET de Pi-Hole instance)

[Freee!!]

Toet3r schreef op dinsdag 7 juli 2026 @ 00:52:
Er is weer een update uitgebracht
Changelog: https://pi-hole.net/blog/...and-core-v6-4-3-released/

Ik kreeg twee verschillende updates kort na elkaar (Docker containers).

[Toet3r]

Freee!! schreef op dinsdag 7 juli 2026 @ 18:43:
[...]

Ik kreeg twee verschillende updates kort na elkaar (Docker containers).

3 zelfs 2026.07.0 t/m 2026.07.2

[Raven]

Church of Noise schreef op dinsdag 7 juli 2026 @ 14:46:
maar mijn router/firewall onderschept de NTP requests dan weer...

Ah, dat is ook een optie .... that reminds me, moet ik nog met DNS voor apparaten met hardcoded DNS server doen (die redirecten naar PiHole).

---

Toen ik nog PiHole 5 draaide werd de domeinnaam uit de local DNS lijst in de query log weergegeven wanneer het IP-adres overeen kwam met een in de local DNS lijst.

Nou hangt mij er iets van bij dat wanneer een client meerder IP-adressen heeft (IPv4, IPv6 GUA, LUA en link local) dat PiHole op basis van MAC-adres doorheeft dat dit hetzelfde apparaat is (onder Network overview te zien) en dan ook bij die adressen dezelfde naam als die in de local DNS staat in de query log weergeeft.

Dat weergeven van dezelfde naam gebeurt niet, terwijl PiHole wel doorheeft dat het om hetzelfde apparaat gaat, waardoor ik nu dus ook voor IPv6-adressen een local DNS aan moet maken om de naam in de query log te kunnen zien.

Of ik herinner het verkeerd en gebeurde dit voorheen ook niet?

[Freee!!]

Toet3r schreef op dinsdag 7 juli 2026 @ 18:47:
[...]

3 zelfs 2026.07.0 t/m 2026.07.2

Klopt, drie in twaalf uur tijd.

[TheCeet]

Ze zijn bezig met testen van extra upstreaam DNS server opties.
Zoals AdGuard Home, kan je DoH of DoT in toekomst ook gebruiken in Pi-Hole:

https://x.com/The_Pi_Hole/status/2074961394869367277

[Toet3r]

@TheCeet Dat zou een hele mooie toevoeging zijn, en nu nog een van de redenen waarom sommige adguard home boven pi-hole kiezen.

[Hann1BaL]

Toevallig even aan het testen met iOS 27 en kwam er achter dat iOS27 de gedropte DNS requests herkent en als je WiFi Connectivity Assistant aan hebt staan je apparaat om je pihole heen gaat. Dit was en is op iOS26 niet het geval.

ik gebruik Tailscale voor DNS onderweg maar op het lokale netwerk gaat die uit, maar door de WiFi Connectivity Assistance (of wat de exacte naam ook moge zijn) omzeilt je apparaat de DNS blokkade en haalt via 4/5G alsnog de ads op. Uitzetten en het is opgelost uiteraard.

[Get!em]

Hann1BaL schreef op donderdag 16 juli 2026 @ 15:16:
Toevallig even aan het testen met iOS 27 en kwam er achter dat iOS27 de gedropte DNS requests herkent en als je WiFi Connectivity Assistant aan hebt staan je apparaat om je pihole heen gaat. Dit was en is op iOS26 niet het geval.

ik gebruik Tailscale voor DNS onderweg maar op het lokale netwerk gaat die uit, maar door de WiFi Connectivity Assistance (of wat de exacte naam ook moge zijn) omzeilt je apparaat de DNS blokkade en haalt via 4/5G alsnog de ads op. Uitzetten en het is opgelost uiteraard.

Was eerder ook al eens zo. Verbreekt hij nu de wifi verbinding?

Overigens: tailscale permanent on als DNS onderweg zuipt batterij van je iPhone. Wireguard is zuiniger/minder overhead.

[Airw0lf]

Get!em schreef op donderdag 16 juli 2026 @ 16:15:
[...]

Overigens: tailscale permanent on als DNS onderweg zuipt batterij van je iPhone. Wireguard is zuiniger/minder overhead.

Waaruit blijkt dat "zuipt batterij"?

Er is inderdaad meer overhead - o.a. vanwege de beheer- en ACL laag. Maar ik kan niet zeggen dat mijn Android-foon (veel) sneller leeg is - ondanks dat Tailscale 24x7 aan staat - dus ook in het eigen WiFi.

[Get!em]

Airw0lf schreef op donderdag 16 juli 2026 @ 17:16:
[...]

Waaruit blijkt dat "zuipt batterij"?

Er is inderdaad meer overhead - o.a. vanwege de beheer- en ACL laag. Maar ik kan niet zeggen dat mijn Android-foon (veel) sneller leeg is - ondanks dat Tailscale 24x7 aan staat - dus ook in het eigen WiFi.

Uit eigen praktijk had ik er last van, en nazoek op internet leverde veel meer gevallen op. Wel op iOS, voor android kan ik niet spreken.

Maar ging om 10-15% batterij verbruik per dag. Wireguard zit bij mij 1-3% afhankelijk van gebruik.

Mobile device batteries drain quickly · Tailscale Docs

Issue staat nog open:

Mobile battery usage still bad in some situations · Issue #3363 · tailscale/tailscale

Waarin ook meerdere users aangeven dat dit icm pihole continu dns is.

[Raven]

Get!em schreef op donderdag 16 juli 2026 @ 17:23:
Issue staat nog open:

Mobile battery usage still bad in some situations · Issue #3363 · tailscale/tailscale

Waarin ook meerdere users aangeven dat dit icm pihole continu dns is.

Maar comments zijn niet toegestaan?
"This conversation has been locked and limited to collaborators."

[Hann1BaL]

Get!em schreef op donderdag 16 juli 2026 @ 17:23:
[...]

Uit eigen praktijk had ik er last van, en nazoek op internet leverde veel meer gevallen op. Wel op iOS, voor android kan ik niet spreken.

Maar ging om 10-15% batterij verbruik per dag. Wireguard zit bij mij 1-3% afhankelijk van gebruik.

Mobile device batteries drain quickly · Tailscale Docs

Issue staat nog open:

Mobile battery usage still bad in some situations · Issue #3363 · tailscale/tailscale

Waarin ook meerdere users aangeven dat dit icm pihole continu dns is.

Ik gebruik zowel Tailscale als WireGuard en merk inderdaad ook meer batterij verbruik via Tailscale hoewel Tailscale zelf ook het WireGuard protocol gebruikt. Maar de intelligentere routing doet vast iets met je iOS device.

ik heb wel eens momenten dat mijn WireGuard niet wordt geaccepteerd door een wifi netwerk en Tailscale wel. Sowieso houd ik van backup.

maar het ging uiteraard vooral even over het idee dat de Connectivity Assist je pihole “sloopt”

[Hann1BaL]

Get!em schreef op donderdag 16 juli 2026 @ 16:15:
[...]

Was eerder ook al eens zo. Verbreekt hij nu de wifi verbinding?

Overigens: tailscale permanent on als DNS onderweg zuipt batterij van je iPhone. Wireguard is zuiniger/minder overhead.

Nee de verbinding wordt niet verbroken. Je ziet als gebruiker niets gebeuren. De telefoon gebruikt blijkbaar WiFi en 5G tegelijk.

[Raven]

Hann1BaL schreef op donderdag 16 juli 2026 @ 19:32:
ik heb wel eens momenten dat mijn WireGuard niet wordt geaccepteerd door een wifi netwerk en Tailscale wel. Sowieso houd ik van backup.

offtopic:
TailScale gebruikt toch een TCP 433 fallback (DERP-relay) wanneer er alleen TCP-verkeer is toegestaan? Misschien maakt dat het verschil, UDP-block op dat WiFi netwerk.

[SkyStreaker]

Ik heb op dit moment een goed (maar amateuristisch ingesteld) pi-hole lopen op een ouder raspberry. Vaak maak ik gebruik van gamebanana maar deze loopt ineens te zeuren over html-load.com, ik wil best gamebanana.com whitelisten (wat ik ook heb gedaan), maar het gedonder blijft.

Er is vrij weinig te vinden over hoe je dit kan verslaan. html-load.com whitelisten verslaat een beetje het idee achter pi-hole. https://www.reddit.com/r/pihole/comments/1qly953/htmlload/ dit is wat gevonden heb en de link die hierin voorkomt over cookbook heb ik ook al bekeken.
Zelf een chrome-extensie in elkaar timmeren, geen idee hoe dat moet.

Heeft iemand een suggestie/oplossing?

[sweetdude]

SkyStreaker schreef op zondag 19 juli 2026 @ 10:12:
Ik heb op dit moment een goed (maar amateuristisch ingesteld) pi-hole lopen op een ouder raspberry. Vaak maak ik gebruik van gamebanana maar deze loopt ineens te zeuren over html-load.com, ik wil best gamebanana.com whitelisten (wat ik ook heb gedaan), maar het gedonder blijft.

Er is vrij weinig te vinden over hoe je dit kan verslaan. html-load.com whitelisten verslaat een beetje het idee achter pi-hole. https://www.reddit.com/r/pihole/comments/1qly953/htmlload/ dit is wat gevonden heb en de link die hierin voorkomt over cookbook heb ik ook al bekeken.
Zelf een chrome-extensie in elkaar timmeren, geen idee hoe dat moet.

Heeft iemand een suggestie/oplossing?

Nou het simpelste is denk ik eerst controleren of pi-hole wel het probleem is.Disable hem even en kijk of je het probleem dan nog hebt.

Mocht het probleem dan nog steeds voorkomen, kijk in je query log zet even "live update" aan en filter op je host en kijk wat er geblokkeerd wordt. vanuit daar kun je gaan testen met whitelisten.

[Church of Noise]

Welke browser gebruik je?

Net even naar die site gebrowsed via Firefox met Ublock Origin en helemaal geen issues tegengekomen. Misschien filter je op die manier het probleem weg vóór het zich stelt.

[SkyStreaker]

Church of Noise schreef op zondag 19 juli 2026 @ 11:01:
Welke browser gebruik je?

Net even naar die site gebrowsed via Firefox met Ublock Origin en helemaal geen issues tegengekomen. Misschien filter je op die manier het probleem weg vóór het zich stelt.

Ja, net via FF gedaan - geen probleem meer.

[Toet3r]

Voor wie naast pi-hole ook unbound heeft draaien. Er is een nieuwe versie uitgebracht, versie 1.25.2
In deze update zijn een hoop beveiligingslekken gedicht.
changelog: https://nlnetlabs.nl/proj.../download/#unbound-1-25-2

[GG85]

Toet3r schreef op donderdag 23 juli 2026 @ 18:33:
Voor wie naast pi-hole ook unbound heeft draaien. Er is een nieuwe versie uitgebracht, versie 1.25.2
In deze update zijn een hoop beveiligingslekken gedicht.
changelog: https://nlnetlabs.nl/proj.../download/#unbound-1-25-2

Voordeel van DietPi, die hebben hun eigen repo voor o.a. Unbound dus altijd up to date

[Webgnome]

@GG85 nu is het zelf compileren en installeren niet heel erg lastig. Tijdje terug mijn orangepi zo voorzien van de nieuwste versie. Werkt goed hoor

[GaMbiNo]

Ik gebruik sinds kort Renovate icm Gitea.
Renovate checkt periodiek op nieuwe versies voor mijn images, en zet een pull request met changelog in Gitea. Dan even beoordelen en mergen en dan wordt hij door een script uitgerold. En als het niet goed is revert ik de boel. Werkt wel erg fijn. 😊

Zo had ik de nieuwe Unbound ook al draaien.

[ Voor 5% gewijzigd door GaMbiNo op 26-07-2026 08:45 ]

[Gunner]

Ik block een aantal domains handmatig, waaronder html-load.com via een reg-ex deny, om hardnekkige advertenties te blokkeren. Maar de sites herkennen dat waardoor ze niet willen laden. Deze ads zijn erg vervelend dus ik zie ze liever niet.

Is er een manier om hier wat aan te doen of is dit het kat en muis spel tussen blockers en websites?
(zo'n beetje alle weer websites geven deze meldingen)

[ Voor 5% gewijzigd door Gunner op 13-08-2026 10:25 ]

[Webgnome]

Dat is een kat/muis spel. Het is natuurlijk niet heel gek dat websites dit doen omdat advertenties over het algemeen hun primaire inkomstenbron is.

[rvk]

Welke browser gebruik je hiervoor? Want als ik Brave gebruik i.c.m. pi-hole DNS, krijg ik deze melding op weerslag.nl niet. Misschien dat Brave al meerdere dingen weg filtert voordat pi-hole aan de beurt komt.

[Webgnome]

@rvk brave staat er om bekend dat het al van zichzelf heel veel zaken filtert.

[Gunner]

rvk schreef op donderdag 13 augustus 2026 @ 11:18:
Welke browser gebruik je hiervoor? Want als ik Brave gebruik i.c.m. pi-hole DNS, krijg ik deze melding op weerslag.nl niet. Misschien dat Brave al meerdere dingen weg filtert voordat pi-hole aan de beurt komt.

Gewoon Firefox (incl Ghostery als extension) met op Pi-hole in principe de oisd als blacklist met wat specifieke white/blacklist entries door mezelf gemaakt.

[ Voor 3% gewijzigd door Gunner op 13-08-2026 11:22 ]

[jant]

* jant ziet die melding ook niet (firefox / ghostery), terwijl html-load.com door de steven black list wordt geblocked.

[ThinkPad]

Firefox + uBlock Origin en geen reclame op weerslag.nl.
Ik zie html-load.com niet eens langskomen in AdGuardHome (met OISD Big lijst)