[Pi-Hole] Ervaringen & discussie

[deHakkelaar]

wimbre schreef op vrijdag 24 december 2021 @ 16:05:
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.178.234 netmask 255.255.255.0 broadcast 192.168.178.255
inet6 fe80::1f58:xx:xxx:xx prefixlen 64 scopeid 0x20<link>
ether b8:27xx:xx:xx:xx txqueuelen 1000 (Ethernet)
RX packets 5671 bytes 2204930 (2.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 217 bytes 28255 (27.5 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
[/cmd]

Disable je Wifi want dit kan problemen opleveren als je ook eht0 gebruikt in hetzelfde subnet!

EDIT: En waarschijnlijk is het de wlan interface die als DHCP client staat geconfigureerd.

[ Voor 9% gewijzigd door deHakkelaar op 24-12-2021 16:54 ]

[nero355]

sweetdude schreef op vrijdag 24 december 2021 @ 15:59:
Heeft iemand ook de sleutel om ditzelfde met OpenWRT te doen. Ik merk namelijk hetzelfde alleen met een OpenWRT router

Ga gewoon op zoek naar de juiste DNAT/SNAT regels die je via IPTables toepast :
- ed1703 in "[Pi-Hole] Ervaringen & discussie"
- ed1703 in "[Pi-Hole] Ervaringen & discussie"

Dat is gewoon DE MANIER om het te doen!

Misschien heeft @ed1703 nog wat TIPS voor je

[wimbre]

deHakkelaar schreef op vrijdag 24 december 2021 @ 16:32:
[...]

Disable je Wifi want dit kan problemen opleveren als je ook eht0 gebruikt in hetzelfde subnet!

sudo nano /boot/config.txt

Aan dit bestand "dtoverlay=pi3-disable-wifi" toegevoegd en vervolgens reboot uitgevoerd.

Als ik nu ifconfig uitvoer is "wlan0" niet meer zichtbaar.

[deHakkelaar]

@wimbre , ik had nog te laat onderstaande toegevoegd aan m'n eerdere bericht:

deHakkelaar schreef op vrijdag 24 december 2021 @ 16:32:
EDIT: En waarschijnlijk is het de wlan interface die als DHCP client staat geconfigureerd.

Heb je nog steeds die "not giving name localhost.home.wimbre.nl" berichten nu dat de wlan0 interface waarchijnlijk niet meer als DHCP client functioneert?

[wimbre]

deHakkelaar schreef op vrijdag 24 december 2021 @ 16:24:
@deHakkelaar Die van mij:

wim@Rasberry3TV:~ $ tail /etc/dhcpcd.conf
        static routers=192.168.178.1
        static domain_name_servers=1.1.1.1 1.0.0.1
interface eth0
        static ip_address=192.168.178.5
        static routers=192.168.178.1
        static domain_name_servers=1.1.1.1 1.0.0.1
interface eth0
        static ip_address=192.168.178.5/24
        static routers=192.168.178.1
        static domain_name_servers=1.1.1.1 1.0.0.1

wim@Rasberry3TV:~ $ sudo service dhcpcd restart
wim@Rasberry3TV:~ $

wim@Rasberry3TV:~ $ ip -br a
lo               UNKNOWN        127.0.0.1/8 ::1/128 
eth0           UP                      192.168.178.5/24 fe80::XXXX:XXXX:XXX:XXXX/64 
wim@Rasberry3TV:~ $

wim@Rasberry3TV:~ $ sudo journalctl -u dhcpcd | tail -20
dec 24 17:10:55 Rasberry3TV dhcpcd[1204]: sending signal TERM to pid 429
dec 24 17:10:55 Rasberry3TV dhcpcd[1204]: waiting for pid 429 to exit
dec 24 17:10:55 Rasberry3TV dhcpcd[1204]: sending signal TERM to pid 429
dec 24 17:10:55 Rasberry3TV dhcpcd[1204]: waiting for pid 429 to exit
dec 24 17:10:55 Rasberry3TV dhcpcd[429]: received SIGTERM, stopping
dec 24 17:10:55 Rasberry3TV dhcpcd[429]: eth0: removing interface
dec 24 17:10:55 Rasberry3TV dhcpcd[429]: dhcpcd exited
dec 24 17:10:55 Rasberry3TV systemd[1]: dhcpcd.service: Succeeded.
dec 24 17:10:55 Rasberry3TV systemd[1]: Stopped dhcpcd on all interfaces.
dec 24 17:10:55 Rasberry3TV systemd[1]: Starting dhcpcd on all interfaces...
dec 24 17:10:55 Rasberry3TV dhcpcd[1206]: dev: loaded udev
dec 24 17:10:55 Rasberry3TV dhcpcd[1206]: forked to background, child pid 1208
dec 24 17:10:55 Rasberry3TV systemd[1]: Started dhcpcd on all interfaces.
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: DUID 00:01:00:01:26:60:d7:5f:XX:XX:XX:XX:XX:XX
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: eth0: IAID eb:00:d7:fa
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: eth0: using static address 192.168.178.5/24
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: eth0: adding route to 192.168.178.0/24
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: eth0: adding default route via 192.168.178.1
dec 24 17:10:55 Rasberry3TV dhcpcd[1208]: eth0: soliciting an IPv6 router
dec 24 17:11:07 Rasberry3TV dhcpcd[1208]: eth0: no IPv6 Routers available
[..]

[wimbre]

deHakkelaar schreef op vrijdag 24 december 2021 @ 17:13:
@wimbre , ik had nog te laat onderstaande toegevoegd aan m'n eerdere bericht:

[...]

Heb je nog steeds die "not giving name localhost.home.wimbre.nl" berichten nu dat de wlan0 interface waarchijnlijk niet meer als DHCP client functioneert?

De laatste dateren van 16.47 uur.

Kun je dat log niet schonen zodat je van dat knipperende uitroepteken af ben en je dan kan monitoren of er nieuwe meldingen zijn?

[deHakkelaar]

wim@Rasberry3TV:~ $ tail /etc/dhcpcd.conf
        static routers=192.168.178.1
        static domain_name_servers=1.1.1.1 1.0.0.1
interface eth0
        static ip_address=192.168.178.5
        static routers=192.168.178.1
        static domain_name_servers=1.1.1.1 1.0.0.1
interface eth0

Die dubbele overbodige eth0 entries zou je weg keunnen halen/opschonen:

code:

sudo nano /etc/dhcpcd.conf

wimbre schreef op vrijdag 24 december 2021 @ 17:20:
Kun je dat log niet schonen zodat je van dat knipperende uitroepteken af ben en je dan kan monitoren of er nieuwe meldingen zijn?

Bedoel soms onderstaande?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"
Ik heb die berichten namelijk nog niet meegemaakt

[ Voor 3% gewijzigd door deHakkelaar op 24-12-2021 17:34 ]

[wimbre]

deHakkelaar schreef op vrijdag 24 december 2021 @ 17:25:
[...]

Die dubbele overbodige eth0 entries zou je weg keunnen halen/opschonen:

code:

sudo nano /etc/dhcpcd.conf

[...]

Bedoel soms onderstaande?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"
Ik heb die berichten namelijk nog niet meegemaakt

Ik heb ze verwijderd maar ik zie er toch weer verschijnen.

[deHakkelaar]

@wimbre , welke heb je verwijderd en komen weer terug?
De dubbele eth0 secties in dhcpcd.conf of de "messages" in de database?

[wimbre]

deHakkelaar schreef op vrijdag 24 december 2021 @ 17:44:
@wimbre , welke heb je verwijderd en komen weer terug?
De dubbele eth0 secties in dhcpcd.conf of de "mesages" in de database?

Sorry, ik bedoel de messages in Pi-hole diagnosis.

Maar ik had in dhcpcd.conf "#" voor die dubbele meldingen gedaan maar nu toch maar weggehaald en ook weer die meldingen uit de database verwijderd.

Daarna ff een paar kerstkaarten op de bus gedaan en..... tot nu toe geen meldingen .

Ik ga het even aankijken.

Bedankt voor al je hulp en alvast hele fijne feestdagen!

[wimbre]

wimbre schreef op vrijdag 24 december 2021 @ 18:05:
[...]

Sorry, ik bedoel de messages in Pi-hole diagnosis.

Maar ik had in dhcpcd.conf "#" voor die dubbele meldingen gedaan maar nu toch maar weggehaald en ook weer die meldingen uit de database verwijderd.

Daarna ff een paar kerstkaarten op de bus gedaan en..... tot nu toe geen meldingen .

Ik ga het even aankijken.

Helaas te vroeg gejuicht.

Vóór aanpassing van het hosts bestand luidden de meldingen:

not giving name localhost.home.wimbre.nl to the DHCP lease of 192.168.178.216 because the name exists in /etc/hosts with address 127.0.0.1
not giving name localhost.home.wimbre.nl to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.0.1

Ná aanpassingen:

not giving name localhost.home.wimbre.nl to the DHCP lease of 192.168.178.216 because the name exists in /etc/hosts with address 127.0.0.1
not giving name localhost.home.wimbre.nl to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.0.1

[deHakkelaar]

@wimbre , die .216 op het einde was toch de Samsung TV?
En wat is die .234 op het einde?
"localhost" is geen geldige hostnaam omdat deze al gereserveerd is.
Kijk ofdat je op die Samsung de hostnaam of welk ander naam kan veranderen?
Misschien ook de TV een koude boot laten doen om er zeker van te zijn dat hij z'n DHCP lease vernieuwd en tegelijk z'n hostnaam adverteerd naar de DHCP server.

EDIT: Onderstaande kan helpen door live de logs te tailen voor DHCP berichten:

code:

tail -F /var/log/pihole.log | grep dnsmasq-dhcp

Elke keer als een DHCP client verbindt met het netwerk, dan adverteren ze standaard hun eigen hostnaam.

[ Voor 24% gewijzigd door deHakkelaar op 25-12-2021 12:28 ]

[wimbre]

deHakkelaar schreef op zaterdag 25 december 2021 @ 12:20:
@wimbre , die .216 op het einde was toch de Samsung TV?

Klopt

En wat is die .234 op het einde?

IP adres van de Raspberry Pi (WLAN0). Dezelfde als waarop Pihole draait (IP adres eindigt hiervan op.5).

"localhost" is geen geldige hostnaam omdat deze al gereserveerd is.

Begrijp ik

Kijk ofdat je op die Samsung de hostnaam of welk ander naam kan veranderen?
Misschien ook de TV een koude boot laten doen om er zeker van te zijn dat hij z'n DHCP lease vernieuwd en tegelijk z'n hostnaam adverteerd naar de DHCP server.

Van wat ik heb begrepen is de naam van de TV wel via de instellingen van de TV te veranderen (heb ik ook veranderd in TV woonkamer) maar dat die localhost in het netwerk die naam vasthoudt.

EDIT: Onderstaande kan helpen door live de logs te tailen voor DHCP berichten:

code:

tail -F /var/log/pihole.log | grep dnsmasq-dhcp

Elke keer als een DHCP client verbindt met het netwerk, dan adverteren ze standaard hun eigen hostnaam.

Als ik onderstaand commando uitvoer zie ik:

Dec 25 13:03:07 dnsmasq-dhcp[569]: not giving name Rasberry3TV.home.wimbre.nl to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.1.1
Dec 25 13:03:07 dnsmasq-dhcp[569]: not giving name Rasberry3TV to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.1.1

[ Voor 12% gewijzigd door wimbre op 25-12-2021 13:10 ]

[Kapitein187]

Gister toch te veel problemen, ipv6 werkte maar had ge-update naar bullseye en plotseling aantal uur later stopte FTL er mee. De error zorgde voor flood van data.

Daarna maar opnieuw vanaf scratch bullseye er op gezet via Rapsberry pi imager. Nu geen issues vooralsnog..

Wel raar dat het niet meteen na de update kwam maar random paar uur later.

[ Voor 21% gewijzigd door Kapitein187 op 25-12-2021 19:00 ]

[deHakkelaar]

wimbre schreef op zaterdag 25 december 2021 @ 12:53:

Dec 25 13:03:07 dnsmasq-dhcp[569]: not giving name Rasberry3TV.home.wimbre.nl to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.1.1
Dec 25 13:03:07 dnsmasq-dhcp[569]: not giving name Rasberry3TV to the DHCP lease of 192.168.178.234 because the name exists in /etc/hosts with address 127.0.1.1

Het lijkt erop alsof iets nog steeds probeert een IP via DHCP te verkrijgen en daarbij de naam Rasberry3TV adverteert.
Stond er niks voor bovenstaande meldingen met een MAC adres?
Bv. zoiets:

pi@ph5a:~ $ tail -F /var/log/pihole.log | grep dnsmasq-dhcp
Dec 26 07:17:10 dnsmasq-dhcp[439]: DHCPINFORM(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx
Dec 26 07:17:10 dnsmasq-dhcp[439]: DHCPACK(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx hakpc

Bovenstaande 00:1e:0b:xx:xx:xx MAC adres kun je opzoeken:

pi@ph5a:~ $ pihole-FTL /etc/pihole/macvendor.db "SELECT vendor FROM macvendor WHERE mac LIKE '00:1e:0b'"
Hewlett Packard

Of op de makkelijke manier
https://duckduckgo.com/?t...mac+address+lookup&ia=web

Op de Pi-hole host zelf kun je de eigen MAC addressen achterhalen met onderstaande:

pi@ph5a:~ $ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             b8:27:eb:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>

EDIT: De Pi-hole web GUI geeft ook MAC adressen weer:
http://pi.hole/admin/network.php

Of de ARP/neighbor cache uitlezen voor MAC adressen die ontdekt zijn:

pi@ph5a:~ $ ip neigh
[..]
10.0.0.11 dev eth0 lladdr 00:1e:0b:xx:xx:xx REACHABLE
[..]

[ Voor 7% gewijzigd door deHakkelaar op 26-12-2021 08:13 ]

[deHakkelaar]

@Kapitein187 , geen idee wat de output van dat screenshotje produceert?

Maar de pihole-FTL binary zou niet zoveel geheugen (477MB) moeten innemen na een verse installatie.
De mijne gebruikt maar 73MB:

pi@ph5a:~ $ ps -o vsize -C pihole-FTL
   VSZ
 73212

Mogelijk heb je een DNS loop of gedeeltelijke loop gecreeerd.
Die onstaat meestal als je "Conditional Forwarding" hebt geactiveerd in Pi-hole en ook de WAN/Internet DNS instellingen op de router met het Pi-hole IP hebt geconfigureerd.
DNS verzoekjes kunnen dan in een loop geraken en snel alle resources opmaken (RAM, concurrent connections etc):

code:

Client --> Pi-hole --[CF]--> Router -
              ^                      |
              |                      |
               ----------------------

[ Voor 21% gewijzigd door deHakkelaar op 26-12-2021 08:33 . Reden: typos ]

[wimbre]

deHakkelaar schreef op zondag 26 december 2021 @ 07:37:
[...]

Het lijkt erop alsof iets nog steeds probeert een IP via DHCP te verkrijgen en daarbij de naam Rasberry3TV adverteert.
Stond er niks voor bovenstaande meldingen met een MAC adres?
Bv. zoiets:

pi@ph5a:~ $ tail -F /var/log/pihole.log | grep dnsmasq-dhcp
Dec 26 07:17:10 dnsmasq-dhcp[439]: DHCPINFORM(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx
Dec 26 07:17:10 dnsmasq-dhcp[439]: DHCPACK(eth0) 10.0.0.11 00:1e:0b:xx:xx:xx hakpc

Bovenstaande 00:1e:0b:xx:xx:xx MAC adres kun je opzoeken:

pi@ph5a:~ $ pihole-FTL /etc/pihole/macvendor.db "SELECT vendor FROM macvendor WHERE mac LIKE '00:1e:0b'"
Hewlett Packard

Of op de makkelijke manier
https://duckduckgo.com/?t...mac+address+lookup&ia=web

Op de Pi-hole host zelf kun je de eigen MAC addressen achterhalen met onderstaande:

pi@ph5a:~ $ ip -br l
lo               UNKNOWN        00:00:00:00:00:00 <LOOPBACK,UP,LOWER_UP>
eth0             UP             b8:27:eb:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>

EDIT: De Pi-hole web GUI geeft ook MAC adressen weer:
http://pi.hole/admin/network.php

Of de ARP/neighbor cache uitlezen voor MAC adressen die ontdekt zijn:

pi@ph5a:~ $ ip neigh
[..]
10.0.0.11 dev eth0 lladdr 00:1e:0b:xx:xx:xx REACHABLE
[..]

Ik had, voordat ik je bericht las, een reboot gedaan en laat nu onderstaand proces lopen:

tail -F /var/log/pihole.log | grep dnsmasq-dhcp 

Vooralsnog geeft dit nog geen foutmeldingen behalve verzoeken van andere devices maar die leiden niet tot foutmeldingen.

Ik kijk het weer even aan en koppel de resultaten later even terug.

[deHakkelaar]

@wimbre , die hoef je niet te laten lopen.
Je kunt ze opzoeken met ondertaande:

code:

grep dnsmasq-dhcp /var/log/pihole.log

EDIT: Of onderstaande en de "/" toets aanslaan om te zoeken naar dnsmasq-dhcp:

code:

less /var/log/pihole.log

Die tail -F doe je als je apparaten tijdelijk even loskoppelt van het netwerk om onmiddelijk de DHCP berichten live in de logs te volgen.

[ Voor 52% gewijzigd door deHakkelaar op 26-12-2021 09:35 ]

[Wildfire]

Hmmm, zojuist IPv6 maar weer uitgezet in mijn ASUS RT-AX88U router. IPv6 werkte prima hoor, maar in tegenstelling tot IPv6 is het (nog) niet mogelijk eigen hostnames te geven aan devices met IPv6. Ik krijg gewoon zo'n nietszeggende lange IPv6 hostname en daarmee worden de PiHole logs gigantisch vervuild, want ik weet niet welke apparaten het dan allemaal zijn.

Hopelijk komt er nog een optie in PiHole om zelf een hostname toe te kennen aan bepaalde devices. Dan worden de logs weer overzichtelijk omdat je dan kunt zien welk apparaat welke query deed.

[Raven]

Wildfire schreef op zondag 26 december 2021 @ 11:27:
Hopelijk komt er nog een optie in PiHole om zelf een hostname toe te kennen aan bepaalde devices. Dan worden de logs weer overzichtelijk omdat je dan kunt zien welk apparaat welke query deed.

Gebruik je de local DNS niet? De domeinnamen die daar staan komen bij mij in de query log voorbij, ook bij IPv6 clients mits de MAC overeenkomt met een client waarvan het IP(v4)-adres al in local DNS staat.

[Miki]

Wildfire schreef op zondag 26 december 2021 @ 11:27:
Hmmm, zojuist IPv6 maar weer uitgezet in mijn ASUS RT-AX88U router. IPv6 werkte prima hoor, maar in tegenstelling tot IPv6 is het (nog) niet mogelijk eigen hostnames te geven aan devices met IPv6. Ik krijg gewoon zo'n nietszeggende lange IPv6 hostname en daarmee worden de PiHole logs gigantisch vervuild, want ik weet niet welke apparaten het dan allemaal zijn.

Hopelijk komt er nog een optie in PiHole om zelf een hostname toe te kennen aan bepaalde devices. Dan worden de logs weer overzichtelijk omdat je dan kunt zien welk apparaat welke query deed.

Dat is normaal gedrag en een pluspunt van IPv6, een stukje extra privacy. Er zijn wel wat workarounds te vinden maar daarmee ga je het nooit 100% waterdicht krijgen ipv veranderende IPv6 adressen.

Ik zou me er niet zo druk om maken tenzij je heel specifiek bepaalde apparaten wilt uitsluiten in een groep bijvoorbeeld. Statistieken zijn leuk de eerste paar weken, daarna herken je het patroon en de trends in je grafieken en is de lol eraf.

[nero355]

Miki schreef op zondag 26 december 2021 @ 12:25:
Dat is normaal gedrag en een pluspunt van IPv6, een stukje extra privacy.

NEE : Dat noemen we netwerkvervuiling!

Er zijn wel wat workarounds te vinden maar daarmee ga je het nooit 100% waterdicht krijgen ipv veranderende IPv6 adressen.

Dan doe je iets verkeerd!

Ik zou me er niet zo druk om maken tenzij je heel specifiek bepaalde apparaten wilt uitsluiten in een groep bijvoorbeeld. Statistieken zijn leuk de eerste paar weken, daarna herken je het patroon en de trends in je grafieken en is de lol eraf.

De meeste mensen die Pi-Hole gebruiken willen juist meer controle over hun netwerk(en) vanwege al die spyware troep die tegenwoordig op Televisies/Telefoons/Tablets/enz. draait dus is het gewoon hartstikke belangrijk om te weten welk apparaat wat doet i.p.v. elke keer alles zelf bij elkaar te moeten zoeken!

Dus @Wildfire moet gewoon effe goed naar de Local DNS Records optie kijken, zoals @Raven al heeft gepost, desnoods door ze zelf te fixen via SSH als de webGUI niet meewerkt!

[Miki]

nero355 schreef op zondag 26 december 2021 @ 19:53:
[...]

NEE : Dat noemen we netwerkvervuiling!


[...]

Dan doe je iets verkeerd!


[...]

De meeste mensen die Pi-Hole gebruiken willen juist meer controle over hun netwerk(en) vanwege al die spyware troep die tegenwoordig op Televisies/Telefoons/Tablets/enz. draait dus is het gewoon hartstikke belangrijk om te weten welk apparaat wat doet i.p.v. elke keer alles zelf bij elkaar te moeten zoeken!

Dus @Wildfire moet gewoon effe goed naar de Local DNS Records optie kijken, zoals @Raven al heeft gepost, desnoods door ze zelf te fixen via SSH als de webGUI niet meewerkt!

Te makkelijk

Als je je logs goed bijhoudt in de eerste dagen bij gelijkblijvende hardware setup in huis dan weet je heel snel wat je apparaten allemaal uitspoken. Daar hoef je echt niet iedere dag voor op je schermpje te turen. Na een week weet je heel goed dat je Samsung tv op gezette tijden als je tv uit staat toch nog even naar huis belt dat alles nog okay is. Je filtert de “verdachte” patronen er echt zo uit. Daar heb ik dus Pihole niet specifiek voor nodig.

Tja en dan privacy extension (RFC4941) zo vervuilend is het ook niet als je je er niet zo druk om maakt door te veel naar je logs te kijken

En btw, Pihole local DNS records werken niet hier. Pihole lijkt niet in staat om mac-adres + IPv4 + IPv6 als 1 te zien als je ze netjes hebt getaged.

[ Voor 6% gewijzigd door Miki op 26-12-2021 21:30 ]

[nero355]

Miki schreef op zondag 26 december 2021 @ 21:07:
Te makkelijk

Eerder de waarheid!

Als je je logs goed bijhoudt in de eerste dagen bij gelijkblijvende hardware setup in huis dan weet je heel snel wat je apparaten allemaal uitspoken. Daar hoef je echt niet iedere dag voor op je schermpje te turen. Na een week weet je heel goed dat je Samsung tv op gezette tijden als je tv uit staat toch nog even naar huis belt dat alles nog okay is. Je filtert de “verdachte” patronen er echt zo uit. Daar heb ik dus Pihole niet specifiek voor nodig.

In het begin zag ik echt niet dat de Netflix app die ik niet eens gebruik (maar helaas niet kan uninstalleren) op de Nvidia Shield TV 2017 zoveel naar huis belde!

Tja en dan privacy extension (RFC4941) zo vervuilend is het ook niet als je je er niet zo druk om maakt door te veel naar je logs te kijken

Die hele hype moet gewoon DOOD!!!

En btw, Pihole local DNS records werken niet hier. Pihole lijkt niet in staat om mac-adres + IPv4 + IPv6 als 1 te zien als je ze netjes hebt getaged.

Getagged

Je maakt gewoon records aan voor ze ?!

Daarnaast is men daar juist heel erg mee bezig geweest enige maanden geleden en zou ik het vreemd vinden als dat nog steeds niet werkt...

[wimbre]

wimbre schreef op zondag 26 december 2021 @ 09:20:
[...]

Ik had, voordat ik je bericht las, een reboot gedaan en laat nu onderstaand proces lopen:

tail -F /var/log/pihole.log | grep dnsmasq-dhcp 

Vooralsnog geeft dit nog geen foutmeldingen behalve verzoeken van andere devices maar die leiden niet tot foutmeldingen.

Ik kijk het weer even aan en koppel de resultaten later even terug.

Status update:
Tot nu toe nog steeds geen meldingen in Pi-hole diagnosis.

Ik ben hoopvol

[Kapitein187]

deHakkelaar schreef op zondag 26 december 2021 @ 07:52:
@Kapitein187 , geen idee wat de output van dat screenshotje produceert?

Maar de pihole-FTL binary zou niet zoveel geheugen (477MB) moeten innemen na een verse installatie.
De mijne gebruikt maar 73MB:

pi@ph5a:~ $ ps -o vsize -C pihole-FTL
   VSZ
 73212

Mogelijk heb je een DNS loop of gedeeltelijke loop gecreeerd.
Die onstaat meestal als je "Conditional Forwarding" hebt geactiveerd in Pi-hole en ook de WAN/Internet DNS instellingen op de router met het Pi-hole IP hebt geconfigureerd.
DNS verzoekjes kunnen dan in een loop geraken en snel alle resources opmaken (RAM, concurrent connections etc):

code:

Client --> Pi-hole --[CF]--> Router -
              ^                      |
              |                      |
               ----------------------

Dit was de output bij Tail pihole-FTL.log.

Ik had en heb Conditional forwarding idd aan staan, anders heb ik geen namen van m'n devices.
Of raad je een andere setup aan, ik zou graag DHCP via mn router willen houden voor het geval mn raspberry er mee nokt..

[deHakkelaar]

wimbre schreef op maandag 27 december 2021 @ 09:07:
[...]

Status update:
Tot nu toe nog steeds geen meldingen in Pi-hole diagnosis.

Ik ben hoopvol

Ik vermoed dat voor de wlan0 interface geen statisch IP was meegegeven in dhcpcd.conf.
Als je een interface niet specifiek configureert, dan zal de dhcpcd netwerk manager default via DHCP een IP proberen te verkrijgen voor alle interfaces die dhcpcd kan detecteren.
Daarbij adverteert de host z'n eigen hostnaam Rasberry3TV.
Maar pihole-FTL accepteert deze niet omdat hij al in /etc/hosts geconfigureerd stond.
Pew...

[deHakkelaar]

Kapitein187 schreef op maandag 27 december 2021 @ 10:00:
Dit was de output bij Tail pihole-FTL.log.

Aha tuurlijk

Kapitein187 schreef op maandag 27 december 2021 @ 10:00:
Ik had en heb Conditional forwarding idd aan staan

Maar heb je ook het Pi-hole IP opgegeven in de WAN/Internet DNS veldje(s) in de router?
Dan pas wordt de (EDIT: gedeeltelijke) loop namelijk daadwerkelijk gesloten.
Lees de docs er maar op na dat je deze instelling helemaal niet hoeft aan te raken.
Als je maar het Pi-hole IP adres kunt adverteren als DNS server naar de clients via je router DHCP service instellingen:
https://docs.pi-hole.net/main/post-install/

[JB]

Voel me weer heel erg n00b maar het default password van Raspberry Pi OS Lite is toch gewoon raspberry?

Slikt 'm niet met een sudo ssh pi@raspberrypi

[deHakkelaar]

@JB , correct.
Pas op dat je CAPSLOCK niet aan staat!
En anders zou ik ook ff het wachtwoord in het "user" veldje inkloppen om te zien op scherm ofdat het juist doorkomt.

Maar waarom start je de SSH client met sudo?
Is helemaal niet nodig

EDIT: Tis gewoon een tool voor de normale gebruikers:

pi@ph5b:~ $ which ssh
/usr/bin/ssh

Tov de folder voor ondestaande die wel sudo nodig heeft:

pi@ph5b:~ $ which shutdown
/usr/sbin/shutdown

[ Voor 32% gewijzigd door deHakkelaar op 27-12-2021 12:19 ]

[JB]

deHakkelaar schreef op maandag 27 december 2021 @ 12:14:
@JB , correct.
Pas op dat je CAPSLOCK niet aan staat!
En anders zou ik ook ff het wachtwoord in het "user" veldje inkloppen om te zien op scherm ofdat het juist doorkomt.

Maar waarom start je de SSH client met sudo?
Is helemaal niet nodig

Omdat ik weinig CLI skills heb en even snel mijn gesneuvelde Pi Hole probeer te reanimeren

[deHakkelaar]

Miki schreef op zondag 26 december 2021 @ 21:07:
[...]
Tja en dan privacy extension (RFC4941)

Ben het wel ééns met @nero355.
RFC4941, "MAC Address Anonymization", DoH of DoT is leuk als je roaming bent.
Maar voor netwerk beheer thuis of zakelijk is het een ramp etterende pukkel

[Miki]

deHakkelaar schreef op maandag 27 december 2021 @ 12:40:
[...]

Ben het wel ééns met @nero355.
RFC4941, "MAC Address Anonymization", DoH of DoT is leuk als je roaming bent.
Maar voor netwerk beheer thuis of zakelijk is het een ramp etterende pukkel

Maar dat heb ik ook niet beweerd, ik ben er zelf ook niet gelukkig mee maar heb me er inmiddels bij neergelegd dat het mij niet gaat lukken om IPv6 te kunnen herleiden.

@nero355 Met mijn IPv6 > PiHole instellingen heb je me in het verleden geholpen, zie: nero355 in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"
Dus als jij betere ideeën hebt hoe ik het wel kan regelen dan verneem ik ze graag

Ps. uiteraard heb ik ook dit plaatje erbij gepakt: Coolhva in "[Ubiquiti & IPTV] Ervaringen & Discussie"

[ Voor 7% gewijzigd door Miki op 27-12-2021 13:52 ]

[JB]

Hmm nu ben ik mijn blacklists ook kwijt

Deze nog altijd hanteren?

hp-got in "[Pi-Hole] Ervaringen & discussie"

[TheCeet]

JB schreef op maandag 27 december 2021 @ 14:07:
Hmm nu ben ik mijn blacklists ook kwijt

Deze nog altijd hanteren?

hp-got in "[Pi-Hole] Ervaringen & discussie"

Er staat maar 1 standaard in fresh install van Pi-hole, dat is die van StevenBlack.

Je kan die van OISD toevoegen:
https://oisd.nl/downloads

En anders kan je op volgende site een handig overzicht terug vinden:
https://firebog.net/

[Webgnome]

JB schreef op maandag 27 december 2021 @ 14:07:
Hmm nu ben ik mijn blacklists ook kwijt

Deze nog altijd hanteren?

hp-got in "[Pi-Hole] Ervaringen & discussie"

Ik gebruik al sinds jaar en dag de lijsten die hier staan:
https://blocklistproject.github.io/Lists/

Als ook mijn eigen flubot lijst (https://raw.githubusercon...main/flubot_blocklist.txt)

[nero355]

Miki schreef op maandag 27 december 2021 @ 13:47:
@nero355 Met mijn IPv6 > PiHole instellingen heb je me in het verleden geholpen, zie: nero355 in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"
Dus als jij betere ideeën hebt hoe ik het wel kan regelen dan verneem ik ze graag

Ps. uiteraard heb ik ook dit plaatje erbij gepakt: Coolhva in "[Ubiquiti & IPTV] Ervaringen & Discussie"

Kijk eens binnen je Pi-Hole naar http://<pi-hole-ip-adres/admin/network.php en check wat je daar al kan herleiden, want volgens mij moet je daar al een heleboel dingen kunnen zien

Verder zou ik per VLAN altijd het IPv6 Link-Local adres gebruiken voor DNS Resolving dus dat adres moet je door je Router uit laten delen aan je Clients in ieder geval!

Mijn ISP deelt nog geen IPv6 uit dus ik doe daar niks mee i.c.m. Pi-Hole verder, maar IMHO moet je alles gewoon net zo goed als bij IPv4 moeten kunnen regelen met wat moeite

TheCeet schreef op maandag 27 december 2021 @ 14:12:
Er staat maar 1 standaard in fresh install van Pi-hole, dat is die van StevenBlack.

Dan zijn er een heleboel lijsten verdwenen de afgelopen jaren!

Ik heb het volgende staan :

code:

https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts    
http://sysctl.org/cameleon/hosts    
https://s3.amazonaws.com/lists.disconnect.me/simple_tracking.txt    
https://s3.amazonaws.com/lists.disconnect.me/simple_ad.txt  
https://raw.githubusercontent.com/jjtbsomhorst/pihole/main/flubot_blocklist.txt 
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1136_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1136_202107.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1642_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1642_202107.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1813_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1813_202107.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1905_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1905_202107.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1945_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_1945_202107.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_2931_202106.txt   
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_2931_202107.txt
https://github.com/NCSC-NL/flubot/raw/main/dga/flubot_v4.7_202107.txt

Kapitein187 schreef op maandag 27 december 2021 @ 10:00:
Ik had en heb Conditional forwarding idd aan staan, anders heb ik geen namen van m'n devices.
Of raad je een andere setup aan, ik zou graag DHCP via mn router willen houden voor het geval mn raspberry er mee nokt...

Zoals altijd :
- Static DHCP IP Mapping op basis van het MAC adres.
- Local DNS Records binnen Pi-Hole voor elk van die adressen.

KLAAR!!!

[Miki]

nero355 schreef op maandag 27 december 2021 @ 16:12:
[...]

Kijk eens binnen je Pi-Hole naar http://<pi-hole-ip-adres/admin/network.php en check wat je daar al kan herleiden, want volgens mij moet je daar al een heleboel dingen kunnen zien

Verder zou ik per VLAN altijd het IPv6 Link-Local adres gebruiken voor DNS Resolving dus dat adres moet je door je Router uit laten delen aan je Clients in ieder geval!

Mijn ISP deelt nog geen IPv6 uit dus ik doe daar niks mee i.c.m. Pi-Hole verder, maar IMHO moet je alles gewoon net zo goed als bij IPv4 moeten kunnen regelen met wat moeite

Onder network wordt netjes de verschillende apparaten op basis van hardware adres en bijbehorende adressen gegroepeerd. Daar is niets vreemds aan zie ook screenshot:


In bovenstaand overzicht snapt PiHole dus heel goed dat Mac adres + IPv4 en IPv6 bij elkaar horen maar dat zie je niet terug in de overzichten op het dashboard, daar wordt alleen de top 10 van IPv6 adressen getoond. Ook de query log doet niet aan braaf groeperen van hostnames terwijl Pihole dit wel goed lijkt te doen onder network

[ Voor 3% gewijzigd door Miki op 27-12-2021 18:34 ]

[nero355]

Miki schreef op maandag 27 december 2021 @ 18:13:
nder network wordt netjes de verschillende apparaten op basis van hardware adres en bijbehorende adressen gegroepeerd. Daar is niets vreemds aan zie ook screenshot:
[Afbeelding]

In bovenstaand overzicht snapt PiHole dus heel goed dat Mac adres + IPv4 en IPv6 bij elkaar horen maar dat zie je niet terug in de overzichten op het dashboard, daar wordt alleen de top 10 van IPv6 adressen getoond. Ook de query log doet niet aan braaf groeperen van hostnames terwijl Pihole dit wel goed lijkt te doen onder network

Dan heb je denk ik een bug of beperking/tekortkoming van de webGUI te pakken en zal je daar effe @ https://discourse.pi-hole.net/ een topic voor moeten aanmaken!

[deHakkelaar]

Miki schreef op maandag 27 december 2021 @ 13:47:
Maar dat heb ik ook niet beweerd, ik ben er zelf ook niet gelukkig mee maar heb me er inmiddels bij neergelegd dat het mij niet gaat lukken om IPv6 te kunnen herleiden.

Sorry, ik wou alleen aanhaken op die RFC etc.
Herleiden is lastig idd omdat IPv6 met identifiers werkt ipv MAC's:
https://datatracker.ietf.org/doc/html/rfc7217
Wikipedia: IPv6

[deHakkelaar]

nero355 schreef op maandag 27 december 2021 @ 16:12:
Zoals altijd :
- Static DHCP IP Mapping op basis van hjet MAC adres.
- Local DNS Records binnen Pi-Hole voor elk van die adressen.

Bedoel je soms IP adres reserveringen via DHCPv4 op basis van MAC adres?
Ik zie hele volksstammen allerhand reserveringen maken voor hun clients maar waarom
Als gebruiker zou je helemaal niet met IP adressen willen werken en dit hoeft ook niet.
Daarvoor heb je DNS en namen ipv IP's en dan maakt het niet uit ofdat een IP een keertje veranderd.
En zolang clients via DHCPv4 verbinden zullen ze default hun eigen naam adverteren (je kunt ook configureren dat ze dit niet doen).
Met IP's jongleren doe je eigenlijk alleen als je gaat diagnotiseren op netwerk niveau.

EDIT: Ow ik maak wel DHCPv4 reserveringen voor mijn apparaten die met een statisch IP zijn geconfigureerd (twee Pi-hole nodes en NAS).
Maar dat is alleen voor mocht er iets fout gaan en deze apparaten toch proberen via DHCP een IP te verkrijgen.
Zoals bv bij nieuw/herinstallatie etc.

Op DHCP server node a:

pi@ph5a:~ $ cat /etc/dnsmasq.d/04-pihole-static-dhcp.conf
[..]
dhcp-host=B8:27:EB:xx:xx:xx,10.0.0.4,ph5b

Op node b:

pi@ph5b:~ $ ip -br -4 a show eth0
eth0             UP             10.0.0.4/24

pi@ph5b:~ $ ip -br l show eth0
eth0             UP             b8:27:eb:xx:xx:xx <BROADCAST,MULTICAST,UP,LOWER_UP>

pi@ph5b:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
  Offered IP address: 10.0.0.4

[ Voor 34% gewijzigd door deHakkelaar op 28-12-2021 07:06 ]

[Kapitein187]

deHakkelaar schreef op maandag 27 december 2021 @ 11:58:
[...]

Aha tuurlijk

[...]

Maar heb je ook het Pi-hole IP opgegeven in de WAN/Internet DNS veldje(s) in de router?
Dan pas wordt de (EDIT: gedeeltelijke) loop namelijk daadwerkelijk gesloten.
Lees de docs er maar op na dat je deze instelling helemaal niet hoeft aan te raken.
Als je maar het Pi-hole IP adres kunt adverteren als DNS server naar de clients via je router DHCP service instellingen:
https://docs.pi-hole.net/main/post-install/

Bij WAN DNS heb ik Google & Cloudflare.[/URL]


Bij LAN DNS heb ik de Pi

[/URL]

Dus het zou goed moeten staan volgens mij.


Ander dingetje. RATE_LIMIT. Hier heb ik last van, maar als ik de config file open staat er alleen PRIVACYLEVEL=0. Als ik dan een extra regel toevoeg met RATE_LIMIT=0/0 dan tript FTL bij mij..

deHakkelaar schreef op dinsdag 28 december 2021 @ 09:49:
Uit deze post gejat:
[Afbeelding]

Die staat idd exact zo vreemde zaak.

[ Voor 44% gewijzigd door Kapitein187 op 28-12-2021 10:00 ]

[deHakkelaar]

@Kapitein187 , bovenstaande WAN DNS instellingen ism Pi-hole CF zal geen loop veroorzaken.
Wat wel een loop kan veroorzaken is het stukje "DNSFilter is enabled".
Als je in het DNSFilter niet een uitzondering hebt gemaakt voor het Pi-hole IP MAC adres, geloof "no filter" of iets dergelijks , dan kan via deze route een gedeeltelijke loop onstaan.

[deHakkelaar]

Uit deze post gejat:


EDIT: MAC adres van de Pi-hole host voor de desbetreffende interfaces kun je achterhalen met onderstaande ... als deze niet al in het lijstje op de router wordt weergegeven:

code:

ip -br l

Mogelijk moet je hoofdletters opgeven in de router voor het MAC!

[ Voor 30% gewijzigd door deHakkelaar op 28-12-2021 10:04 ]

[deHakkelaar]

Kapitein187 schreef op dinsdag 28 december 2021 @ 09:31:
Ander dingetje. RATE_LIMIT. Hier heb ik last van, maar als ik de config file open staat er alleen PRIVACYLEVEL=0. Als ik dan een extra regel toevoeg met RATE_LIMIT=0/0 dan tript FTL bij mij..
[...]
Die staat idd exact zo vreemde zaak.

Rate limiting treed inderdaad snel op als er een loop is.
Heb je toevallig ook Unbound op dezelfde host geinstalleerd?

[deHakkelaar]

pi@ph5b:~ $ man dnsmasq
[..]
       --dns-loop-detect
              Enable code to detect DNS forwarding  loops;  ie  the  situation
              where  a query sent to one of the upstream server eventually re‐
              turns as a new query to the dnsmasq instance. The process  works
              by  generating  TXT  queries  of the form <hex>.test and sending
              them to each upstream server. The hex is a UID which encodes the
              instance of dnsmasq sending the query and the upstream server to
              which it was sent. If the query returns to the server which sent
              it,  then  the upstream server through which it was sent is dis‐
              abled and this event is logged. Each time the  set  of  upstream
              servers  changes,  the  test is re-run on all of them, including
              ones which were previously disabled.

Probeer ééns onderstaande bestandje aan te maken:

code:

sudo tee /etc/dnsmasq.d/99-loop-detect.conf <<< 'dns-loop-detect'

Syntax controleren:

code:

pihole-FTL --test

Herstarten om toe te passen:

code:

sudo service pihole-FTL restart

En onderstaande om te zien ofdat er een loop is gedetecteerd:

code:

grep 'ignoring nameserver\|query loop detected' /var/log/pihole.log

Bestandje kun je weer verwijderen met onderstaandje als je deze loop controle niet meer wilt:

code:

sudo rm /etc/dnsmasq.d/99-loop-detect.conf

EDIT: De test is helaas niet waterdicht omdat alleen TXT DNS verzoekjes worden gebruikt voor het testen.

Dit is wat je krijgt te zien als je het eigen Pi-hole IP opvoerd als upstream DNS server voor Pi-hole:

pi@ph5b:~ $ grep 'ignoring nameserver\|query loop detected' /var/log/pihole.log
Dec 28 10:24:16 dnsmasq[30917]: ignoring nameserver 10.0.0.4 - local interface

En dit als een loop is gedetecteerd:

pi@ph5b:~ $ grep 'ignoring nameserver\|query loop detected' /var/log/pihole.log
Oct 22 18:17:41 dnsmasq[17301]: NOT using nameserver 10.0.0.1#53 - query loop detected

[ Voor 16% gewijzigd door deHakkelaar op 28-12-2021 20:57 ]

[Kapitein187]

deHakkelaar schreef op dinsdag 28 december 2021 @ 10:19:
[...]

Rate limiting treed inderdaad snel op als er een loop is.
Heb je toevallig ook Unbound op dezelfde host geinstalleerd?

Nee unbound gebruik ik niet meer.

code:

pi@raspberrypi:~ $ sudo tee /etc/dnsmasq.d/99-loop-detect.conf <<< 'dns-loop-detect'
dns-loop-detect
pi@raspberrypi:~ $ pihole-FTL --test
dnsmasq: syntax check OK.
pi@raspberrypi:~ $ sudo service pihole-FTL restart
pi@raspberrypi:~ $ grep 'ignoring nameserver' /var/log/pihole.log
pi@raspberrypi:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

Geen problemen.
RATE_LIMIT aanpassing lijkt nu wel te werken.

[ Voor 3% gewijzigd door Kapitein187 op 28-12-2021 10:46 ]

[deHakkelaar]

@Kapitein187 , Tja dan weet ik het ook niet waarom hij zoveel geheugen inneemt EN rate limiting wordt geactiveerd.
Mogelijk een apparaat welke Pi-hole overspoelt met verzoekjes.
Springt er niet eentje tussenuit met ontzettend veel verzoekjes?

code:

nc localhost 4711 <<< '>top-clients >quit'

Als dingen in de rats draaien, zou ik adviseren de debugger te draaien pihole -d , de logs laten uploaden naar de Pi-hole tricorder server om een token te genereren, een support case aanmaken en daar de token vermelden.

[ Voor 4% gewijzigd door deHakkelaar op 28-12-2021 10:52 ]

[nero355]

deHakkelaar schreef op dinsdag 28 december 2021 @ 05:11:
Bedoel je soms IP adres reserveringen via DHCPv4 op basis van MAC adres?

Yup!

Ik zie hele volksstammen allerhand reserveringen maken voor hun clients maar waarom

Omdat we control freaks zijn natuurlijk!

Als gebruiker zou je helemaal niet met IP adressen willen werken en dit hoeft ook niet.
Daarvoor heb je DNS en namen ipv IP's en dan maakt het niet uit ofdat een IP een keertje veranderd.
En zolang clients via DHCPv4 verbinden zullen ze default hun eigen naam adverteren (je kunt ook configureren dat ze dit niet doen).
Met IP's jongleren doe je eigenlijk alleen als je gaat diagnotiseren op netwerk niveau.

Veel plezier met de Android apparaten die hele vreemde hostnames adverteren : Zie dat maar eens te onthouden!

EDIT: Ow ik maak wel DHCPv4 reserveringen voor mijn apparaten die met een statisch IP zijn geconfigureerd (twee Pi-hole nodes en NAS).
Maar dat is alleen voor mocht er iets fout gaan en deze apparaten toch proberen via DHCP een IP te verkrijgen.
Zoals bv bij nieuw/herinstallatie etc.

Ja, dat is sowieso wel verstandig inderdaad!

[Koepert]

Vraagje, mede n.a.v. bovenstaande IP/DNS/Etc discussie.

Ik heb mn PiHole prima draaien (Vandaag Unbound toegevoegd als Recursive DNS, just to try) maar erger me aan de naamgeving/benaming van mn devices.

mijn laptop heet bijvoorbeeld 'arch.fritz.box' .. Dat komt omdat ik in de settings conditional forwarding dus AAN heb en als ' domein' fritz.box heb staan. Hoe ik kan ik dat dan het beste aanpassen zodat ik wel mijn devices in de logs kan zien als " arch"(maw herkenbare namen), maar niet de boei in de soep laat lopen of een brakke config creëer.

[DikkieDick]

Ik ontdek(te) een vreemd fenomeen.

Ik draai pihole in docker op een Raspberry Pi 4B en dat draait als een zonnetje.
Alleen als ik een inspect doe van het volume dat pihole gebruikt voor de config en data blijkt dat de created date elke minuut wijzigt. Portainer laat ook zien dat het volume dan net is aangemaakt, terwijl het 'gewoon' een tijd bestaat. Blijkt dan ook dat de _data op het volume een niewe timestamp heeft. Dat kan natuurlijk komen door de logging.

Bij bv HomeAssistant in docker zie ik dit fenomeen niet. Het volume voor de config heeft dan ook een oudere created date die ook overeen komt met de timestamp van _data . De onderliggende files hebben wel een nieuwe(re) timestamp.

Is dit known behaviour of een bug?

[deHakkelaar]

nero355 schreef op dinsdag 28 december 2021 @ 14:22:
Veel plezier met de Android apparaten die hele vreemde hostnames adverteren : Zie dat maar eens te onthouden!

Settings --> About --> Edit

[deHakkelaar]

Koepert schreef op dinsdag 28 december 2021 @ 15:53:
Hoe ik kan ik dat dan het beste aanpassen zodat ik wel mijn devices in de logs kan zien als " arch"(maw herkenbare namen), maar niet de boei in de soep laat lopen of een brakke config creëer.

Check onderstaande voor boel info:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

Koepert schreef op dinsdag 28 december 2021 @ 15:53:
Vandaag Unbound toegevoegd als Recursive DNS

Pi-OS Bullseye?
Dan zal je onderstaande moeten doen voor goed functioneren als een recursieve DNS server:
deHakkelaar in "Raspberry Pi - deel 2"

[ Voor 4% gewijzigd door deHakkelaar op 28-12-2021 18:52 ]

[nero355]

deHakkelaar schreef op dinsdag 28 december 2021 @ 18:35:
Settings --> About --> Edit

Grapjas!

Alsof dat op elke telefoon kan!

Die optie heb ik al lang geleden doorgestreept!

Koepert schreef op dinsdag 28 december 2021 @ 15:53:
Vraagje, mede n.a.v. bovenstaande IP/DNS/Etc discussie.

Daar staat dan ook gelijk je oplossing dus kijk daar gewoon effe goed naar!

Ik heb mn PiHole prima draaien (Vandaag Unbound toegevoegd als Recursive DNS, just to try) maar erger me aan de naamgeving/benaming van mn devices.

mijn laptop heet bijvoorbeeld 'arch.fritz.box' .. Dat komt omdat ik in de settings conditional forwarding dus AAN heb en als ' domein' fritz.box heb staan. Hoe ik kan ik dat dan het beste aanpassen zodat ik wel mijn devices in de logs kan zien als " arch"(maw herkenbare namen), maar niet de boei in de soep laat lopen of een brakke config creëer.

Pas ze aan waar het kan en kijk of je daarmee tevreden bent en zo niet : nero355 in "[Pi-Hole] Ervaringen & discussie"
_{Onderaan die reactie!}

[deHakkelaar]

@nero355 , ik kan de naam gewoon aanpassen op m'n Samsung telefoon, m'n Sony Experia pad en m'n oude Google Nexus pad.
EDIT: Ow en ik weet dat m'n oude stukke HTC telefoon het ook kon.

[ Voor 21% gewijzigd door deHakkelaar op 28-12-2021 19:11 ]

[nero355]

deHakkelaar schreef op dinsdag 28 december 2021 @ 19:09:
@nero355 , ik kan de naam gewoon aanpassen op m'n Samsung telefoon, m'n Sony Experia pad en m'n oude Google Nexus pad.

Dat is geweldig, maar...

Ik NIET!

Ik heb te maken met van die fantastische hostnames zoals : android-xxxxxxxxxxx

Het enige wat ik bij de meeste telefoons kon vinden was de Bluetooth hostname veranderen, maar ja... die doet dus precies alleen dat...

Maar mooi dat er ook (nieuwere ?!) apparaten zijn waarbij het wel kan!

[deHakkelaar]

@nero355 , Google Nexus 6 uit 2014.
Is dat oud genoeg?
Als je geeneens de naam van de telefoon kan veranderen, dan is het wel erg slechte prut

[Koepert]

deHakkelaar schreef op dinsdag 28 december 2021 @ 18:51:
[...]

Pi-OS Bullseye?
Dan zal je onderstaande moeten doen voor goed functioneren als een recursieve DNS server:
deHakkelaar in "Raspberry Pi - deel 2"

Proxmox VM (Debian bullseye) dus zal eens kijken.

[nero355]

deHakkelaar schreef op dinsdag 28 december 2021 @ 19:17:
Google Nexus 6 uit 2014.
Is dat oud genoeg?
Als je geeneens de naam van de telefoon kan veranderen, dan is het wel erg slechte prut

Google = Prut!
Android = Prut!

Dus dat kan er ook wel bij!

[deHakkelaar]

@Koepert , het schaadt niet om die commando's uit te voeren.
Niks zal stuk gaan.

[deHakkelaar]

nero355 schreef op dinsdag 28 december 2021 @ 19:19:
[...]

Google = Prut!
Android = Prut!

Dus dat kan er ook wel bij!

Dat is een andere discussie.

[deHakkelaar]

@Kapitein187 , ik had een foutje gemaakt in dit bericht.

Je moest zoeken naar:

code:

grep 'ignoring nameserver\|query loop detected' /var/log/pihole.log

Ipv:

code:

grep 'ignoring nameserver' /var/log/pihole.log

Inmiddels aangepast.
Je zou het nog een keertje kunnen proberen door pihole-FTL te herstarten en daarna te greppen.

[Koepert]

deHakkelaar schreef op dinsdag 28 december 2021 @ 19:19:
@Koepert , het schaadt niet om die commando's uit te voeren.
Niks zal stuk gaan.

Ik krijg bij deze een error:

code:

sudo sed -i 's\^unbound_conf=\#unbound_conf=\g' /etc/resolvconf.conf

sed: can't read /etc/resolvconf.conf: No such file or directory

(heb een lege file /etc/resolvconf.conf aangemaakt en toen de rest vd stappen doorlopen)

[ Voor 10% gewijzigd door Koepert op 28-12-2021 21:23 ]

[nero355]

@Koepert
Het is dan ook /etc/resolv.conf dus een typo!

/EDIT :
Oww... laat maar... gaat over iets anders...

deHakkelaar schreef op woensdag 29 december 2021 @ 04:28:
Ik zat zo te denken, heb je niet toevallig dit alleen ervaren met zakelijke telefoons?
Mogelijk dat via een bedrijfs policy ge-pushed wordt dat deze naam instelling niet te wijzigen valt???

NOPE.AVI

[ Voor 76% gewijzigd door nero355 op 29-12-2021 14:47 ]

[deHakkelaar]

@nero355 , is geen typo al lijkt het er wel op.
Voor de sed:

pi@ph5b:~ $ lsb_release -a
[..]
Description:    Raspbian GNU/Linux 11 (bullseye)

pi@ph5b:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Na de sed:

pi@ph5b:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

In Pi-OS Buster was deze instelling ook al aanwezig maar had geen invloed op de werking van unbound omdat het pad anders was:

pi@ph5a:~ $ lsb_release -a
[..]
Description:    Raspbian GNU/Linux 10 (buster)

pi@ph5a:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf

Voor details (credits @jpgview):
https://discourse.pi-hole...se-bullseye-unbound/51027

Koepert schreef op dinsdag 28 december 2021 @ 21:21:
heb een lege file /etc/resolvconf.conf aangemaakt

Dit hoeft niet!
Als sed een fout melding geeft dat het bestand niet bestaat, dan is dat alleen maar gunstig want dan weet je dat unbound niet als een simpele DNS forwarder wordt geconfigureerd ipv een recursieve DNS server.

[ Voor 21% gewijzigd door deHakkelaar op 29-12-2021 04:48 ]

[deHakkelaar]

nero355 schreef op dinsdag 28 december 2021 @ 18:57:
Grapjas!

Alsof dat op elke telefoon kan!

Ik zat zo te denken, heb je niet toevallig dit alleen ervaren met zakelijke telefoons?
Mogelijk dat via een bedrijfs policy ge-pushed wordt dat deze naam instelling niet te wijzigen valt???

[Koepert]

deHakkelaar schreef op woensdag 29 december 2021 @ 04:00:
@nero355 , is geen typo al lijkt het er wel op.
Voor de sed:

pi@ph5b:~ $ lsb_release -a
[..]
Description:    Raspbian GNU/Linux 11 (bullseye)

pi@ph5b:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Na de sed:

pi@ph5b:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
#unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

In Pi-OS Buster was deze instelling ook al aanwezig maar had geen invloed op de werking van unbound omdat het pad anders was:

pi@ph5a:~ $ lsb_release -a
[..]
Description:    Raspbian GNU/Linux 10 (buster)

pi@ph5a:~ $ cat /etc/resolvconf.conf
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details
[..]
unbound_conf=/var/cache/unbound/resolvconf_resolvers.conf

Voor details (credits @jpgview):
https://discourse.pi-hole...se-bullseye-unbound/51027


[...]

Dit hoeft niet!
Als sed een fout melding geeft dat het bestand niet bestaat, dan is dat alleen maar gunstig want dan weet je dat unbound niet als een simpele DNS forwarder wordt geconfigureerd ipv een recursieve DNS server.

Wat kan ik dan nu t beste doen? Zo laten of die file alsnog weggooien!?

[deHakkelaar]

@Koepert , je hebt zelf besloten dat bestandje aan te maken en dan vraag je advies ofdat hij weer verwijderd kan worden.
Wat denk je zelf?
Ik leg me neer bij elke beslissing die je maakt

Dat bestandje hoort bij de openresolv package:

pi@ph5b:~ $ dpkg -S /etc/resolvconf.conf
openresolv: /etc/resolvconf.conf

Je kunt controleren ofdat deze is geinstalleerd met onderstaande:

pi@ph5b:~ $ apt policy openresolv
openresolv:
  Installed: 3.12.0-1
[..]

Jij heb deze package waarschijnlijk niet nodig voor jouw Debian Buster Bullseye installatie!

[Koepert]

deHakkelaar schreef op woensdag 29 december 2021 @ 12:48:
@Koepert , je hebt zelf besloten dat bestandje aan te maken en dan vraag je advies ofdat hij weer verwijderd kan worden.
Wat denk je zelf?
Ik leg me neer bij elke beslissing die je maakt

Dat bestandje hoort bij de openresolv package:

pi@ph5b:~ $ dpkg -S /etc/resolvconf.conf
openresolv: /etc/resolvconf.conf

Je kunt controleren ofdat deze is geinstalleerd met onderstaande:

pi@ph5b:~ $ apt policy openresolv
openresolv:
  Installed: 3.12.0-1
[..]

Jij heb deze package waarschijnlijk niet nodig voor jouw Debian Buster installatie!

Ja ok. Maar het zou niet de eerste keer zijn dat ‘het bestaan van de file’ de dependency is en niet de inhoud.

[Eddie G.]

Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

[Bongoarnhem]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Heb je lijsten in Pi-hole die advertentie netwerken blokkeren?

[Webgnome]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Welke blocklists heb je in gebruik?

[MJV]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Is je pihole daarmee ook je enige dns-server? Als er een tweede (normale) staat ingesteld werkt het niet.

[nero355]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Hoe of waarmee test je : Welke URL en welke browser

Heb je de PC gereboot zodat je DNS Cache leeg is ?
Weet je zeker dat er niet stiekem iets van DoH/DoT verkeer actief is richting een DNS Server buiten je netwerk ?!
Niet toevallig ook via IPv6 verbonden ?
enz...
enz..
enz.

[Aramiss]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Je zou ervoor kunnen kiezen om je pihole als dhcp server te gebruiken zodat alle apparaten langs je pihole gaan.

[Eraser127]

@Eddie G. Ik had dat eerst ook, maar bij mij had ik in mijn Ziggo modem alleen DNS1 aangepast en twee gewoon leeg gelaten. Toen kreek mijn vrouw geen reclame zooi, maar ik nog wel (OnePlus 3T). Daarna DNS2 aangepast naar 192.168.255.255 (om geen andere adressen te flooden) en toen werkte het bij mij ook.

[lowfi]

Ik heb sinds kort 2 piholes. Nu heb ik een rate limit probleempje....



Boosdoener is hier de UDM-Pro die de hele boel aan het flooden is. Als ik (overal in unifi) als secondary DNS weer 1.1.1.1 doe is dit probleem weg maar dat is natuurlijk niet waarom ik 2 piholes heb

query log staat helemaal vol met dit:

code:

2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local Unknown (0) N/A 
2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local OK, sent to 10.0.10.1#53    N/A 
2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local OK, sent to 10.0.10.1#53    N/A 
2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local OK, sent to 10.0.10.1#53    N/A 
2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local OK, sent to 10.0.10.1#53    N/A 
2021-12-30 21:46:18     PTR lb._dns-sd._udp.0.10.0.10.in-addr.arpa  unifi.local OK, sent to 10.0.10.1#53    N/A

ik heb de ratelimit nu op disable staan in pihole-FTL.conf maar tis natuurlijk belachelijk wat hier gebeurt. Iemand een suggestie hoe dit op te lossen?

De UDM-Pro blijft trouwens

[ Voor 3% gewijzigd door lowfi op 30-12-2021 21:56 ]

[Webgnome]

Als ik even zoek op internet kom ik deze thread tegen: https://www.reddit.com/r/...pro_flooding_dns_servers/. Misschien heb je er wat aan?

[lowfi]

Wat ik daar lees is bv voor wan dns niet de piholes maar isp of cloudflare ingeef. Probleem dan is dat iot netwerk vlan weer vrij spel heeft of ik moet daar allerlei ingewikkelde firewall rules voor maken.

Of conditional formatting uitzetten bij pihole settings.

Morgen eens proberen

[HSG]

Ik heb sinds vandaag Pi-hole in gebruik genomen en nu al erg tevreden ermee. Wat mij wel opvalt is dat er bij een aantal IP-adressen/devices geen hostname wordt weergeven.

Iemand enig idee?

[dss58]

HSG schreef op vrijdag 31 december 2021 @ 00:24:
Ik heb sinds vandaag Pi-hole in gebruik genomen en nu al erg tevreden ermee. Wat mij wel opvalt is dat er bij een aantal IP-adressen/devices geen hostname wordt weergeven.

Iemand enig idee?

dashboard wel hoor

[Koepert]

Ik heb iets geks sinds ik pihole als recursive dns heb in gesteld. Load is de hele dag tussen 0,4 en 0,7 maar elke ochtend (nou ja 2x) zie ik dit als alert


2021-12-31
01:53:25 LOAD Long-term load (15min avg) larger than number of processors: 2.0 > 2
This may slow down DNS resolution and can cause bottlenecks.

Tijd is beide keren ruwweg gelijk, maar zie geen spike in dns queries.. dan neem ik aan dat ik t in de vm of host moet zoeken en niet pihole? Of zijn er nog zaken te controleren.

[Memphisto]

Ik heb pi-hole draaien in een docker container op een debian host. Dit draait al maanden naar tevredenheid.

Nu wilde ik eens kijken of het toevoegen van een aantal blocklists een nog beter resultaat zou geven.
Echter na het toevoegen van de lists en het runnen van pihole -g volgt onderstaande melding;

code:

[✗] DNS resolution is currently unavailable
[✗] DNS resolution is not available

Als ik hierop zoek vind ik legio usecases en is eerlijk gezegd een beetje overweldigend, echter ben ik wat terughoudend om zomaar wat te proberen en alles om zeep te helpen..
Ik begrijp niet helemaal waarom de software prima werkt, maar dit dan weer niet..

Iemand enige hulp?

[HSG]

dss58 schreef op vrijdag 31 december 2021 @ 02:12:
[...]

dashboard wel hoor

Nee daar ook niet. Alleen een ip-adres. Of zou dat komen omdat ik die apparaten een static IP heb gegeven.

[Webgnome]

Memphisto schreef op vrijdag 31 december 2021 @ 10:04:
Ik heb pi-hole draaien in een docker container op een debian host. Dit draait al maanden naar tevredenheid.

Nu wilde ik eens kijken of het toevoegen van een aantal blocklists een nog beter resultaat zou geven.
Echter na het toevoegen van de lists en het runnen van pihole -g volgt onderstaande melding;

code:

[✗] DNS resolution is currently unavailable
[✗] DNS resolution is not available

Als ik hierop zoek vind ik legio usecases en is eerlijk gezegd een beetje overweldigend, echter ben ik wat terughoudend om zomaar wat te proberen en alles om zeep te helpen..
Ik begrijp niet helemaal waarom de software prima werkt, maar dit dan weer niet..

Iemand enige hulp?

Wat zeggen de pihole en pihole ftl log?

[Eddie G.]

Ik ben een redelijke noob op netwerkgebeuren. Hoop dus dat mijn antwoorden jullie veder kunnen helpen mij te helpen.

@Bonghoarnhem en @Webgnome: Ik heb als blocklist https://dbl.oisd.nl
@MJV op mijn PC en Telefoon laat hij zien dat de Pi-hole de DNS afhandelt
@nero355 ik heb hem getest in Edge en heb voor het gemak Nu.nl als testsite gebruikt
Ik heb zowel de PC als telefoon gereboot.
Even geen idee of er DoH.DoT verkeer actief is, hoe controleer ik zoiets
Ik heb de zwarte KPN modem (Experia 12?) kan ik die z\o instellen dat hij intern alleen IP4 draait. Heeft het uberhaupt voordelen intern IP6 te draaien.

[lowfi]

lowfi schreef op donderdag 30 december 2021 @ 22:49:
Wat ik daar lees is bv voor wan dns niet de piholes maar isp of cloudflare ingeef. Probleem dan is dat iot netwerk vlan weer vrij spel heeft of ik moet daar allerlei ingewikkelde firewall rules voor maken.

Of conditional formatting uitzetten bij pihole settings.

Morgen eens proberen

Als ik de conditional formatting uitzet in de dns settings van de twee piholes dan is de error weg.

Voorheen had ik ongeveer elke seconde 5000 dns requests

[Memphisto]

Webgnome schreef op vrijdag 31 december 2021 @ 10:59:
[...]


Wat zeggen de pihole en pihole ftl log?

pihole.log onderstaande snippet en verder eigenlijk alleen het netwerkverkeer etc.

code:

Dec 31 11:07:02 dnsmasq[434]: query[A] pi.hole from 127.0.0.1
Dec 31 11:07:02 dnsmasq[434]: /etc/pihole/local.list pi.hole is 0.0.0.0
Dec 31 11:07:02 dnsmasq[434]: query[A] a.root-servers.net from 192.168.0.7
Dec 31 11:07:02 dnsmasq[434]: cached a.root-servers.net is 198.41.0.4
Dec 31 11:07:24 dnsmasq[434]: query[NS] . from 172.17.0.1
Dec 31 11:07:24 dnsmasq[434]: forwarded . to 1.0.0.1
Dec 31 11:07:24 dnsmasq[434]: forwarded . to 1.1.1.1

pihole-FTL.log

code:

[2021-12-31 09:46:18.794 434M] Resizing "FTL-strings" from 122880 to (163840 * 1) == 163840 (/dev/shm: 2.8MB used, 67.1MB total, FTL uses 2.8MB)
[2021-12-31 09:46:39.158 434M] Resizing "FTL-domains" from 73728 to (3584 * 24) == 86016 (/dev/shm: 2.9MB used, 67.1MB total, FTL uses 2.9MB)
[2021-12-31 09:50:11.086 434M] Resizing "FTL-dns-cache" from 147456 to (9472 * 16) == 151552 (/dev/shm: 2.9MB used, 67.1MB total, FTL uses 2.9MB)

[Webgnome]

Dan je de syslog moeten checken of daar iets geks in staat. Want pihole is het niet.

[Hulliee]

Koepert schreef op vrijdag 31 december 2021 @ 07:45:
Ik heb iets geks sinds ik pihole als recursive dns heb in gesteld. Load is de hele dag tussen 0,4 en 0,7 maar elke ochtend (nou ja 2x) zie ik dit als alert


2021-12-31
01:53:25 LOAD Long-term load (15min avg) larger than number of processors: 2.0 > 2
This may slow down DNS resolution and can cause bottlenecks.

Tijd is beide keren ruwweg gelijk, maar zie geen spike in dns queries.. dan neem ik aan dat ik t in de vm of host moet zoeken en niet pihole? Of zijn er nog zaken te controleren.

Op 1 van mijn pi-hole zie ik dit ook soms. Deze draait in docker op een nas. Als mijn nas erg druk is, dan krijg ik deze melding. Geen punt, alleen is die melding niet makkelijk weg te klikken..

[deHakkelaar]

lowfi schreef op vrijdag 31 december 2021 @ 11:07:
[...]

Als ik de conditional formatting uitzet in de dns settings van de twee piholes dan is de error weg.

Voorheen had ik ongeveer elke seconde 5000 dns requests

Klinkt als een gedeeltelijke DNS loop.
Volg mijn conversatie maar met @Kapitein187 :
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Als je conditional forwarding weer aktiveert, kun je kijken ofdat onderstaande wat aangeeft:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

Koepert schreef op vrijdag 31 december 2021 @ 07:45:
Ik heb iets geks sinds ik pihole als recursive dns heb in gesteld. Load is de hele dag tussen 0,4 en 0,7 maar elke ochtend (nou ja 2x) zie ik dit als alert


2021-12-31
01:53:25 LOAD Long-term load (15min avg) larger than number of processors: 2.0 > 2
This may slow down DNS resolution and can cause bottlenecks.

Tijd is beide keren ruwweg gelijk, maar zie geen spike in dns queries.. dan neem ik aan dat ik t in de vm of host moet zoeken en niet pihole? Of zijn er nog zaken te controleren.

Dan zul je moeten uitzoeken wat rond 01:53 uur zoveel load veroorzaakt.
Actuele load kun je uitlezen met het uptime commando.
En met het top commando krijg je een lijst met processen te zien en %CPU load.

[deHakkelaar]

Eddie G. schreef op donderdag 30 december 2021 @ 13:13:
Ik ben ook begonnen met een pi-hole in mijn netwerk te plaatsen. Dit om alle toestellen in mijn netwerk reclamevrij te krijgen.

Om te testen heb ik in een schone browser op mijn PC staan. Deze is zonder addblock of dergelijke. Helaas zie ik hierop geen verschil. Wat zou ik fout doen/anders moeten doen?

Ik kan in de netwerkinstellingen van mijn PC zien dat hij de Raspberry Pi ziet als DNS server.

Is Pi-hole de enige DNS server?
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[deHakkelaar]

HSG schreef op vrijdag 31 december 2021 @ 10:20:
Of zou dat komen omdat ik die apparaten een static IP heb gegeven.

deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[nero355]

Eraser127 schreef op donderdag 30 december 2021 @ 20:43:
Daarna DNS2 aangepast naar 192.168.255.255 (om geen andere adressen te flooden) en toen werkte het bij mij ook.

Je weet dat een .255 in de IPv4 wereld staat voor een Broadcast

Ik zou dat gauw veranderen naar het volgende :
- Maak een Interface IP Alias aan op je Pi-Hole installatie.
- Koppel deze aan FTLDNS/DNSmasq zodat die Interface ook voor DNS wordt gebruikt.
- Vul vervolgens het IP in als DNS2 op je Router

lowfi schreef op donderdag 30 december 2021 @ 21:49:
De UDM-Pro blijft trouwens

De UDM Pro is een verschrikkelijk apparaat vol met rare problemen die opeens opduiken dus opzich mag die ook wel weg!

Maar in dit geval is het 100% zeker weten een Admin probleem!

Koepert schreef op vrijdag 31 december 2021 @ 07:45:
Tijd is beide keren ruwweg gelijk, maar zie geen spike in dns queries.. dan neem ik aan dat ik t in de vm of host moet zoeken en niet pihole?

Lijkt me wel zo logisch!

Memphisto schreef op vrijdag 31 december 2021 @ 10:04:
Nu wilde ik eens kijken of het toevoegen van een aantal blocklists een nog beter resultaat zou geven.
Echter na het toevoegen van de lists en het runnen van pihole -g volgt onderstaande melding;

code:

[✗] DNS resolution is currently unavailable
[✗] DNS resolution is not available

Als ik hierop zoek vind ik legio usecases en is eerlijk gezegd een beetje overweldigend, echter ben ik wat terughoudend om zomaar wat te proberen en alles om zeep te helpen..
Ik begrijp niet helemaal waarom de software prima werkt, maar dit dan weer niet..

Iemand enige hulp?

Tja, haal ze één voor één weg en doe daarna een Gravity Update en kijk of het op een bepaald moment wel goed gaat

Ik zou in ieder geval daarmee beginnen!

Eddie G. schreef op vrijdag 31 december 2021 @ 11:07:
Ik heb als blocklist https://dbl.oisd.nl

Haal die eens weg, want die laat heel veel rommel toe onder het motto "Gebruiksvriendelijkheid"

op mijn PC en Telefoon laat hij zien dat de Pi-hole de DNS afhandelt

Worden de ads wel op je telefoon gefilterd

ik heb hem getest in Edge en heb voor het gemak Nu.nl als testsite gebruikt

Voor zover ik alleen op hun hoofdpagina kan zien filtert Pi-Hole bij mij alles eruit!
_{Nadat ik die idiote cookiewall voorbij ben gekomen... tering... the tracking horror!}

Even geen idee of er DoH.DoT verkeer actief is, hoe controleer ik zoiets

Ik weet niet waar die optie bij Edge zit, maar bij Firefox kan je dat heel makkelijk vinden en wordt zelfs standaard via de canary domain door Pi-Hole uitgeschakeld!

Ik heb de zwarte KPN modem (Experia 12?) kan ik die z\o instellen dat hij intern alleen IP4 draait. Heeft het uberhaupt voordelen intern IP6 te draaien.

Volgens mij was er nogal wat gedoe met bepaalde KPN Modem/Routers die geen instelling voor de Secondary DNS Server hebben en daarom dus altijd één van de DNS Servers aan de WAN kant als Secondary DNS Server aan de LAN kant uitdelen dus kijk daar effe naar!

IPv6 zal je op een moment echt nodig gaan hebben, maar laten we dat effe opzij leggen en eerst je IPv4 probleem oplossen...

[Freee!!]

nero355 schreef op vrijdag 31 december 2021 @ 15:46:
[...]
Volgens mij was er nogal wat gedoe met bepaalde KPN Modem/Routers die geen instelling voor de Secondary DNS Server hebben en daarom dus altijd één van de DNS Servers aan de WAN kant als Secondary DNS Server aan de LAN kant uitdelen dus kijk daar effe naar!

Op te lossen door ook de DHCP bij betreffende modem/router weg te halen (Pi-Hole of iets anders naar smaak).

[deHakkelaar]

nero355 schreef op vrijdag 31 december 2021 @ 15:46:
Je weet dat een .255 in de IPv4 wereld staat voor een Broadcast

Die viel me geeneens op

nero355 schreef op vrijdag 31 december 2021 @ 15:46:
Ik zou dat gauw veranderen naar het volgende :
- Maak een Interface IP Alias aan op je Pi-Hole installatie.
- Koppel deze aan FTLDNS/DNSmasq zodat die Interface ook voor DNS wordt gebruikt.
- Vul vervolgens het IP in als DNS2 op je Router

Waarom niet gewoon dat tweede en/of derde DHCP DNS IP veldje configureren met een ongebruikt IP welke nog wel binnen het subnet valt maar buiten de DHCP scope?
Mogelijk zelfs beter als de router toelaat, configureren met private IP's die buiten het toegepaste subnet vallen waarnaartoe een route onmogelijk is.
Voor de client maakt het toch geen drol uit ofdat die extra DNS IP's niet reageren.
Zolang die ééne maar antwoord.

Een Pi-hole host met twee interfaces en IP's, waarvan de één afhankelijk is van de UP status van de ander, blijft nog steeds een single point of failure.
Dus bespaar de moeite/complexiteit zou ik zeggen toch?

[Koepert]

Kan iemand me vertellen wat dit is? Staat met voorsprong in m’n blocked domains.

code:

domain=lb._dns-sd._udp.0.111.111.111.in-addr.arpa

Waarbij de 111 eigenlijk een variant op m’n ip is dus daarom alle 1tjes. M’n pihole doet geen dhcp maar conditional forwarding staat wel aan. Ik krijg alleen de ‘namen’ niet goed. Blijft .fritz.box bij veel en er komen ook veel jibberish adressen bij die op IP wel weer terug te leiden zijn maar ook hun Router ‘name’ niet meesturen.

[mrdemc]

Koepert schreef op vrijdag 31 december 2021 @ 23:01:
Kan iemand me vertellen wat dit is? Staat met voorsprong in m’n blocked domains.

code:

domain=lb._dns-sd._udp.0.111.111.111.in-addr.arpa

Waarbij de 111 eigenlijk een variant op m’n ip is dus daarom alle 1tjes. M’n pihole doet geen dhcp maar conditional forwarding staat wel aan. Ik krijg alleen de ‘namen’ niet goed. Blijft .fritz.box bij veel en er komen ook veel jibberish adressen bij die op IP wel weer terug te leiden zijn maar ook hun Router ‘name’ niet meesturen.

Zoals in dit topic ook naar voren komt:
https://discourse.pi-hole...-192-in-addr-arpa/18241/4

Heb je hoogstwaarschijnlijk een DNS loop. As je terugzoekt in dit topic is dat meerdere keren benoemd hoe je dat kan oplossen, waaronder hier: mrdemc in "[Ubiquiti-Netwerkapparatuur] Ervaringen & Discussie - Deel 4"