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