[Pi-Hole] Ervaringen & discussie

[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)

[d5stick]

TheCeet schreef op donderdag 9 juli 2026 @ 07:18:
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:
[Afbeelding]
https://x.com/The_Pi_Hole/status/2074961394869367277

Misschien een leuke tip om DoH al toe toevoegen aan PiHole:
Als je alles in containers draait, kan je deze container tussen je PiHole en je internet zetten: visibilityspots/cloudflared.

Je kan je upstream DNS servers leeg maken en dit als een Custom DNS instellen in PiHole:
127.0.0.1#5054

[Webgnome]

dan ga je dus alles via cloudflare laten lopen?

[asing]

Webgnome schreef op maandag 17 augustus 2026 @ 19:59:
dan ga je dus alles via cloudflare laten lopen?

Het is een beetje potato potato.

Unbound gebruikt de DNS servers van je provider niet, maar gaat wel over poort 53 naar buiten dus DNS verkeer is te zien door de provider.

CloudFlared gaat via HTTPS naar buiten, dus je provider heeft geen zicht op je DNS verzoeken. CloudFlare ziet ze overigens wel.

Als je dacht dat je webgebruik met CloudFlared onzichtbaar is voor je provider, think again. Iedere versleutelde verbinding met een webserver wordt vooraf gegaan door een onversleutelde verbinding met het verzoek om een verbinding met het domein op te zetten (SNI record).

Encrypted SNI via CloudFlare is wel onderweg, maar lang niet alle sites gebruiken het. Daar komt bij dat CloudFlare ook weer weer waar je heen gaat.

Met andere woorden, anoniem op internet is een utopie.

[Webgnome]

Ik heb nergens gezegd dat t mij gaat om anonimiteit. I couldn't care less. Waar t mij om gaat.is je niet afhankelijk wil zijn van Cloudflare? Mijn lokale config gebruikt unbound ivm lijstje roots. Niet dat dat perfect is. Echter geen directe afhankelijkheid van cf.

Dat half internet plat gaat als cf plat gaat.. dat is een andere discussie.

[Techno Overlord]

Ik heb sinds deze week ook een Pi Hole + Unbound + DHCP draaien op een RPi 3B. Daarnaast resolven al mijn mobiele devices via de Pi Hole door middel van Tailscale en een Tailscale subnet router op mijn headless Ubuntu server. Doet het allemaal uitstekend. Momenteel wordt ongeveer 10% geblokkeerd en dat zijn iets van 537k aan domeinen. Is dit genoeg? Ik zie soms toch nog ads in Android apps (weer app en eufy app). Ik zou die ook graag die in-app ads tegen willen houden maar ik kan niet uitvogelen hoe ik dit voor elkaar krijg. Welke lijsten kan ik daarvoor gebruiken? Of zijn dit soort ads niet tegen te houden?

[DjoeC]

Techno Overlord schreef op woensdag 19 augustus 2026 @ 16:22:
Ik heb sinds deze week ook een Pi Hole + Unbound + DHCP draaien op een RPi 3B. Daarnaast resolven al mijn mobiele devices via de Pi Hole door middel van Tailscale en een Tailscale subnet router op mijn headless Ubuntu server. Doet het allemaal uitstekend. Momenteel wordt ongeveer 10% geblokkeerd en dat zijn iets van 537k aan domeinen. Is dit genoeg? Ik zie soms toch nog ads in Android apps (weer app en eufy app). Ik zou die ook graag die in-app ads tegen willen houden maar ik kan niet uitvogelen hoe ik dit voor elkaar krijg. Welke lijsten kan ik daarvoor gebruiken? Of zijn dit soort ads niet tegen te houden?

Pihole werkt NIET voor alle inapp advertenties. Daarvoor zul je lokaal op je apparaat voorzieningen moeten treffen. Reden: Sommige apps serveren advertenties vanaf dezelfde DNS naam als hun content. En er zullen vast wel meer truukjes bestaan om toch advertenties te tonen.

Is 10% genoeg? Tja..... Ik heb 11 miljoen sites in de blok lijst en blokkeer 19% van de DNS verzoeken (let op: van de DNS verzoeken). Wat en hoeveel je blokkeert hangt o.a. samen met je gebruik, de sites die je bezoekt, etc.

De KNMI app zal niet veel hoeven te blokkeren, een commercieele versie vast veel meer. En sites met veel natuurfoto's en filmpjes - tja.....

[sweetdude]

Techno Overlord schreef op woensdag 19 augustus 2026 @ 16:22:
Ik heb sinds deze week ook een Pi Hole + Unbound + DHCP draaien op een RPi 3B. Daarnaast resolven al mijn mobiele devices via de Pi Hole door middel van Tailscale en een Tailscale subnet router op mijn headless Ubuntu server. Doet het allemaal uitstekend. Momenteel wordt ongeveer 10% geblokkeerd en dat zijn iets van 537k aan domeinen. Is dit genoeg? Ik zie soms toch nog ads in Android apps (weer app en eufy app). Ik zou die ook graag die in-app ads tegen willen houden maar ik kan niet uitvogelen hoe ik dit voor elkaar krijg. Welke lijsten kan ik daarvoor gebruiken? Of zijn dit soort ads niet tegen te houden?

Dat ligt geheel aan de manier waarop die advertenties getoond worden.
Als deze gehost worden op dezelfde servers als waar de content vandaan komt, is het niet te blokkeren. Zoals bijvoorbeeld de youtube advertenties die van dezelfde servers af komen dan het filmpje wat je aan het kijken bent.
Tweede mogelijkheid is dat deze apps een ingebouwde DNS hebben waardoor ze effectief jouw DHCP settings omzeilen. Enige optie omdat te voorkomen is om in je router (indien deze de mogelijkheid heeft) een regel te maken die verkeer op poort 53 blokkeert en terug stuurt naar je pihole. Met als uitzondering lle verkeer op poort 53 die van je pi-hole komt.
Derde mogelijkheid, deze apps halen via DOH (DNS over HTTPS) de advertentie op, waardoor deze niet als standaard DNS verkeer te zien is omdat dit effectief HTTPS verkeer is op poort 443.

Ik heb trouwens deze lijst toegevoegd:
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/pro.plus.txt

Deze komt van deze github pagina af.
https://github.com/hagezi/dns-blocklists

Hiermee ging ik van 10% naar 25% blokkade. Maar ik zie dat er veel phone home verkeer van o.a. de Ikea Homesmart en Teams geblokkeerd wordt. Maar of dit juist goed of slecht is ben ik nog aan het uitvogelen. Ik weet namelijk niet of bepaalde functionaliteit nu nog zo goed werkt.

[ Voor 16% gewijzigd door sweetdude op 19-08-2026 16:34 ]

[Get!em]

En als laatste optie: ipv6 die mogelijk je pihole bypassed die niet als DNS voor ipv6 staat.

[d5stick]

Webgnome schreef op maandag 17 augustus 2026 @ 20:42:
Ik heb nergens gezegd dat t mij gaat om anonimiteit. I couldn't care less. Waar t mij om gaat.is je niet afhankelijk wil zijn van Cloudflare? Mijn lokale config gebruikt unbound ivm lijstje roots. Niet dat dat perfect is. Echter geen directe afhankelijkheid van cf.

Dat half internet plat gaat als cf plat gaat.. dat is een andere discussie.

Als je eigen DNS servers wil instellen voor DoH kan je ook kiezen om andere containers te gebruiken bijvoorbeeld: satishweb/doh-server. Het was meer een voorbeeldje om DoH te implementeren. Zelf heb ik mijn domeinen ondergebracht bij cloudflare en door middel van tokens update ik mijn DDNS via containers + Certbot voor de bijbehorende certificaten. Ja het is een SPoF waar ik van bewust ben.

[Techno Overlord]

sweetdude schreef op woensdag 19 augustus 2026 @ 16:29:
[...]

Dat ligt geheel aan de manier waarop die advertenties getoond worden.
Als deze gehost worden op dezelfde servers als waar de content vandaan komt, is het niet te blokkeren. Zoals bijvoorbeeld de youtube advertenties die van dezelfde servers af komen dan het filmpje wat je aan het kijken bent.
Tweede mogelijkheid is dat deze apps een ingebouwde DNS hebben waardoor ze effectief jouw DHCP settings omzeilen. Enige optie omdat te voorkomen is om in je router (indien deze de mogelijkheid heeft) een regel te maken die verkeer op poort 53 blokkeert en terug stuurt naar je pihole. Met als uitzondering lle verkeer op poort 53 die van je pi-hole komt.
Derde mogelijkheid, deze apps halen via DOH (DNS over HTTPS) de advertentie op, waardoor deze niet als standaard DNS verkeer te zien is omdat dit effectief HTTPS verkeer is op poort 443.

Ik heb trouwens deze lijst toegevoegd:
https://cdn.jsdelivr.net/gh/hagezi/dns-blocklists@latest/adblock/pro.plus.txt

Deze komt van deze github pagina af.
https://github.com/hagezi/dns-blocklists

Hiermee ging ik van 10% naar 25% blokkade. Maar ik zie dat er veel phone home verkeer van o.a. de Ikea Homesmart en Teams geblokkeerd wordt. Maar of dit juist goed of slecht is ben ik nog aan het uitvogelen. Ik weet namelijk niet of bepaalde functionaliteit nu nog zo goed werkt.

Ik had idd al gelezen dat sommige grote platforms zelf de ads aanbieden van hun eigen domein ipv vanaf een content network. Maargoed wellicht dat DOH verbetering kan gaan geven straks. Ik ga mij daar eens op inlezen want ik kon het nog niet.


En over die percentages; wellicht dat het nog omhoog gaat als we weer thuis wonen want momenteel wordt de gehele onderverdeling verbouwd en verbinden onze apparaten via tailscale. Als je thuis woont is er toch veel meer verkeer dan nu. Ik ben benieuwd hoe straks al het smarthomespul samengaat met deze pi hole.

[DaRk PoIsOn]

Techno Overlord schreef op woensdag 19 augustus 2026 @ 21:02:
[...]

Ik had idd al gelezen dat sommige grote platforms zelf de ads aanbieden van hun eigen domein ipv vanaf een content network. Maargoed wellicht dat DOH verbetering kan gaan geven straks. Ik ga mij daar eens op inlezen want ik kon het nog niet.


En over die percentages; wellicht dat het nog omhoog gaat als we weer thuis wonen want momenteel wordt de gehele onderverdeling verbouwd en verbinden onze apparaten via tailscale. Als je thuis woont is er toch veel meer verkeer dan nu. Ik ben benieuwd hoe straks al het smarthomespul samengaat met deze pi hole.

Als al jullie apparaten nu al via tailscale verbinden, dan is er toch niet meer verkeer als je thuis woont?

Mijn vriendin zit thuis continue op de wifi en ik eigenlijk alleen als ik thuis ben, verder loopt alles via tailscale bij mij. Ik zie het percentage niet drastisch omhoog gaan als ik wel thuis ben.

[Techno Overlord]

DaRk PoIsOn schreef op donderdag 20 augustus 2026 @ 12:36:
[...]

Als al jullie apparaten nu al via tailscale verbinden, dan is er toch niet meer verkeer als je thuis woont?

Mijn vriendin zit thuis continue op de wifi en ik eigenlijk alleen als ik thuis ben, verder loopt alles via tailscale bij mij. Ik zie het percentage niet drastisch omhoog gaan als ik wel thuis ben.

Jawel , ik denkt het wel. Nu worden PC's niet gebruikt want die staan in de opslag. Die worden het meest gebruikt. Dan nog een LG C2 en een LG G5 tv en een AV-receiver. Daarnaast heel veel smarthomespul (verlichting, rolluikschakelaars, electrische jalozies en gordijnen en een deurbel via Wi-Fi en Zigbee) via Home Assistant wat nog niet is aangesloten. In hoeverre dat allemaal DNS requests doet kan ik nog niet zeggen. Mijn doel is om het meeste te blokkeren. VOoral van de LG TV's. Ze mogen alleen praten met Home Assistant en niet met het internet.

[ Voor 7% gewijzigd door Techno Overlord op 20-08-2026 13:57 ]

[DaRk PoIsOn]

Techno Overlord schreef op donderdag 20 augustus 2026 @ 13:56:
[...]

Jawel , ik denkt het wel. Nu worden PC's niet gebruikt want die staan in de opslag. Die worden het meest gebruikt. Dan nog een LG C2 en een LG G5 tv en een AV-receiver. Daarnaast heel veel smarthomespul (verlichting, rolluikschakelaars, electrische jalozies en gordijnen en een deurbel via Wi-Fi en Zigbee) via Home Assistant wat nog niet is aangesloten. In hoeverre dat allemaal DNS requests doet kan ik nog niet zeggen. Mijn doel is om het meeste te blokkeren. VOoral van de LG TV's. Ze mogen alleen praten met Home Assistant en niet met het internet.

Ah, op die fiets.
Zou je het smarthome spul dan niet gewoon in een aparte VLAN gooien, zodat ze op die manier alleen met HA kunnen communiceren?
Ik moet zeggen dat ik weinig Tuya verkeer of ConnectLife (koelkast, wasmachine) verkeer zie langskomen. De nest mini's babbelen veel en de iphone van mijn vriendin.

[Techno Overlord]

DaRk PoIsOn schreef op donderdag 20 augustus 2026 @ 14:04:
[...]

Ah, op die fiets.
Zou je het smarthome spul dan niet gewoon in een aparte VLAN gooien, zodat ze op die manier alleen met HA kunnen communiceren?
Ik moet zeggen dat ik weinig Tuya verkeer of ConnectLife (koelkast, wasmachine) verkeer zie langskomen. De nest mini's babbelen veel en de iphone van mijn vriendin.

Helaas ondersteunt het KPN modem geen VLANs. Ik heb ook geen pfSense draaien of een eigen router. Het smarthomespul gebruikt wel een eigen SSID maarja daar kan ik niets mee als het aankomt op routering. Smart speakers zijn van futureproofhomes en die praten sowieso niet met het internet. Maar daar vind ik wel wat op. Ik kan bijvoorbeeld wel de Parental Control functie van de KPN Box 12 gebruiken om internetverkeer te blokkeren op device basis..

[DjoeC]

Techno Overlord schreef op donderdag 20 augustus 2026 @ 13:56:
[...]
VOoral van de LG TV's. Ze mogen alleen praten met Home Assistant en niet met het internet.

Dat heb ik in mijn Fritzbox router (KPN netwerk, eigen router) geblokkeerd: De TV, de AV receiver, de ESP32's, etc. En dat wat naar buiten mag hangt bij voorkeur aan het gasten netwerk (wel Pihole, wel internet, geen onderlinge communicatie binnen het netwerk).

[ Voor 3% gewijzigd door DjoeC op 20-08-2026 14:36 ]

[Techno Overlord]

Hebben jullie nog iets van VPN draaien? Ik heb op mijn computer thuis Proton VPN draaien. Dat werkt natuurlijk niet met DNS queries sturen naar de Pi Hole. Dan moet ik, denk ik, al een wireguard installeren op de Pi Hole die unbound gebruikt om het internet op te gaan. En anders maar een ander modem/router gaan regelen als ik weer thuis woon volgende maand zodat al mijn verkeer op het modem via ProtonVPN naar buiten gaat.

[Airw0lf]

Techno Overlord schreef op donderdag 20 augustus 2026 @ 18:20:
Hebben jullie nog iets van VPN draaien? Ik heb op mijn computer thuis Proton VPN draaien. Dat werkt natuurlijk niet met DNS queries sturen naar de Pi Hole. Dan moet ik, denk ik, al een wireguard installeren op de Pi Hole die unbound gebruikt om het internet op te gaan. En anders maar een ander modem/router gaan regelen als ik weer thuis woon volgende maand zodat al mijn verkeer op het modem via ProtonVPN naar buiten gaat.

Ik heb Tailscale draaien met Pihole als "global" DNS server. In die combi wordt er gewerkt met een split DNS inchting.

Thuis maak ik gebruik van een Tailscale router voor de verbinding naar de VPS-en. Deze is in voorkomende gevallen ook de exit node voor alles buiten-de-deur.

Buiten de deur gebruik ik de Tailscale VPN voor de toegang tot eigen systemen en apps. Waarbij Pihole alle interne en externe DNS functies afhandelt. En de internet verbinding van de client de rest van de content ophaalt.

Als ik in het buitenland ben en een bepaalde site of app wil perse een NLD internet verbinding zien dan gebruik ik de exit functie. Al het internet verkeer wordt dan via de NLD verbinding afgehandeld.

[ Voor 13% gewijzigd door Airw0lf op 21-08-2026 09:32 ]

[DjoeC]

Techno Overlord schreef op donderdag 20 augustus 2026 @ 18:20:
Hebben jullie nog iets van VPN draaien? Ik heb op mijn computer thuis Proton VPN draaien. Dat werkt natuurlijk niet met DNS queries sturen naar de Pi Hole. Dan moet ik, denk ik, al een wireguard installeren op de Pi Hole die unbound gebruikt om het internet op te gaan. En anders maar een ander modem/router gaan regelen als ik weer thuis woon volgende maand zodat al mijn verkeer op het modem via ProtonVPN naar buiten gaat.

Ik gebruik alleen een wireguard van buiten naar binnen (zit in de Fritzbox) om pihole ook in te zetten op mijn mobiele meuk.

[sweetdude]

Techno Overlord schreef op donderdag 20 augustus 2026 @ 18:20:
Hebben jullie nog iets van VPN draaien? Ik heb op mijn computer thuis Proton VPN draaien. Dat werkt natuurlijk niet met DNS queries sturen naar de Pi Hole. Dan moet ik, denk ik, al een wireguard installeren op de Pi Hole die unbound gebruikt om het internet op te gaan. En anders maar een ander modem/router gaan regelen als ik weer thuis woon volgende maand zodat al mijn verkeer op het modem via ProtonVPN naar buiten gaat.

Ja ik gebruik beide opties.
Op mijn OpenWRT router draai ik wireguard server zodat ik onderweg met thuis verbonden ben.
Daarnaast op mijn vaste PC gebruik ik soms NordVPN. Deze heeft trouwens wel een optie om een custom DNS server aan te geven. Daar zou je dan je pihole kunnen ingeven.

Ik heb wel last dat er best wel wat meldingen in de logs langs komen waar ik weinig mee kan doen. Ik heb de NTP server al meerdere malen gecontroleerd en als ik

Warning in NTP client:

code:

No valid NTP replies received, check server and network connectivity

En deze sinds ik DNSSEC heb aangezet.

dnsmasq warning:

code:

negative DS reply without NS record received for latest, assuming non-DNSSEC domain-specific server

[ Voor 21% gewijzigd door sweetdude op 21-08-2026 09:32 ]

[mcmd]

In de aankomende nieuwe release van Fritz!OS (8.4) komt een pihole achtige functie beschikbaar, zie FRITZ!OS DNS filter blocks unwanted content

Ben benieuwd of dit mijn huidige PiHole kan vervangen in een docker container, het moet dan wel voldoende flexibiliteit hebben om dit voor bepaalde apparaten anders in te stellen of uit te schakelen.

[sweetdude]

@mcmd zal die Fritz functionaliteit niet meer lijken op de OpenWRT adblock dan op PiHole?

Ansich niet erg, als het werkt, werkt het. De use case en gebruikerservaring zal bepalen welke het fijnste voor iedereen werkt.

[DjoeC]

mcmd schreef op vrijdag 21 augustus 2026 @ 09:37:
In de aankomende nieuwe release van Fritz!OS (8.4) komt een pihole achtige functie beschikbaar, zie FRITZ!OS DNS filter blocks unwanted content

Ben benieuwd of dit mijn huidige PiHole kan vervangen in een docker container, het moet dan wel voldoende flexibiliteit hebben om dit voor bepaalde apparaten anders in te stellen of uit te schakelen.

Hier iets meer informatie. Het lijkt er inderdaad op dat je de pihole lists in de Fritz kunt laden (en automatisch kunt bijwerken). Misschien wat later dit weekend eens kijken (ik heb te veel projecten gaande.....) of ik de 8.4 BETA wil installeren op mijn 5590.

<aanvulling>
De beta geinstalleerd en als test de OISD.nl lijst toegevoegd. Ik verwacht geen blokkade's omdat PiHole mijn primaire DNS is, zou er een block komen dan loopt er ergens iets niet in sync..... Ook horen er weinig DNS requests in het filter te komen omdat ik naast PiHole ook Unbound draai.

Eerste indruk: Het laden van lijsten gaat vrij eenvoudig, het status overzicht blijft beperkt tot

code:

0% der DNS-Anfragen wurden seit dem Neustart Ihrer FRITZ!Box blockiert (0 von 127)

nog Duits talig in mijn Engels talige interface.

Misschien leuk om mijn lijsten achter PiHole te hangen maar het lijkt voorlopig geen waardige vervanger te zijn waarbij je snel een geblokkeerde site kunt identificeren en whitelisten.

<aanvulling 2>
Vergeet het maar.... Gaat niet werken als ze de lijst niet op extern geheugen (in mijn geval een USB stick) kunnen zetten:

FYI tag: @FRITZ!webcare

[ Voor 42% gewijzigd door DjoeC op 21-08-2026 13:31 ]