[Pi-Hole] Ervaringen & discussie

[Diedo70]

RaijRaij schreef op zondag 12 september 2021 @ 15:34:
Ik draai al een tijdje 'probleemloos' pihole op mijn raspberry pi 3. Zolang het draait is er niets aan de hand. Nu heb ik al een paar keer gehad dat als de stroom uitvalt en daarna alles weer opstart ik geen internet heb. Voor mij niet zo'n probleem maar anderen hier in huis weten het niet te herstellen.

Mijn dhcp wordt gehandeld door pihole. Dhcp in mijn router(experiabox V10) staat daarom uit. Pi heeft een statisch IP die als dns is opgegeven in mijn router. Toch moet ik na zo'n stroomuitval de dhcp van mijn router even aanzetten en die van pihole uit om internet weer op gang te krijgen. Daarna zet ik alles terug en draait het probleemloos. Iemand enig idee waar de fout in mij config zit of wat dit probleem veroorzaakt (naast de waterkoker, oven en vaatwasser gelijktijdig aanzetten ;-))

Ik heb zoiets ook al meerdere keren gehad.
Bij mij was het een network setting in de raspi-config: wait for netwerk on boot (of iets dergelijks).
Kwam er op neer dat de pi bij opstarten wachtte tot ie een IP zou krijgen, terwijl hij zelf de dhcp server was. Dan blijf je lang wachten.

[RaijRaij]

Diedo70 schreef op zondag 12 september 2021 @ 19:55:
[...]


Ik heb zoiets ook al meerdere keren gehad.
Bij mij was het een network setting in de raspi-config: wait for netwerk on boot (of iets dergelijks).
Kwam er op neer dat de pi bij opstarten wachtte tot ie een IP zou krijgen, terwijl hij zelf de dhcp server was. Dan blijf je lang wachten.

Zojuist gekeken. Kon niet zien of het uit of aan stond maar voor de zekerheid wachten op netwerk uit gezet.

[deHakkelaar]

RaijRaij schreef op zondag 12 september 2021 @ 20:06:
[...]


Zojuist gekeken. Kon niet zien of het uit of aan stond maar voor de zekerheid wachten op netwerk uit gezet.

Het lijkt erop dat die setting default enabled is OOTB voor Pi-OS (ik heb die setting nooit aangeraakt):

code:

pi@ph5b:~ $ cat /etc/systemd/system/dhcpcd.service.d/wait.conf
[Service]
ExecStart=
ExecStart=/usr/lib/dhcpcd5/dhcpcd -q -w

code:

pi@ph5b:~ $ man dhcpcd
[..]
     -w      Wait for an address to be assigned before forking to the back‐
             ground.  Does not take an argument, unlike the below option.

Volgens de source code zal bovenstaande wait.conf bestandje verwijderd worden "rm -f" zodra disabled in raspi-config.

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

[Verwijderd]

mijn excuses als dit niet de plek is om het te vragen maar ik kon nergens anders een antwoord vinden, c.dpgmedia.net ik zie laatste tijd dit domein omhoog komen als ik nieuws apps laadt, wat is dit voor domein? ads of tracking

[heeten12]

Dat weet denk ik niemand hier.

Blokkeer hem, blijft alles werken dan waarschijnlijk iets van tracking/ads etc.

Krijg je issues, dan weer van de Blacklist halen.

Edit: Je weet dat dpg media een heleboel nieuws sites en bladen in eigendom heeft? Wikipedia: DPG Media

[ Voor 32% gewijzigd door heeten12 op 12-09-2021 21:19 ]

[deHakkelaar]

verkeerd gelezen.... post deleted

[ Voor 85% gewijzigd door deHakkelaar op 12-09-2021 21:24 ]

[Rozz]

Pihole container draaien werkt ook op Ubiquiti Dream Machine Pro voor de geintresserden.
https://github.com/boostc...es/tree/master/run-pihole

sambaloedjek schreef op zondag 12 september 2021 @ 19:23:
Blijkbaar is het sinds kort ook mogelijk om Pihole direct op bepaalde Mikrotik routers te draaien als docker container:
https://help.mikrotik.com/docs/display/ROS/Container

[nero355]

Verwijderd schreef op zondag 12 september 2021 @ 21:07:
mijn excuses als dit niet de plek is om het te vragen maar ik kon nergens anders een antwoord vinden, c.dpgmedia.net ik zie laatste tijd dit domein omhoog komen als ik nieuws apps laadt, wat is dit voor domein? ads of tracking

Dat soort sub-domeinen zijn de laatste trend op het moment : Lekker onduidelijk en nikszeggend dus je weet ook niet wat je ermee aan moet en moet je dus inderdaad gaan testen...

Het zou zomaar een manier kunnen zijn om zowel de content als de ads vanaf dezelfde server in te laden, zoals de ellende die we van YouTube kennen!

[wouter1981]

Ik heb Pi-hole geïnstalleerd op een schone Raspberry Pi OS installatie. Een static IP reservering (buiten DHCP range) gemaakt in de Genexis Platinum-7840 van Caiway. Daarna lijkt Pi-hole gewoon te werken echter wanneer ik de DNS server verwijzing in de router wijzig naar het IP adres van de rpi dan krijg ik geen verbinding meer met internet. Iemand een idee?

Na verder zoeken zag ik meer problemen met lokale DNS servers in de Platinum 7840, nu de DHCP van de router uitgeschakeld en de DHCP van de pi-hole ingesteld. Dit lijkt te werken. Even aanzien.

[ Voor 23% gewijzigd door wouter1981 op 16-09-2021 15:47 ]

[nero355]

@wouter1981
Dat is best wel vaag, want bij mij doet alles het prima met dezelfde Genexis 7840

Zelfs i.c.m. een VLAN Interface van de Pi-Hole die de DNS verzorgt in een apart VLAN waar de Genexis de baas speelt!

Post eens je instellingen en de firmware versie en zo...

[PFY]

Vraagje omtrent Pi-hole op windows docker.

In de logging van de Pi-hole zie ik queries gaan naar 2 dns servers. 1 is de pi-hole en de 2e is 9.9.9.9 (Quad nine).

Maar eigenlijk wil ik alles via pi-hole laten lopen, want ik heb het idee dat nu verkeer niet volledig gebruik maakt van de pihole, maar dus ook via quad nine loopt.

Als ik alles via de pi-hole laat lopen: 127.17.0.1 werkt mijn internet niet. Dus vandaar als secondary internet DNS 9.9.9.9.

Stukje logging.....


2021-09-16 18:55:46 A www.facebook.com 172.17.0.1 OK, answered by dns9.quad9.net#53 CNAME (0.0ms)
2021-09-16 18:55:17 A nexusrules.officeapps.live.com 172.17.0.1 Blocked (gravity) IP (0.3ms)
2021-09-16 18:55:06 A qnl-play-fetch.s3.amazonaws.com 172.17.0.1 OK, answered by dns9.quad9.net#53

[Freee!!]

PFY schreef op donderdag 16 september 2021 @ 19:01:
Vraagje omtrent Pi-hole op windows docker.

In de logging van de Pi-hole zie ik queries gaan naar 2 dns servers. 1 is de pi-hole en de 2e is 9.9.9.9 (Quad nine).

Maar eigenlijk wil ik alles via pi-hole laten lopen, want ik heb het idee dat nu verkeer niet volledig gebruik maakt van de pihole, maar dus ook via quad nine loopt.

Als ik alles via de pi-hole laat lopen: 127.17.0.1 werkt mijn internet niet. Dus vandaar als secondary internet DNS 9.9.9.9.

Stukje logging.....


2021-09-16 18:55:46 A www.facebook.com 172.17.0.1 OK, answered by dns9.quad9.net#53 CNAME (0.0ms)
2021-09-16 18:55:17 A nexusrules.officeapps.live.com 172.17.0.1 Blocked (gravity) IP (0.3ms)
2021-09-16 18:55:06 A qnl-play-fetch.s3.amazonaws.com 172.17.0.1 OK, answered by dns9.quad9.net#53

Je Pi-Hole moet de enige DNS mogelijkheid zijn voor andere apparaten, maar je Pi-Hole zelf moet het dus ook ergens anders vandaan halen. Dat lijkt me in jouw geval dus Quad Nine. Je Pi-Hole naar zichzelf laten verwijzen is niet helemaal hoe het werkt.

[PFY]

Freee!! schreef op donderdag 16 september 2021 @ 19:19:
[...]

Je Pi-Hole moet de enige DNS mogelijkheid zijn voor andere apparaten, maar je Pi-Hole zelf moet het dus ook ergens anders vandaan halen. Dat lijkt me in jouw geval dus Quad Nine. Je Pi-Hole naar zichzelf laten verwijzen is niet helemaal hoe het werkt.

De Pi-hole staat op zijn eigen ip (http://127.17.0.1) en als secondary op 9.9.9.9
Maar als ik echter 1 pc ( even testen) zet op dns : 127.17.0.1 dan is er geen dns mee rmogelijk.
Als ik als secondary dns ( in windows 10) 9.9.9.9 zet dan werkt internet weer wel, maar ik weet dus niet zeker of alles nou nog wel via de pihole gaat.

[heeten12]

Ik snap je setup nog niet volledig maar er lijken wat dingen door elkaar te gaan

1. Je gebruikt hier het ip-adres voor localhost misschien niet juist. Wikipedia: localhost

Met 127.17.0.1 zeg je eigenlijk tegen een netwerkapparaat: Gebruik jezelf!

Als je dat dus invult op een andere test waar de pihole instantie niet draait op die pc dan denkt je pc dat hij zelf je DNS moet resolven wat niet lukt.

Je moet andere apparaten dus verwijzen naar het ip-adres van het apparaat waar pihole op draait. Geen ervaring met Docker hoe het dan gaat met IP-toewijzing aan docker instanties.

2. Er is verwarring over gebruik van quad9. Je pihole moet ook ergens zijn DNS info ophalen. Dat zijn de upstream servers. Hiervoor gebruik je quad9 blijkbaar

Zie je dus een querie in het querylog dan zihn dat queries die door de pihole worden gedaan en je ziet welke upstream server deze resolved.

Heb je andere netwerkapparatuur die niet via de pihole resolven dan zie je die gewoonweg niet in het query log. Dus als je op een test pc quad9 als enige DNS instelt dan zie je die queries niet meer in het log verschijnen. (tenzij je bepaalde firewall rules hebt ingesteld om die om te leiden)

[deHakkelaar]

Ter aanvulling op van @heeten12, zie hieronder het LOOPBACK vlaggetje voor de virtual netwerk interface genaamd lo met IP 127.0.0.1/8:

pi@ph5b:~ $ ip -4 address show lo
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever

Dus alles loept/lust gewoon terug:

pi@ph5b:~ $ ping -c 1 127.0.0.1
PING 127.0.0.1 (127.0.0.1) 56(84) bytes of data.
64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.389 ms

--- 127.0.0.1 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.389/0.389/0.389/0.000 ms

pi@ph5b:~ $ sudo tcpdump -ni lo icmp
[..]
13:00:04.986899 IP 127.0.0.1 > 127.0.0.1: ICMP echo request, id 21512, seq 1, length 64
13:00:04.987067 IP 127.0.0.1 > 127.0.0.1: ICMP echo reply, id 21512, seq 1, length 64

Geldt voor alle IP's in dat /8 subnet:

pi@ph5b:~ $ ping -c 1 127.255.255.254
PING 127.255.255.254 (127.255.255.254) 56(84) bytes of data.
64 bytes from 127.255.255.254: icmp_seq=1 ttl=64 time=0.390 ms

--- 127.255.255.254 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.390/0.390/0.390/0.000 ms

pi@ph5b:~ $ sudo tcpdump -ni lo icmp
[..]
13:04:16.355167 IP 127.0.0.1 > 127.255.255.254: ICMP echo request, id 21544, seq 1, length 64
13:04:16.355340 IP 127.255.255.254 > 127.0.0.1: ICMP echo reply, id 21544, seq 1, length 64

De loopback interface is veel sneller als Ethernet of WiFi, er wordt niks ge-broadcast over de andere fysieke netwerk interfaces, en is ook niet afhankelijk ofdat een kabeltje aangesloten is of niet.
Deze wordt dus voornamelijk gebruikt voor intercommunicatie tussen processen op dezelfde host en niet voor host to host communicatie.

EDIT: ow, de link tussen het 127.0.0.1 IP en de localhost naam is vastgelegd in onderstaande bestandje:

pi@ph5b:~ $ cat /etc/hosts
127.0.0.1       localhost
::1             localhost ip6-localhost ip6-loopback
[..]

[ Voor 5% gewijzigd door deHakkelaar op 17-09-2021 17:43 . Reden: ddtdtdtdtdtdddt ]

[PFY]

Inmiddels is het opgelost. Heb meerdere netwerk kaarten in de pc zitten en op de een of andere manier pakte die de verkeerde nic.
Bedankt voor het meedenken.

heeten12 schreef op vrijdag 17 september 2021 @ 07:35:
Ik snap je setup nog niet volledig maar er lijken wat dingen door elkaar te gaan

1. Je gebruikt hier het ip-adres voor localhost misschien niet juist. Wikipedia: localhost

Met 127.17.0.1 zeg je eigenlijk tegen een netwerkapparaat: Gebruik jezelf!

Als je dat dus invult op een andere test waar de pihole instantie niet draait op die pc dan denkt je pc dat hij zelf je DNS moet resolven wat niet lukt.

Je moet andere apparaten dus verwijzen naar het ip-adres van het apparaat waar pihole op draait. Geen ervaring met Docker hoe het dan gaat met IP-toewijzing aan docker instanties.

2. Er is verwarring over gebruik van quad9. Je pihole moet ook ergens zijn DNS info ophalen. Dat zijn de upstream servers. Hiervoor gebruik je quad9 blijkbaar

Zie je dus een querie in het querylog dan zihn dat queries die door de pihole worden gedaan en je ziet welke upstream server deze resolved.

Heb je andere netwerkapparatuur die niet via de pihole resolven dan zie je die gewoonweg niet in het query log. Dus als je op een test pc quad9 als enige DNS instelt dan zie je die queries niet meer in het log verschijnen. (tenzij je bepaalde firewall rules hebt ingesteld om die om te leiden)

[nero355]

PFY schreef op vrijdag 17 september 2021 @ 14:46:
Heb meerdere netwerk kaarten in de pc zitten en op de een of andere manier pakte die de verkeerde nic.

Dan is het misschien een idee om meerdere dingen na te lopen en te binden op het juiste IP adres en daarmee NIC Interface dus pak effe dit erbij : nero355 in "[Pi-Hole] Ervaringen & discussie"

[Verwijderd]

@PFY
Mooi dat het is opgelost

Gebruik je PiHole echter ook op je andere devices in jou netwerk? In dat geval zou ik adviseren om het te hosten op een zuinige server, NAS of Rapsberry Pi. Anders moet je PC 24/7 draaien, en bij elke reboot of andere euvel met je PC hebben je andere devices daar last van.

[PFY]

Verwijderd schreef op vrijdag 17 september 2021 @ 15:32:
@PFY
Mooi dat het is opgelost

Gebruik je PiHole echter ook op je andere devices in jou netwerk? In dat geval zou ik adviseren om het te hosten op een zuinige server, NAS of Rapsberry Pi. Anders moet je PC 24/7 draaien, en bij elke reboot of andere euvel met je PC hebben je andere devices daar last van.

Gebruik hem alleen op 1 pc, anders gaat de dame in huis die nogal veel online shopped waarschijnlijk issues krijgen aangezien dat nou net zo,n type is wat wel op reclames (wil) klikken.

Pc staat altijd aan, draaien wat websites en databases op. ( non critical).

[Pierre]

PFY schreef op vrijdag 17 september 2021 @ 16:15:
[...]
Anders gaat de dame in huis die nogal veel online shopped waarschijnlijk issues krijgen aangezien dat nou net zo,n type is wat wel op reclames (wil) klikken.

De wederhelft hier shopt ook graag, die heb ik duidelijk gemaakt dat ze beter moeten zoeken, die pihole draait niet voor niks
Dus die klikt nooit op advertenties.

[ Voor 4% gewijzigd door Pierre op 17-09-2021 16:31 ]

[nero355]

PFY schreef op vrijdag 17 september 2021 @ 16:15:
Gebruik hem alleen op 1 pc, anders gaat de dame in huis die nogal veel online shopped waarschijnlijk issues krijgen aangezien dat nou net zo,n type is wat wel op reclames (wil) klikken.

Die troep kan je specifiek voor haar PC/Laptop/Tablet/Telefoon gewoon Whitelisten, maar dit is uiteraard veel beter :

Pierre schreef op vrijdag 17 september 2021 @ 16:28:
De wederhelft hier shopt ook graag, die heb ik duidelijk gemaakt dat ze beter moeten zoeken, die pihole draait niet voor niks
Dus die klikt nooit op advertenties.

Fout gedrag afleren en fatsoenlijk heropvoeden!

[dss58]

Pierre schreef op vrijdag 17 september 2021 @ 16:28:
[...]

De wederhelft hier shopt ook graag, die heb ik duidelijk gemaakt dat ze beter moeten zoeken, die pihole draait niet voor niks
Dus die klikt nooit op advertenties.

sinds pihole 5 kun je groepen aanmaken dus maak er 1 voor haar, opgelost zou ik zeggen, of, haar DNS instellen op 1.1.1.1 ofzo

[Mau_Maus]

Weet iemand hoe ik een melding uit mijn 'Pi-hole diagnosis' haal? (/admin/messages.php)

Vast heel simpel, maar ik zie het niet en nu contant zo'n warning-driehoek bovenin.

Was een client die even teveel queries veroorzaakte in een minuut... niet heel schokkend.

[nero355]

Mau_Maus schreef op zaterdag 18 september 2021 @ 15:35:
Weet iemand hoe ik een melding uit mijn 'Pi-hole diagnosis' haal? (/admin/messages.php)

Vast heel simpel, maar ik zie het niet en nu contant zo'n warning-driehoek bovenin.

Was een client die even teveel queries veroorzaakte in een minuut... niet heel schokkend.

Een snelle search lijkt erop te wijzen dat die berichten vanzelf verdwijnen na een tijdje en dat er enkele dagen geleden een Feature Request is aangemaakt voor een Delete functie voor die berichten!

[Mau_Maus]

nero355 schreef op zaterdag 18 september 2021 @ 16:37:
[...]

Een snelle search lijkt erop te wijzen dat die berichten vanzelf verdwijnen na een tijdje en dat er enkele dagen geleden een Feature Request is aangemaakt voor een Delete functie voor die berichten!

Dank!

Waar gevonden eigenlijk? Ik heb toch wel even gezocht in verschillende combinaties met 'pihole', 'messages', 'diagnosis', 'delete', 'clear' etc... En kon het niet vinden.

[nero355]

Mau_Maus schreef op zaterdag 18 september 2021 @ 16:40:
Waar gevonden eigenlijk?

Via : https://duckduckgo.com/?q...e+messages+diagnoses+page
Kwam ik uit op : https://www.reddit.com/r/...sis_warning_wont_go_away/

Ik baal altijd als ik op Reddit uitkom met hun rare forum, maar soms heb je helaas geen keuze...

/EDIT :

jpgview schreef op zaterdag 18 september 2021 @ 21:31:
gebruik old reddit... https://old.reddit.com/r/pihole/

Lijkt mijn grootste ergernis weg te nemen : Continue this thread...

Thnx!

[ Voor 24% gewijzigd door nero355 op 19-09-2021 00:06 ]

[jpgview]

Mau_Maus schreef op zaterdag 18 september 2021 @ 15:35:
Weet iemand hoe ik een melding uit mijn 'Pi-hole diagnosis' haal? (/admin/messages.php)

nog een alternatief, zie mijn manual (users.telenet.be whitelisten), sectie 27/3 (browsing the FTL database). Als je de write permissions eenmaal hebt aangepast, kan je in de database records aanpassen / verwijderen via een web interface (table message).

nero355 schreef op zaterdag 18 september 2021 @ 16:44:
[...]
Ik baal altijd als ik op Reddit uitkom met hun rare forum, maar soms heb je helaas geen keuze...

gebruik old reddit... https://old.reddit.com/r/pihole/

[deHakkelaar]

Mau_Maus schreef op zaterdag 18 september 2021 @ 15:35:
Weet iemand hoe ik een melding uit mijn 'Pi-hole diagnosis' haal? (/admin/messages.php)

Vast heel simpel, maar ik zie het niet en nu contant zo'n warning-driehoek bovenin.

Was een client die even teveel queries veroorzaakte in een minuut... niet heel schokkend.

Zonder extra poespas, onderstaande laat zien welke databases er aanwezig zijn in het pihole-FTL.db bestandje:

pi@ph5b:~ $ pihole-FTL /etc/pihole/pihole-FTL.db '.database'
main: /etc/pihole/pihole-FTL.db r/o

Onderstaande geeft de tables weer voor de default geselecteerde database genaamd main:

pi@ph5b:~ $ pihole-FTL /etc/pihole/pihole-FTL.db '.tables'
aliasclient        ftl                network            queries
counters           message            network_addresses

Onderstaande hoe de colums in bovenstaande message table zijn opgebouwt:

pi@ph5b:~ $ pihole-FTL /etc/pihole/pihole-FTL.db '.schema message'
CREATE TABLE message ( id INTEGER PRIMARY KEY AUTOINCREMENT, timestamp INTEGER NOT NULL, type TEXT NOT NULL, message TEXT NOT NULL, blob1 BLOB, blob2 BLOB, blob3 BLOB, blob4 BLOB, blob5 BLOB );

Ondertstaande geeft alle rows/data weer in die message table (ik heb geen "messages" dus antwoord is leeg):

pi@ph5b:~ $ pihole-FTL /etc/pihole/pihole-FTL.db --header --column 'SELECT * FROM message'
pi@ph5b:~ $

Elke row heeft een id column dus daarop kun je DELETE op toepassen (id hieronder aanpassen naargelang resultaat van bovenstaande uitkomst):

code:

sudo -u pihole pihole-FTL /etc/pihole/pihole-FTL.db 'DELETE FROM message WHERE id=999999'

EDIT: Ow is aan te raden eerst een backup te maken:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[ Voor 4% gewijzigd door deHakkelaar op 19-09-2021 20:59 ]

[Chris12]

Hallo,

Ik heb een issue met het updaten van pihole, hij wil de FLT niet updaten:

code:

pi@raspberrypi:~ $ sudo pihole updatePihole
  [i] Checking for updates...
  [i] Pi-hole Core:     up to date
  [i] Web Interface:    up to date
  [i] FTL:              update available

  [i] FTL out of date, it will be updated by the installer.

  [✓] Root user check

        .;;,.
        .ccccc:,.
         :cccclll:.      ..,,
          :ccccclll.   ;ooodc
           'ccll:;ll .oooodc
             .;cll.;;looo:.
                 .. ','.
                .',,,,,,'.
              .',,,,,,,,,,.
            .',,,,,,,,,,,,....
          ....''',,,,,,,'.......
        .........  ....  .........
        ..........      ..........
        ..........      ..........
        .........  ....  .........
          ........,,,,,,,'......
            ....',,,,,,,,,,,,.
               .',,,,,,,,,'.
                .',,,,,,'.
                  ..'''.

  [✗] Update local cache of available packages
  Error: Unable to update package cache. Please try "sudo apt-get update"
  Unable to complete update, please contact Pi-hole Support

code:

pi@raspberrypi:~ $ pihole version
  Pi-hole version is v5.4 (Latest: v5.4)
  AdminLTE version is v5.6 (Latest: v5.6)
  FTL version is v5.8.1 (Latest: v5.9)

Ik heb ook apt-get update en apt-get upgrade gedaan:

code:

pi@raspberrypi:~ $ sudo apt-get update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Reading package lists... Done
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

apt-get upgrade:

code:

E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/systemd-sysv_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libpam-systemd_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libsystemd0_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/systemd_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/udev_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev1_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

code:

pi@raspberrypi:~ $ sudo apt-get update --fix-missing
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Reading package lists... Done
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Hoe kan ik dit verder oplossen? Zonder alles opnieuw te moeten installeren/instellen.
Ben geen expert in linux/pi-hole.

[rvk]

Chris12 schreef op maandag 20 september 2021 @ 08:54:

code:

pi@raspberrypi:~ $ sudo apt-get update --fix-missing
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Reading package lists... Done
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Hoe kan ik dit verder oplossen? Zonder alles opnieuw te moeten installeren/instellen.
Ben geen expert in linux/pi-hole.

Helpt dit?

code:

sudo apt-get update --allow-releaseinfo-change

En dan dit

code:

sudo apt-get update

[Chris12]

ja, dit werkt prima!

code:

Update Complete!
  Current Pi-hole version is v5.4
  Current AdminLTE version is v5.6
  Current FTL version is v5.9

Nu kan ik ook de apt-upgrade runnen, zonder de error meldingen.

[Chris12]

Nog een andere vraag:

Op één of andere manier werkt de site www.bol.com (of andere bol.com links naar producten niet).
Ik zie echter niets terug in de pi-hole query log wanneer ik zo'n bol.com link open of rechtstreeks naar www.bol.com in de browser ga.

Ik heb een whitelist entry gemaakt: (\.|^)bol\.com$
Echter dan werkt het nog steeds niet.

Mijn browser geeft na wat wachttijd deze melding:
Fout tijdens het verbinden met www.bol.com. PR_CONNECT_RESET_ERROR

Als ik in de pi-hole log file kijk (tail logging), dan kom ik dit wel tegen:

code:

Sep 20 10:08:47 dnsmasq[570]: query[AAAA] pro-web-proxy-vip.bol.com from 192.168.1.246
Sep 20 10:08:47 dnsmasq[570]: forwarded pro-web-proxy-vip.bol.com to 192.168.1.1
Sep 20 10:08:47 dnsmasq[570]: reply pro-web-proxy-vip.bol.com is NODATA-IPv6

Hoe dit nu verder te onderzoeken en wellicht nog wat whitelisten om bol.com en de links daarnaar toe te laten werken in de browser?

[nero355]

Chris12 schreef op maandag 20 september 2021 @ 08:54:
Ik heb een issue met het updaten van pihole, hij wil de FLT niet updaten:

code:

  [✗] Update local cache of available packages
  Error: Unable to update package cache. Please try "sudo apt-get update"
  Unable to complete update, please contact Pi-hole Support

Ik heb ook apt-get update en apt-get upgrade gedaan:

code:

pi@raspberrypi:~ $ sudo apt-get update
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Reading package lists... Done
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

apt-get upgrade:

code:

E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/systemd-sysv_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libpam-systemd_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libsystemd0_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/systemd_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/udev_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Failed to fetch http://raspbian.raspberrypi.org/raspbian/pool/main/s/systemd/libudev1_241-7~deb10u7+rpi1_armhf.deb  404  Not Found [IP: 93.93.128.193 80]
E: Unable to fetch some archives, maybe run apt-get update or try with --fix-missing?

code:

pi@raspberrypi:~ $ sudo apt-get update --fix-missing
Hit:1 http://archive.raspberrypi.org/debian buster InRelease
Get:2 http://raspbian.raspberrypi.org/raspbian buster InRelease [15.0 kB]
Reading package lists... Done
E: Repository 'http://raspbian.raspberrypi.org/raspbian buster InRelease' changed its 'Suite' value from 'stable' to 'oldstable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

Hoe kan ik dit verder oplossen? Zonder alles opnieuw te moeten installeren/instellen.
Ben geen expert in linux/pi-hole.

Er staat eigenlijk precies wat er aan de hand is : Buster is van Stable naar Old Stable gegaan, omdat de nieuwe versie uit is!

Ga ik straks waarschijnlijk ook tegenaan lopen, maar heb nog effe geen zin om te updaten vanwege het een en ander...

Je kan dus drie dingen doen :
- Updaten zoals je al hebt gedaan.
- Je sources.list aanpassen, zoals voorgesteld door de melding.
- Eerst je OS updaten naar Bullseye (geloof ik ??) en dan weer Pi-Hole updaten.

Of gewoon een verse microSDXC kaart erbij pakken en een fresh install doen, eventueel zelfs op een tweede Raspberry Pi als je die nog hebt liggen

Chris12 schreef op maandag 20 september 2021 @ 11:13:
Nog een andere vraag:

Op één of andere manier werkt de site www.bol.com (of andere bol.com links naar producten niet).
Ik zie echter niets terug in de pi-hole query log wanneer ik zo'n bol.com link open of rechtstreeks naar www.bol.com in de browser ga.

Ik heb een whitelist entry gemaakt: (\.|^)bol\.com$
Echter dan werkt het nog steeds niet.

Mijn browser geeft na wat wachttijd deze melding:
Fout tijdens het verbinden met www.bol.com. PR_CONNECT_RESET_ERROR

Als ik in de pi-hole log file kijk (tail logging), dan kom ik dit wel tegen:

code:

Sep 20 10:08:47 dnsmasq[570]: query[AAAA] pro-web-proxy-vip.bol.com from 192.168.1.246
Sep 20 10:08:47 dnsmasq[570]: forwarded pro-web-proxy-vip.bol.com to 192.168.1.1
Sep 20 10:08:47 dnsmasq[570]: reply pro-web-proxy-vip.bol.com is NODATA-IPv6

Hoe dit nu verder te onderzoeken en wellicht nog wat whitelisten om bol.com en de links daarnaar toe te laten werken in de browser?

Lijkt te komen door het gebrek aan een IPv6 verbinding

[Gunner]

nero355 schreef op maandag 20 september 2021 @ 14:49:
[...]

Er staat eigenlijk precies wat er aan de hand is : Buster is van Stable naar Old Stable gegaan, omdat de nieuwe versie uit is!

Ga ik straks waarschijnlijk ook tegenaan lopen, maar heb nog effe geen zin om te updaten vanwege het een en ander...

Ik heb nog Stretch, maar kon toch onlangs wel zonder problemen Pi-Hole updaten.

[nero355]

Gunner schreef op maandag 20 september 2021 @ 15:07:
Ik heb nog Stretch, maar kon toch onlangs wel zonder problemen Pi-Hole updaten.

Die is inderdaad nog ouder : Wikipedia: Raspberry Pi OS

En nu ben ik ook in de war...

Voor mij is het ook allemaal best wel nieuw dus misschien kan iemand anders een betere verklaring verzinnen

* nero355 is een oude verstokte FreeBSD gebruiker die gewoon alles vanaf Source compileerde bij updates/upgrades

[ Voor 12% gewijzigd door nero355 op 20-09-2021 15:13 ]

[deHakkelaar]

Chris12 schreef op maandag 20 september 2021 @ 11:13:
Nog een andere vraag:

Op één of andere manier werkt de site www.bol.com (of andere bol.com links naar producten niet).
Ik zie echter niets terug in de pi-hole query log wanneer ik zo'n bol.com link open of rechtstreeks naar www.bol.com in de browser ga.

Ik heb een whitelist entry gemaakt: (\.|^)bol\.com$
Echter dan werkt het nog steeds niet.

Mijn browser geeft na wat wachttijd deze melding:
Fout tijdens het verbinden met www.bol.com. PR_CONNECT_RESET_ERROR

Als ik in de pi-hole log file kijk (tail logging), dan kom ik dit wel tegen:

code:

Sep 20 10:08:47 dnsmasq[570]: query[AAAA] pro-web-proxy-vip.bol.com from 192.168.1.246
Sep 20 10:08:47 dnsmasq[570]: forwarded pro-web-proxy-vip.bol.com to 192.168.1.1
Sep 20 10:08:47 dnsmasq[570]: reply pro-web-proxy-vip.bol.com is NODATA-IPv6

Hoe dit nu verder te onderzoeken en wellicht nog wat whitelisten om bol.com en de links daarnaar toe te laten werken in de browser?

Als je het niet zeker kan opmaken vanuit de Pi-hole logs, disable Pi-hole blocking voor diagnose en probeer opnieuw:

code:

pihole disable

Om blocking weer aan te flippen:

code:

pihole enable

TTL voor geblokte domeinen is 2 seconde dus DNS resultaat is bijna onmiddelijk.
Maar je browser of app kan nog zaken in de cache hebben staan!

Wbt die AAAA logs, er zijn geen IPv6 AAAA records voor dat domain:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com aaaa
pi@ph5b:~ $

Wel IPv4 A records:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com a
185.14.169.119
185.14.169.125
185.14.169.113

Dus zolang je nog een IPv4 verbinding hebt met het Internet zou het moeten werken:

pi@ph5b:~ $ curl ifconfig.me
87.214.XX.XX

Die log snippet laat alleen de AAAA query zien maar waarschijnlijk zie je in diezelfde logs ook de A query voorbij komen die waarschijnlijk wel succesvol is/was?

[Church of Noise]

nero355 schreef op maandag 20 september 2021 @ 14:49:
[...]
...

Je kan dus drie dingen doen :
- Updaten zoals je al hebt gedaan.
- Je sources.list aanpassen, zoals voorgesteld door de melding.
- Eerst je OS updaten naar Bullseye (geloof ik ??) en dan weer Pi-Hole updaten.


[...]

Ik heb onlangs de source list aangepast van Buster naar Bullseye, en de updates liepen goed. (vertrekkend van een DietPi OS dat dus eigenlijk Raspberry Pi OS Lite is met wat scripts erboven via de aanpak die wordt vermeld hier in 'manual upgrade').
Nu versta ik tegelijkertijd dat Raspberry Pi OS nog niet op Bullseye draait.

Is mijn systeem nu een soort Frankenbuild?
(basis is RPI OS Lite met Debian package source?)

[deHakkelaar]

Gunner schreef op maandag 20 september 2021 @ 15:07:
[...]

Ik heb nog Stretch, maar kon toch onlangs wel zonder problemen Pi-Hole updaten.

nero355 schreef op maandag 20 september 2021 @ 15:12:
[...]
En nu ben ik ook in de war...

pi@ph5b:~ $ man apt-get
[..]
       --allow-releaseinfo-change
           Allow the update command to continue downloading data from a repository
           which changed its information of the release contained in the repository
           indicating e.g a new major release. APT will fail at the update command for
           such repositories until the change is confirmed to ensure the user is
           prepared for the change. See also apt-secure(8) for details on the concept
           and configuration.

           Specialist options (--allow-releaseinfo-change-field) exist to allow changes
           only for certain fields like origin, label, codename, suite, version and
           defaultpin. See also apt_preferences(5). Configuration Item:
           Acquire::AllowReleaseInfoChange.

Is oa ook een folder wijzigingetje in de repo waar apt van op de hoogte moet worden gesteld:
http://raspbian.raspberrypi.org/raspbian/dists/

Geen idee meer hoe dat met stretch verliep.
Ik vermoed dat dit iets nieuws is wat vroeger niet noodzakelijk was maar zeker weten doe ik niet.

[Church of Noise]

deHakkelaar schreef op maandag 20 september 2021 @ 17:52:
[...]

Als je het niet zeker kan opmaken vanuit de Pi-hole logs, disable Pi-hole blocking voor diagnose en probeer opnieuw:

code:

pihole disable

Om blocking weer aan te flippen:

code:

pihole enable

TTL voor geblokte domeinen is 2 seconde dus DNS resultaat is bijna onmiddelijk.
Maar je browser of app kan nog zaken in de cache hebben staan!

Wbt die AAAA logs, er zijn geen IPv6 AAAA records voor dat domain:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com aaaa
pi@ph5b:~ $

Wel IPv4 A records:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com a
185.14.169.119
185.14.169.125
185.14.169.113

Dus zolang je nog een IPv4 verbinding hebt met het Internet zou het moeten werken:

pi@ph5b:~ $ curl ifconfig.me
87.214.XX.XX

Die log snippet laat alleen de AAAA query zien maar waarschijnlijk zie je in diezelfde logs ook de A query voorbij komen die waarschijnlijk wel succesvol is/was?

Kan dit verband houden met de bug in dnsmasq waarover men melding maakt op Discourse?

[deHakkelaar]

@Church of Noise , ja mogelijk.
Wachten op dnsmasq release/fix.

[synoniem]

rvk schreef op maandag 20 september 2021 @ 09:43:
[...]

Helpt dit?

code:

sudo apt-get update --allow-releaseinfo-change

En dan dit

code:

sudo apt-get update

Als je sudo apt update (dus apt ipv apt-get) doet zal hij als het goed is vragen of je de gewijzigde repo accepteert en als je ja zegt kan hij daarna gewoon updaten zonder meldingen.

[deHakkelaar]

Ik heb even een nog oudere squeeze release erbij gepakt en daar komt dat --allow-releaseinfo-change argument helemaal niet voor in de man pages.

EDIT: Ow was vergeten dat ik nog een stretch systeem heb, deze maakt ook geen melding van dat argument in de man pages.

[ Voor 29% gewijzigd door deHakkelaar op 20-09-2021 19:46 ]

[Chris12]

deHakkelaar schreef op maandag 20 september 2021 @ 17:52:
[...]

Als je het niet zeker kan opmaken vanuit de Pi-hole logs, disable Pi-hole blocking voor diagnose en probeer opnieuw:

code:

pihole disable

Om blocking weer aan te flippen:

code:

pihole enable

TTL voor geblokte domeinen is 2 seconde dus DNS resultaat is bijna onmiddelijk.
Maar je browser of app kan nog zaken in de cache hebben staan!

Wbt die AAAA logs, er zijn geen IPv6 AAAA records voor dat domain:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com aaaa
pi@ph5b:~ $

Wel IPv4 A records:

pi@ph5b:~ $ dig +short @8.8.8.8 pro-web-proxy-vip.bol.com a
185.14.169.119
185.14.169.125
185.14.169.113

Dus zolang je nog een IPv4 verbinding hebt met het Internet zou het moeten werken:

pi@ph5b:~ $ curl ifconfig.me
87.214.XX.XX

Die log snippet laat alleen de AAAA query zien maar waarschijnlijk zie je in diezelfde logs ook de A query voorbij komen die waarschijnlijk wel succesvol is/was?

Na het stoppen van pi-hole (via web interface gedaan), werkt de bol.com site en andere bol.com links OK.

Hierna pi-hole blocking weer aangezet, browser cache geleegd en FF/GC browser herstart, bol.com en link werkten nog steeds ofwel het lijkt dat het nu prima werkt.
Daarna de bol.com whitelist regex verwijderd en bol.com site/links werken nog steeds (bij deze stap ook de browser cache leeg en browser herstart), ook op een ander niet eerder gebruikt device dit getest.

Ik zie nu ook weer in de query logging de bol.com items die geblocked worden, in mijn geval:

• bol.com.ssl.d1.sc.omtrdc.net (A en AAAA record)
• swa.bol.com (A record)

[deHakkelaar]

@Chris12 , ter info, alleen dat laatste domein staat op de default blocklist die komt met de Pi-hole installatie:

pi@ph5b:~ $ pihole -q bol.com.ssl.d1.sc.omtrdc.net
  [i] No results found for bol.com.ssl.d1.sc.omtrdc.net within the block lists

pi@ph5b:~ $ pihole -q swa.bol.com
 Match found in https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts:
   swa.bol.com

[Chris12]

Hallo, ik heb nog een andere vraag over de mogelijkheden van pi-hole om een Google Chromecast+TV (GCCTV) apart een DNS server te geven (om zo gemakkelijk te kunnen wisselen tussen regio's/content).

Situatie schets:
Pi-hole staat ingesteld dat de upstream DNS kijkt naar mijn router. Pi-hole is tevens ook de DHCP server.
In de router WAN settings staan de DNS servers ingesteld op 1.1.1.1 en 1.0.0.1 (cloudflare)
In de router staan de DNS filter settings dat alles gefilterd wordt behalve de RaspberryPI waar pi-hole op draait, de custom DNS setting verwijst hier naar het IP adres van pi-hole.
Verder staat de DHCP server uit op de router (DNS server1 setting daar verwijst ook naar pi-hole DNS server 2 is leeg, echter zal dit geen invloed hebben).

GCCTV heeft een vast IP toegewezen, welke hetzelfde is in zowel de router als pi-hole.
Dit IP adres gaat als enige buiten de VPN om, VPN staat ingesteld in mijn router. Dit om issues met streamingsdiensten en VPN detectie te voorkomen, met name Discovery+ werkt anders niet of maar een paar dagen.

Vraag:
Kan ik nu ergens in pi-hole het IP van de GCCTV voorzien van een eigen (anders) DNS server dan de reeds ingestelde DNS servers (1.1.1.1/1.0.0.1) ?
In de router kan ik bij de niet active DHCP setting bij manual assigned IP adressen wel een optionele DNS server opgeven.

[dennis_LU]

Chris12 schreef op vrijdag 24 september 2021 @ 11:42:
GCCTV heeft een vast IP toegewezen, welke hetzelfde is in zowel de router als pi-hole.
Dit IP adres gaat als enige buiten de VPN om, VPN staat ingesteld in mijn router. Dit om issues met streamingsdiensten en VPN detectie te voorkomen, met name Discovery+ werkt anders niet of maar een paar dagen.

Vraag:
Kan ik nu ergens in pi-hole het IP van de GCCTV voorzien van een eigen (anders) DNS server dan de reeds ingestelde DNS servers (1.1.1.1/1.0.0.1) ?
In de router kan ik bij de niet active DHCP setting bij manual assigned IP adressen wel een optionele DNS server opgeven.

Kan je niet gewoon een volledig static ip config in de GCCTV zetten?

[Chris12]

Ik las dat je dan moet gaan rommelen met ADB om rechtstreeks in de firmware van het android device (GCCTV) de dns aan te passen:
https://www.reddit.com/r/...rivate_dns_in_chromecast/

er is zover ik kan zien geen DNS setting in de GCCTV uesr interface zelf.

[Verwijderd]

Maken Google Chromecasts sowieso geen verbinding met 8.8.8.8 en 8.8.4.4, ongeacht wat in de DHCP van je router staat?

[Hann1BaL]

Verwijderd schreef op vrijdag 24 september 2021 @ 13:17:
Maken Google Chromecasts sowieso geen verbinding met 8.8.8.8 en 8.8.4.4, ongeacht wat in de DHCP van je router staat?

Dat klopt. Je zou dus op je netwerk connectiepogingen naar die IPs moeten omleiden naar je Pi-hole.

[Chris12]

Hann1BaL schreef op vrijdag 24 september 2021 @ 13:18:
[...]

Dat klopt. Je zou dus op je netwerk connectiepogingen naar die IPs moeten omleiden naar je Pi-hole.

Volgens mij heb ik mijn pi-hole zo op deze wijze ingericht.
via deze handleiding: http://users.telenet.be/MySQLplaylist/pi-hole.pdf

[nero355]

dennis_LU schreef op vrijdag 24 september 2021 @ 12:15:
Kan je niet gewoon een volledig static ip config in de GCCTV zetten?

Google apparaten zijn echt een draak qua networking dus je bent de hele tijd de omgeving aan het aanpassen i.p.v. het apparaat zelf...

Chris12 schreef op vrijdag 24 september 2021 @ 11:42:
Hallo, ik heb nog een andere vraag over de mogelijkheden van pi-hole om een Google Chromecast+TV (GCCTV) apart een DNS server te geven (om zo gemakkelijk te kunnen wisselen tussen regio's/content).

Situatie schets:
Pi-hole staat ingesteld dat de upstream DNS kijkt naar mijn router. Pi-hole is tevens ook de DHCP server.
In de router WAN settings staan de DNS servers ingesteld op 1.1.1.1 en 1.0.0.1 (cloudflare)
In de router staan de DNS filter settings dat alles gefilterd wordt behalve de RaspberryPI waar pi-hole op draait, de custom DNS setting verwijst hier naar het IP adres van pi-hole.
Verder staat de DHCP server uit op de router (DNS server1 setting daar verwijst ook naar pi-hole DNS server 2 is leeg, echter zal dit geen invloed hebben).

GCCTV heeft een vast IP toegewezen, welke hetzelfde is in zowel de router als pi-hole.
Dit IP adres gaat als enige buiten de VPN om, VPN staat ingesteld in mijn router. Dit om issues met streamingsdiensten en VPN detectie te voorkomen, met name Discovery+ werkt anders niet of maar een paar dagen.

Vraag:
Kan ik nu ergens in pi-hole het IP van de GCCTV voorzien van een eigen (anders) DNS server dan de reeds ingestelde DNS servers (1.1.1.1/1.0.0.1) ?
In de router kan ik bij de niet active DHCP setting bij manual assigned IP adressen wel een optionele DNS server opgeven.

Op voorwaarde dat je Pi-Hole voor DHCP Server speelt of je eventueel een Router hebt die DNSmasq (Wat dus FTLDNS bij Pi-hole heet) gebruikt is dat wel in een config file in elkaar te knutselen

Wat ook weleens helpt : Gewoon 2 of 4 DNS Servers opgeven in de DHCP Settings van je Router en dan wordt een eventuele eigen DNS Server bij een Google (Android) apparaat overschreven!
Dat scheelt je dan weer een paar DNAT/SNAT regeltjes op je Router

[deHakkelaar]

Chris12 schreef op vrijdag 24 september 2021 @ 11:42:
Hallo, ik heb nog een andere vraag over de mogelijkheden van pi-hole om een Google Chromecast+TV (GCCTV) apart een DNS server te geven (om zo gemakkelijk te kunnen wisselen tussen regio's/content).

Situatie schets:
Pi-hole staat ingesteld dat de upstream DNS kijkt naar mijn router. Pi-hole is tevens ook de DHCP server.
In de router WAN settings staan de DNS servers ingesteld op 1.1.1.1 en 1.0.0.1 (cloudflare)
In de router staan de DNS filter settings dat alles gefilterd wordt behalve de RaspberryPI waar pi-hole op draait, de custom DNS setting verwijst hier naar het IP adres van pi-hole.
Verder staat de DHCP server uit op de router (DNS server1 setting daar verwijst ook naar pi-hole DNS server 2 is leeg, echter zal dit geen invloed hebben).

GCCTV heeft een vast IP toegewezen, welke hetzelfde is in zowel de router als pi-hole.
Dit IP adres gaat als enige buiten de VPN om, VPN staat ingesteld in mijn router. Dit om issues met streamingsdiensten en VPN detectie te voorkomen, met name Discovery+ werkt anders niet of maar een paar dagen.

Vraag:
Kan ik nu ergens in pi-hole het IP van de GCCTV voorzien van een eigen (anders) DNS server dan de reeds ingestelde DNS servers (1.1.1.1/1.0.0.1) ?
In de router kan ik bij de niet active DHCP setting bij manual assigned IP adressen wel een optionele DNS server opgeven.

Als ik goed begrijp, is je DNS pad nu als volgt:

Client --> Pi-hole --> router --> Cloudflare

Waarom die router er tussenin?
Waarom niet gewoon direct:

Client --> Pi-hole --> Cloudflare

Als dit is vanwege de "DNS filter settings" in de router, wat doet deze dan precies?

Ja je kan andere DNS server(s) "pushen" naar individuele clients via DHCP door deze clients te "taggen" op basis van MAC adres:

pi@ph5a:~ $ man dnsmasq
[..]
              The  set:<tag>  construct sets the tag whenever this --dhcp-host di‐
              rective is in use.

Als voorbeeldje, m'n laptop client met huidige DNS servers (2X Pi-hole IP):

dehakkelaar@laptop:~$ nmcli
[..]
DNS configuration:
        servers: 10.0.0.2 10.0.0.4

MAC van de laptop wlan0 interface:

dehakkelaar@laptop:~$ ip -br link show wlan0
wlan0            UP             00:1f:3c:XX:XX:XX <BROADCAST,MULTICAST,UP,LOWER_UP>

EDIT: MAC valt mogelijk ook hier te achterhalen.

Extra config bestandje aanmaken op Pi-hole voor "taggen" en DHCP DNS optie.
Heb de tag maar genoemd googledns EDIT:en let op, het MAC is in hoofdletters:

pi@ph5a:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
dhcp-host=00:1F:3C:XX:XX:XX,set:googledns
dhcp-option=tag:googledns,option:dns-server,8.8.8.8,8.8.4.4

pi@ph5a:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

pi@ph5a:~ $ sudo service pihole-FTL reload
pi@ph5a:~ $

Laptop client DHCP lease vernieuwen:

dehakkelaar@laptop:~$ sudo nmcli device disconnect wlan0; sudo nmcli device connect wlan0
Device 'wlan0' successfully disconnected.
Device 'wlan0' successfully activated

En voila:

dehakkelaar@laptop:~$ nmcli
[..]
DNS configuration:
        servers: 8.8.8.8 8.8.4.4

Andere clients krijgen nog Pi-hole voor hun kiezen voor DNS:

pi@ph5a:~ $ pihole-FTL dhcp-discover
Scanning all your interfaces for DHCP servers
[..]
   dns-server: 10.0.0.2
   dns-server: 10.0.0.4
[..]

[SpiriTNL]

Wil mijn ervaring even delen met overstap van Chrome naar Brave

In Chrome kreeg ik de laatste tijd meer en meer reclames te zien.
Blijkbaar pakt chrome heel snel zijn eigen DNS als er iets niet goed gaat of te lang duurt.
Mijn Pi-hole draait op mijn NAS en werkt naar behoren.

Nu heb ik Brave Browser geïnstalleerd en alles overgezet en alle reclames zijn verdwenen.
Brave is op chrome gebaseerd maar werkt in mijn situatie nu 100%.

[deHakkelaar]

@SpiriTNL , welke OS en Chrome versie?
Wat is het merk/model als het een smart apparaat betreft?
Heb je een voorbeeld linkje?
Staat DoH wel uit in Chrome?
Kun je je ervaring bevestigen met een tcpdump?
Of in de firewall logs als je die hebt?
Mogelijk IPv6 actief/enabled in je router waardoor Pi-hole omzeilt kan worden?

Ik heb drie Android apparaten met Chrome, een Samsung, een Sony en een Google Nexus.
Plus nog een M$ PC met Chrome als backup browser.
Alle vier werken naar behoren.

Mocht het om een Android apparaten gaan, dan adviseer ik om de "Network Info" app te installeren en de WiFi tab te controleren ofdat Pi-hole het enige DNS IP is.

[jaspervd]

Vandaag een raspberrypi ontvangen en pi hole erop gezet, na installatie lijkt alles goed te werken en kan ik het admin dashboard bezoeken.

Nu wil ik de pi hole zo instellen zodat al het internet verkeer binnen mijn netwerk (laptops, telefoons, desktop) automatisch via de pi hole verloopt, ik heb hiervoor de volgende stappen doorlopen, maar krijg het niet werkend

1. op mijn ziggo modem (technicolor) de pi hole een vast ip adres gegeven (192.168.178.26)
2. inloggen op mijn ziggo modem en DHCP server daar uitzetten (hierbij ook geprobeert bij IPv4 DNS servers het ip adres van mijn pi-hole in te vullen, dit maakte geen verschil)
3. inloggen op mijn pi-hole en DHCP server daar aanzetten, hierbij vul ik de ip range zoals in mijn router stonden in en geef ik als router gateway het ip adres van mijn ziggo modem op.
4. alles herstarten (modem, pihole, computer + dns flushen).

Nu zou het toch moeten werken en het verkeer via mijn pihole moeten lopen?

Echter wanneer ik dit doe:
1. mijn telefoon kan geen verbinding meer maken met het wifi netwerk (krijgt geen ip)
2. het pi-hole admin dashboard is niet meer bereikbaar via het ip adres
3. reclame etc is nog steeds zichtbaar op mijn computer

Kortom, het lijkt niet te werken.

Iemand een idee wat ik fout doe / hoe het wel moet? Ik heb deze thread en het ziggo forum al lopen doorspitten maar ik kom er zelf niet uit

[ Voor 4% gewijzigd door jaspervd op 25-09-2021 22:07 ]

[Pierre]

Je zal in het modem van Ziggo het ip adres van je PiHole als DNS moeten invullen. Hier staat mijn CB in bridge en daar achter hangt mijn eigen router. En die gebruikt als DNS de PiHole.

[Freee!!]

jaspervd schreef op zaterdag 25 september 2021 @ 22:06:
Vandaag een raspberrypi ontvangen en pi hole erop gezet, na installatie lijkt alles goed te werken en kan ik het admin dashboard bezoeken.

Nu wil ik de pi hole zo instellen zodat al het internet verkeer binnen mijn netwerk (laptops, telefoons, desktop) automatisch via de pi hole verloopt, ik heb hiervoor de volgende stappen doorlopen, maar krijg het niet werkend

1. op mijn ziggo modem (technicolor) de pi hole een vast ip adres gegeven (192.168.178.26)
2. inloggen op mijn ziggo modem en DHCP server daar uitzetten (hierbij ook geprobeert bij IPv4 DNS servers het ip adres van mijn pi-hole in te vullen, dit maakte geen verschil)
3. inloggen op mijn pi-hole en DHCP server daar aanzetten, hierbij vul ik de ip range zoals in mijn router stonden in en geef ik als router gateway het ip adres van mijn ziggo modem op.
4. alles herstarten (modem, pihole, computer + dns flushen).

Nu zou het toch moeten werken en het verkeer via mijn pihole moeten lopen?

Echter wanneer ik dit doe:
1. mijn telefoon kan geen verbinding meer maken met het wifi netwerk (krijgt geen ip)
2. het pi-hole admin dashboard is niet meer bereikbaar via het ip adres
3. reclame etc is nog steeds zichtbaar op mijn computer

Kortom, het lijkt niet te werken.

Iemand een idee wat ik fout doe / hoe het wel moet? Ik heb deze thread en het ziggo forum al lopen doorspitten maar ik kom er zelf niet uit

Je moet op de Raspberry Pi zelf het vaste IP-adres instellen.

[deHakkelaar]

jaspervd schreef op zaterdag 25 september 2021 @ 22:06:
Vandaag een raspberrypi ontvangen en pi hole erop gezet, na installatie lijkt alles goed te werken en kan ik het admin dashboard bezoeken.

Nu wil ik de pi hole zo instellen zodat al het internet verkeer binnen mijn netwerk (laptops, telefoons, desktop) automatisch via de pi hole verloopt, ik heb hiervoor de volgende stappen doorlopen, maar krijg het niet werkend

1. op mijn ziggo modem (technicolor) de pi hole een vast ip adres gegeven (192.168.178.26)
2. inloggen op mijn ziggo modem en DHCP server daar uitzetten (hierbij ook geprobeert bij IPv4 DNS servers het ip adres van mijn pi-hole in te vullen, dit maakte geen verschil)
3. inloggen op mijn pi-hole en DHCP server daar aanzetten, hierbij vul ik de ip range zoals in mijn router stonden in en geef ik als router gateway het ip adres van mijn ziggo modem op.
4. alles herstarten (modem, pihole, computer + dns flushen).

Nu zou het toch moeten werken en het verkeer via mijn pihole moeten lopen?

Echter wanneer ik dit doe:
1. mijn telefoon kan geen verbinding meer maken met het wifi netwerk (krijgt geen ip)
2. het pi-hole admin dashboard is niet meer bereikbaar via het ip adres
3. reclame etc is nog steeds zichtbaar op mijn computer

Kortom, het lijkt niet te werken.

Iemand een idee wat ik fout doe / hoe het wel moet? Ik heb deze thread en het ziggo forum al lopen doorspitten maar ik kom er zelf niet uit

Draai de Pi-hole debugger en kijk ofdat er wat fout gerapporteerd wordt:

code:

pihole -d

Je wordt gevraagd als laatste stap ofdat je deze log output wilt uploaded naar de Pi-hole tricorder server voor support.
Dit is niet nodig voor ons maar wel als je een support case wilt aanmaken op Pi-hole Discourse.
Paste niet de hele output hier want er kunnen ook private dingen in staan die je niet wilt delen met ons!

[jaspervd]

Pierre schreef op zaterdag 25 september 2021 @ 22:26:
Je zal in het modem van Ziggo het ip adres van je PiHole als DNS moeten invullen. Hier staat mijn CB in bridge en daar achter hangt mijn eigen router. En die gebruikt als DNS de PiHole.

dit heb ik inderdaad gedaan zie:

Freee!! schreef op zaterdag 25 september 2021 @ 22:35:
[...]

Je moet op de Raspberry Pi zelf het vaste IP-adres instellen.

dit doe je tijdens de setup toch? Waar kan ik controleren of dit goed gegaan is / dit alsnog instellen?

deHakkelaar schreef op zaterdag 25 september 2021 @ 22:40:
[...]

Draai de Pi-hole debugger en kijk ofdat er wat fout gerapporteerd wordt:

dit heb ik gedaan, ziet er allemaal goed uit, op dit na misschien, geplakt uit de logs:

code:

*** [ DIAGNOSING ]: Networking
[✗] No IPv4 address(es) found on the eth0 interface.

[✗] No IPv6 address(es) found on the eth0 interface.

na het draaien van de debugger zie ik in ieder geval voor het eerst ook iets in de logs op mijn admin dashboard verschijnen, dus het lijkt vooral in de combo router/pihole te zitten en niet de pihole zelf?

[deHakkelaar]

@jaspervd , check ofdat helemaal onderaan onderstaande bestandje een interface sectie staat met de static IP details:

pi@ph5b:~ $ sudo nano /etc/dhcpcd.conf
[..]
interface eth0
  static ip_address=10.0.0.4/24
  static routers=10.0.0.1
  static domain_name_servers=10.0.0.1

Zoniet, copy/paste, aanpassen naar jouw IP's en subnet, save/exit en onderstaande om toe te passen:

pi@ph5b:~ $ sudo service dhcpcd restart
pi@ph5b:~ $

systemd journals/logs checken:

pi@ph5b:~ $ journalctl -u dhcpcd
[..]
-- Logs begin at Thu 2021-09-23 07:50:01 CEST, end at Sat 2021-09-25 23:00:02 CEST. --
Sep 25 22:59:24 ph5b systemd[1]: Stopping dhcpcd on all interfaces...
Sep 25 22:59:24 ph5b dhcpcd[20977]: sending signal TERM to pid 30543
Sep 25 22:59:24 ph5b dhcpcd[20977]: sending signal TERM to pid 30543
Sep 25 22:59:24 ph5b dhcpcd[20977]: waiting for pid 30543 to exit
Sep 25 22:59:24 ph5b dhcpcd[20977]: waiting for pid 30543 to exit
Sep 25 22:59:24 ph5b dhcpcd[30543]: received SIGTERM, stopping
Sep 25 22:59:24 ph5b dhcpcd[30543]: eth0: removing interface
Sep 25 22:59:25 ph5b dhcpcd[30543]: dhcpcd exited
Sep 25 22:59:25 ph5b systemd[1]: dhcpcd.service: Succeeded.
Sep 25 22:59:25 ph5b systemd[1]: Stopped dhcpcd on all interfaces.
Sep 25 22:59:25 ph5b systemd[1]: Starting dhcpcd on all interfaces...
Sep 25 22:59:25 ph5b dhcpcd[20979]: dev: loaded udev
Sep 25 22:59:25 ph5b dhcpcd[20979]: DUID 00:01:00:01:28:7e:.....
Sep 25 22:59:25 ph5b dhcpcd[20979]: eth0: IAID eb:....
Sep 25 22:59:25 ph5b dhcpcd[20979]: eth0: using static address 10.0.0.4/24
Sep 25 22:59:25 ph5b dhcpcd[20979]: eth0: adding route to 10.0.0.0/24
Sep 25 22:59:25 ph5b dhcpcd[20979]: eth0: adding default route via 10.0.0.1
Sep 25 22:59:25 ph5b dhcpcd[20993]: eth0: soliciting an IPv6 router
Sep 25 22:59:25 ph5b dhcpcd[20979]: forked to background, child pid 20993
Sep 25 22:59:25 ph5b systemd[1]: Started dhcpcd on all interfaces.
Sep 25 22:59:37 ph5b dhcpcd[20993]: eth0: no IPv6 Routers available

IP checken:

pi@ph5b:~ $ ip -br -4 a
lo               UNKNOWN        127.0.0.1/8
eth0             UP             10.0.0.4/24

Routes checken:

pi@ph5b:~ $ ip -br -4 r
default via 10.0.0.1 dev eth0 src 10.0.0.4 metric 202
10.0.0.0/24 dev eth0 proto dhcp scope link src 10.0.0.4 metric 202

Testen naar Google DNS @ 8.8.8.8

pi@ph5b:~ $ traceroute -n 8.8.8.8
traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets
 1  10.0.0.1  0.772 ms  0.589 ms  0.592 ms
 2  192.168.1.1  1.377 ms  0.749 ms  0.694 ms
 3  62.58.240.1  9.083 ms  8.659 ms  8.245 ms
 4  * * 212.53.25.201  10.906 ms
 5  * * *
 6  * * *
 7  8.8.8.8  8.733 ms  8.587 ms  8.813 ms

En weer Pi-hole debugger draaien mocht het nog fout gaan.

EDIT: ow vaak als je dingen in de OS wijzigt, is het noodzakelijk om repair te draaien en reconfigure te selecteren:

code:

pihole -r

[Freee!!]

jaspervd schreef op zaterdag 25 september 2021 @ 22:48:
[...]
dit doe je tijdens de setup toch? Waar kan ik controleren of dit goed gegaan is / dit alsnog instellen?

Controleren doe je door een SSH (of telnet) sessie naar de RPi op te zetten. Voor dat stuk gebruik ik OMV.

[jaspervd]

Jullie zijn helden! Door die commands kwam ik erachter dat er bij het installeren toch iets mis was gegaan, ik had namelijk tijdens de installatie eth0 geselecteerd terwijl ik mijn raspberry via de wifi (wlan0) heb verbonden.

met behulp van de commands van deHakkelaar eth0 aangepast in wlan0 en alles werkte meteen na de reload!!!

[deHakkelaar]

Freee!! schreef op zaterdag 25 september 2021 @ 23:13:
[...]

(of telnet) sessie naar de RPi

Telnet ... proest
Dat doen we al niet meer sinds the dark ages.
Alhoewel m'n oude Asus routertje nog alleen te benaderen is via telnet

# ps
  PID USER       VSZ STAT COMMAND
  335 xxxxxxxx  1624 R    telnetd -b 10.0.0.1

[Freee!!]

deHakkelaar schreef op zaterdag 25 september 2021 @ 23:55:
[...]
Telnet ... proest
Dat doen we al niet meer sinds the dark ages.

Dan weet je meteen hoe oud ik ben, ik gebruik het soms nog wel, ook om SMTP te testen.

[nero355]

SpiriTNL schreef op zaterdag 25 september 2021 @ 11:28:
Wil mijn ervaring even delen met overstap van Chrome naar Brave

In Chrome kreeg ik de laatste tijd meer en meer reclames te zien.
Blijkbaar pakt chrome heel snel zijn eigen DNS als er iets niet goed gaat of te lang duurt.
Mijn Pi-hole draait op mijn NAS en werkt naar behoren.

Nu heb ik Brave Browser geïnstalleerd en alles overgezet en alle reclames zijn verdwenen.
Brave is op chrome gebaseerd maar werkt in mijn situatie nu 100%.

Brave is gemaakt/wordt onderhouden door een vreselijk shady bedrijf dus die browser zou ik echt iedereen afraden!

Google Chrome trouwens ook, maar ik zal je effe op weg helpen : chrome://flags intikken als URL en dan alles wat met DNS te maken heeft zoveel mogelijk slopen!

Als je hier in het topic de Search aanslingert bovenaan de pagina dan kan je een reactie van mij vinden met alle dingen waarop je (destijds) moest letten

[Chris12]

deHakkelaar schreef op vrijdag 24 september 2021 @ 22:00:
[...]


Als ik goed begrijp, is je DNS pad nu als volgt:

Client --> Pi-hole --> router --> Cloudflare

Waarom die router er tussenin?
Waarom niet gewoon direct:

Client --> Pi-hole --> Cloudflare

Als dit is vanwege de "DNS filter settings" in de router, wat doet deze dan precies?

Ik heb het DNS filter deel indertijd geloof ik ingericht op basis van onderstaande link:
https://www.snbforums.com...h-selected-clients.70279/

Echter niet het conditional forwarding deel in pi-hole.

Heb eigenlijk nergens meer reclames waar ik het verwacht.

[deHakkelaar]

@Chris12 , niet precies wat ik vroeg maar van dat kleine stukje text boven de screenshot van de DNS-based filtering setting maak ik op dat dit een soort DNS filter is op de firewall welke alle DNS packets (53 UDP & TCP) tunnelt naar een specifiek IP.
Als mijn vermoeden klopt, dan kan je alsnog de router uit het DNS pad halen (is een hop minder).
Die setting lijkt namelijk op een network packet filter (firewall) welke geldt voor alle DNS packets die door de router gaan ongeacht welke DNS server(s) je selecteert upstream voor Pi-hole.

Als je dit wilt testen, haal dan maar die router uit het DNS pad en doe onderstaande lookup naar Google DNS @ 8.8.8.8 vanaf een client (Windows,Mac of Linux):

code:

nslookup pi.hole 8.8.8.8

Als je netjes het IP van Pi-hole als antwoord krijgt werkt je packet filtering.
Google kent die pi.hole naam namelijk niet:

C:\>nslookup pi.hole 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

*** dns.google can't find pi.hole: Non-existent domain

Mogelijk werkt het ook als je een niet gebruikt IP uit je LAN adresseerd???

code:

nslookup pi.hole <ONGEBRUIKT_LAN_IP>

EDIT: Ow, het is te hopen dat die router intellegent genoeg is om niet de DNS queries van Pi-hole zelf te tunnelen naar het Pi-hole IP en er dus een DNS loop onstaat!
Mogelijk dat je daar anders een uitzondering voor kan instellen op de router ... geen idee.

EDIT2: Toch maar dat draadje verder gelezen op snbforum.
Echt tot een behoorlijke oplossing komen ze daar niet lijkt het.
Maar wat je zeker niet wilt is een onnodige extra DNS hop die vertraagt.
En je wilt dat de clients direct Pi-hole addresseren ipv eerst via je router.

Dat antwoord van @jpdsc aldaar komt nog het meest in de buurt van wat je wilt.
Alhoewel ik de WAN DNS setting genaamd "Connect to DNS Server automatically" gewoon op default "Yes" zou laten staan zodat de router de DNS servers oppikt van je ISP.
Mocht dit werken, dan pas die DNS-based filtering setting activeren en testen met nslookup ofdat alles nog blijft werken:

code:

nslookup <DOMEIN> <DNS_SERVER_IP>

EDIT3:
En eindelijk een stukje documentatie gevonden RTFM
https://github.com/RMerl/asuswrt-merlin.ng/wiki/DNS-Filter
Global dus en een "client rule" aanmaken voor een uitzondering van Pi-hole.
En niet vergeten de router uit het DNS pad te halen!

[ Voor 34% gewijzigd door deHakkelaar op 27-09-2021 23:45 ]

[jpgview]

A problem, limited to iOS devices (14.8 and 15). Neither Windows 10 nor macOS 11.3 show the same behaviour (opmerking uit het reddit artikel)

oorzaak: iCloud Private Relay, een apple privacy feature, met als nadeel dat pihole niet langer gebruikt wordt.

De pihole oplossing:

Een aantal artikels bespreken de apple implementatie van oblivious DoH. Blijkt dat je als netwerk beheerder eenvoudig kan voorkomen dat apple devices oDoH gebruiken, en dus niet langer de pihole DNS, lees hier en hier.

pihole zorgde er reeds voor dat firefox géén DoH gebruikt, wanneer het correcte antwoord (NXDOMAIN) op de query voor het domain use-application-dns.net gegeven wordt. Oorspronkelijk werd hiervoor gebruik gemaakt van server=/use-application-dns.net/ in /etc/dnsmasq.d/01-pihole.conf, ondertussen is dit verwijderd en is dit nu hardcoded in pihole-FTL.

met de nieuwe release is de pihole reply voor de domains mask.icloud.com en mask-h2.icloud.com is nu ook NXDOMAIN (hardcoded), de gebruiker zal dus steeds een waarschuwing krijgen, zie hier...

edit
achterhaald terwijl ik het nalees, dus aangepast, released just now: Pi-hole v5.5, Pi-hole web v5.7, Pi-hole FTL v5.10.1
/edit

[ Voor 35% gewijzigd door jpgview op 30-09-2021 08:24 . Reden: pihole update available ]

[Church of Noise]

Klein puntje ivm de laatste update: er zit een bug in, die ervoor zorgt dat je FTL (dus dnsmasq) ervantussen gaat als je conditional forwarding aan hebt, en je Local network in CIDR notation adres niet 0 als laatste getal heeft. Bug in de laatste dnsmasq, het team neemt het op met Simon Kelley en heeft ondertussen een patch uit die het fixt (net getest, die werkt).
Eenvoudigste tijdelijke fix is dus het laatste getal in dat adres op 0 te brengen (of conditional forwarding uit te schakelen).

Waarschijnlijk niet relevant voor de meeste gebruikers, maar ik heb een paar uur zonder een van m'n Pi-Holes gedraaid als gevolg.

[jpgview]

Church of Noise schreef op donderdag 30 september 2021 @ 11:44:
Klein puntje ivm de laatste update:

Ook ik merk een paar probleempjes (pihole en list related).

1. nslookup pi.hole geeft geen resultaat meer, kan iemand dit bevestigen? (reeds hier gemeld)

2. https://winhelp2002.mvps.org/hosts.txt list download failed.

ERROR: The certificate of ‘winhelp2002.mvps.org’ is not trusted.
ERROR: The certificate of ‘winhelp2002.mvps.org’ has expired.

contact reeds op de hoogte gebracht.

[Church of Noise]

jpgview schreef op donderdag 30 september 2021 @ 13:06:
[...]


Ook ik merk een paar probleempjes (pihole en list related).

1. nslookup pi.hole geeft geen resultaat meer, kan iemand dit bevestigen? (reeds hier gemeld)

2. https://winhelp2002.mvps.org/hosts.txt list download failed.


[...]

contact reeds op de hoogte gebracht.

Beide heb ik ook voor.

[ Voor 4% gewijzigd door Church of Noise op 30-09-2021 13:16 ]

[deHakkelaar]

jpgview schreef op donderdag 30 september 2021 @ 13:06:
[...]


Ook ik merk een paar probleempjes (pihole en list related).

1. nslookup pi.hole geeft geen resultaat meer, kan iemand dit bevestigen? (reeds hier gemeld)

2. https://winhelp2002.mvps.org/hosts.txt list download failed.


[...]


contact reeds op de hoogte gebracht.

Punt één kan ik niet bevestigen want ik wacht even met updaten zo te horen.
Punt twee, curl, welke Pi-hole ook gebruikt voor een gravity pull, geeft aan dat het SSL/TLS cert is verlopen:

pi@ph5b:~ $ curl -sSLI https://winhelp2002.mvps.org/hosts.txt
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Maar zo te zien istie dat niet echt:

pi@ph5b:~ $ curl -sSLIvk https://winhelp2002.mvps.org/hosts.txt
[..]
* Server certificate:
*  subject: CN=winhelp2002.mvps.org
*  start date: Sep 22 15:00:34 2021 GMT
*  expire date: Dec 21 15:00:33 2021 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: certificate has expired (10), continuing anyway.
[..]

Mijn vermoeden, datum/tijd verkeerd aan de server kant.

[ Voor 10% gewijzigd door deHakkelaar op 30-09-2021 14:55 ]

[Lizard]

deHakkelaar schreef op donderdag 30 september 2021 @ 14:50:
[...]

Punt één kan ik niet bevestigen want ik wacht even met updaten zo te horen.
Punt twee, curl, welke Pi-hole ook gebruikt voor een gravity pull, geeft aan dat het SSL/TLS cert is verlopen:

pi@ph5b:~ $ curl -sSLI https://winhelp2002.mvps.org/hosts.txt
curl: (60) SSL certificate problem: certificate has expired
More details here: https://curl.haxx.se/docs/sslcerts.html

curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.

Maar zo te zien istie dat niet echt:

pi@ph5b:~ $ curl -sSLIvk https://winhelp2002.mvps.org/hosts.txt
[..]
* Server certificate:
*  subject: CN=winhelp2002.mvps.org
*  start date: Sep 22 15:00:34 2021 GMT
*  expire date: Dec 21 15:00:33 2021 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify result: certificate has expired (10), continuing anyway.
[..]

Mijn vermoeden, datum/tijd verkeerd aan de server kant.

Of dit issue: https://techcrunch.com/2021/09/21/lets-encrypt-root-expiry/

[deHakkelaar]

@Lizard , wat een bak
Ik heb vast een andere root CA:

pi@ph5b:~ $ curl -sSLIvk https://dehakkelaar.nl
[..]
* Server certificate:
*  subject: CN=dehakkelaar.nl
*  start date: Sep 22 00:00:24 2021 GMT
*  expire date: Dec 21 00:00:23 2021 GMT
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
[..]

EDIT: Aha gevonden terwijl met wat anders bezig was:

pi@ph5b:~ $ echo | openssl s_client -connect winhelp2002.mvps.org:443 -showcerts
CONNECTED(00000003)
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
verify error:num=10:certificate has expired
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3
notAfter=Sep 30 14:01:15 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify error:num=10:certificate has expired
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
notAfter=Sep 29 19:21:40 2021 GMT
verify return:1
depth=0 CN = winhelp2002.mvps.org
notAfter=Dec 21 15:00:33 2021 GMT
verify return:1

pi@ph5b:~ $ echo | openssl s_client -connect dehakkelaar.nl:443 -showcerts
CONNECTED(00000003)
depth=2 C = US, O = Internet Security Research Group, CN = ISRG Root X1
verify return:1
depth=1 C = US, O = Let's Encrypt, CN = R3
verify return:1
depth=0 CN = dehakkelaar.nl
verify return:1

[ Voor 62% gewijzigd door deHakkelaar op 03-10-2021 13:07 ]

[deHakkelaar]

Vreemde 3072 bit size vergeleken met de normale 4096 van mijn cert:

pi@ph5b:~ $ diff winhelp2002.mvps.org.cert.info dehakkelaar.nl.cert.info
[..]
14c14
<                 RSA Public-Key: (3072 bit)
---
>                 RSA Public-Key: (4096 bit)
[..]

[MAdD]

waarschijnlijk niet overgestapt op de R3 intemediate certificaat.
Was een tijd geleden een melding over om hierop over te stappen (volgens mij versie x2x geloof ik van de autocert tool)

[deHakkelaar]

@MAdD , bedoel je deze soms?

Starting at the beginning of 2021 we will occasionally disable ACMEv1 issuance and renewal for periods of 24 hours, no more than once per month (OCSP service will not be affected). The intention is to induce client errors that might encourage subscribers to update to clients or configurations that use ACMEv2. Renewal failures should be limited since new domain validations will already be disabled and we recommend renewing certificates 30 days before they expire.

https://community.letsenc...ife-plan-for-acmev1/88430

Want das al een poosje terug

[deHakkelaar]

EDIT: Laat benedenstaande maar, is niet relevant!

@jpgview @Church of Noise , wat is versie van je root CA certs?
[cmd]pi@ph5b:~ $ apt policy ca-certificates
ca-certificates:
Installed: 20200601~deb10u2
Candidate: 20200601~deb10u2
Version table:
*** 20200601~deb10u2 500
500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages
100 /var/lib/dpkg/status[/cmd]

EDIT:
[cmd]pi@ph5b:~ $ dpkg -L ca-certificates | grep -i dst
/usr/share/ca-certificates/mozilla/DST_Root_CA_X3.crt[/cmd]

[ Voor 22% gewijzigd door deHakkelaar op 30-09-2021 16:58 ]

[jpgview]

jpgview schreef op donderdag 30 september 2021 @ 13:06:
[...]
nslookup pi.hole geeft geen resultaat meer, kan iemand dit bevestigen? (reeds hier gemeld)

probleem is ondertussen bevestigd en opgelost.

maar ik verwacht dat release pihole-FTL v5.10.2 niet lang op zich zal laten wachten...

edit
pihole-FTL v5.10.2 released. Hoewell het niet in de release notes vermeld is, werkt nslookup pi.hole terug, thus solved...
/edit

[ Voor 22% gewijzigd door jpgview op 30-09-2021 22:18 ]

[nero355]

Dus nou nog hierop wachten :

Church of Noise schreef op maandag 20 september 2021 @ 17:59:
Kan dit verband houden met de bug in dnsmasq waarover men melding maakt op Discourse?

Church of Noise schreef op donderdag 30 september 2021 @ 11:44:
Klein puntje ivm de laatste update: er zit een bug in, die ervoor zorgt dat je FTL (dus dnsmasq) ervantussen gaat als je conditional forwarding aan hebt, en je Local network in CIDR notation adres niet 0 als laatste getal heeft. Bug in de laatste dnsmasq, het team neemt het op met Simon Kelley en heeft ondertussen een patch uit die het fixt (net getest, die werkt).
Eenvoudigste tijdelijke fix is dus het laatste getal in dat adres op 0 te brengen (of conditional forwarding uit te schakelen).

Waarschijnlijk niet relevant voor de meeste gebruikers, maar ik heb een paar uur zonder een van m'n Pi-Holes gedraaid als gevolg.

En dan eindelijk updaten!

[jpgview]

nero355 schreef op vrijdag 1 oktober 2021 @ 00:02:
Dus nou nog hierop wachten :

Church of Noise schreef op donderdag 30 september 2021 @ 11:44:
Klein puntje ivm de laatste update: er zit een bug in, die ervoor zorgt dat je FTL (dus dnsmasq) ervantussen gaat als je conditional forwarding aan hebt, en je Local network in CIDR notation adres niet 0 als laatste getal heeft. Bug in de laatste dnsmasq, het team neemt het op met Simon Kelley en heeft ondertussen een patch uit die het fixt (net getest, die werkt).
Eenvoudigste tijdelijke fix is dus het laatste getal in dat adres op 0 te brengen (of conditional forwarding uit te schakelen).

En dan eindelijk updaten!

dit zou ook opgelost zijn, zie hier. Helaas hebben ze er een zooitje van gemaakt (stress related?), géén volledige release notes en geen annoucement....

[nero355]

Nou dan ga ik maar eens effe de boel updaten en kijken hoe dat uitpakt

Ik heb toch alleen maar :
- 192.168.x.0/24
- 10.x.x.0/24
- 172.x.x.0/24

Subnets waar Pi-Hole op actief is!

/EDIT :
DAMNIT...

Ik wilde net beginnen blijkt er toch nog iets mis mee te zijn!

"Now we wait!" zoals ze in de films zeggen...

[ Voor 29% gewijzigd door nero355 op 02-10-2021 15:01 ]

[Church of Noise]

Er is blijkbaar ook een issue waardoor CNAME blocking momenteel niet werkt.
Ook daarvoor is een fix in de maak.
Veel van de huidige akkefietjes lijken verband te hebben met zaken op dnsmasq gebied...

[Webgnome]

als ik het zo lees wacht ik nog even met updates..

[Church of Noise]

Niet zo'n gek idee eigenlijk
We houden je hier wel op de hoogte.

[sweetdude]

jpgview schreef op vrijdag 1 oktober 2021 @ 11:47:
[...]


dit zou ook opgelost zijn, zie hier. Helaas hebben ze er een zooitje van gemaakt (stress related?), géén volledige release notes en geen annoucement....

Er is inderdaad wel iets vreemds aan de hand. Ik had gisteren geupdaet en kreeg FTL v5.10.2
Vanmorgen controleer ik blijkt er een nieuwe update van FTL te zijn met hetzelfde versienummer.

[Pierre]

Webgnome schreef op zaterdag 2 oktober 2021 @ 11:36:
als ik het zo lees wacht ik nog even met updates..

Toevallig wilde ik ook vandaag even de update doen, denk dat ik maar heel even wacht

[jpgview]

hulp gevraagd...

iedereen weet ondertussen dat pihole-FTL v5.10.2 geen CNAME blocking meer doet. Er is ondertussen een fix beschikbaar (pihole checkout ftl fix/cname), maar wie er niet van houd om over te schakelen naar een andere branch...

Omdat dit niet de eerste keer is dat er wat mis is met pihole-FTL, wil ik een test scriptje maken dat, onafhankelijk van blocklists, maar wel rekening houdend met mijn dnsmasq, whitelist, blacklist, regex config test of alles werkt zoals het hoort.

ik gebruik pihole-FTL + unbound recursive, duckduckgo geeft aan dat je met unbound geen cname blocking kan simuleren, unbound is een recursive resolver, je hebt een authoritive resolver nodig om een en ander te kunnen simuleren.

Na ff zoeken heb ik nsd (ook een nlnetlabs product) geinstalleerd en geconfigureerd.

Om deze post leesbaar te houden heb ik alle code die ik tot hiertoe bijeen heb gesprokkeld in een pdf gestoken ,hier (remember, whitelist users.telenet.be)

de eerste testen zijn ok (ik draai de fix branch). DL6ER legt hier uit dat er twee verschillende gevallen van cname moeten gedetecteerd worden, beide werken:
dig cname-1.ftl.test (simple cname) geeft 0.0.0.0
dig cname-4.ftl.test (andere case) geeft ook 0.0.0.0

so far , so good

nu wil ik cname cloaking testen, de techniek die websites gebruiken om tracking te outsourcen. Volgens de beschrijvingen die ik lees, volstaat het om in het customer domain (ftl.test) een entry aan te maken die wijst naar het domain van de tracker, e.g. iets als

cname-5 IN CNAME www.tagcommander.com

ik hoopte dat, door de regex uit de NextDNS lijst te gebruiken, (\.|^)tagcommander\.com$ , deep CNAME inspection er ook zou voor zorgen dat ik 0.0.0.0 zou terug krijgen, helaas.

Blijkt dat dit met dnsmasq niet aan de praat te krijgen is, unbound is hier nodig (de recursieve resolver), om het ip van www.tagcommander.com te bekomen. Opnieuw helaas dus, mijn pogingen om dit aan de praat te krijgen (dnsmasq config verwijderen) en unbound config toevoegen:

stub-zone:
name: "ftl.test"
stub-addr: 127.10.10.7@5557

zorgen er niet voor dat het werkt, zelfs een dig www.ftl.test (ook in de zone file) levert geen IP meer op.

Dus de vraag: wie heeft iets dergelijks al eens geprobeert, of wil het eventueel testen om, als eindresultaat, een ftl test script te bekomen?

Eventueel antwoorden via berichten, om te vermijden dat het forum volloopt met posts, die 95% van de users niet interesseert.

[deHakkelaar]

@jpgview , met embedded dnsmasq, hoef je alleen een A of AAAA record aan te maken voor het target domein om authoritative to worden:

pi@ph5b:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
host-record=www.tagcommander.com,10.20.30.40
cname=ftl.test,www.tagcommander.com

pi@ph5b:~ $ pihole-FTL --test
dnsmasq: syntax check OK.

pi@ph5b:~ $ sudo service pihole-FTL reload
pi@ph5b:~ $

pi@ph5b:~ $ dig +short @localhost www.tagcommander.com a
10.20.30.40

pi@ph5b:~ $ dig +short @localhost ftl.test cname
www.tagcommander.com.

pi@ph5b:~ $ dig +short @localhost ftl.test a
www.tagcommander.com.
10.20.30.40

Handiger misschien als je een appart draadje aanmaakt en um hier linkt ipv PM's?
Met PM's zien de anderen niet wat al besproken is.

[jpgview]

deHakkelaar schreef op dinsdag 5 oktober 2021 @ 16:52:
@jpgview
Handiger misschien als je een appart draadje aanmaakt en um hier linkt ipv PM's?
Met PM's zien de anderen niet wat al besproken is.

geen idee hoe dat moet....

deHakkelaar schreef op dinsdag 5 oktober 2021 @ 16:52:
@jpgview , met embedded dnsmasq, hoef je alleen een A of AAAA record aan te maken voor het target domein om authoritative to worden:

punt is, dat ik aan mijn dnsmask config géén wijzigingen will aanbrengen. vandaar de poging om unbound en nsd te laten samen werken (stub zone), massa's info op duckduckgo, helaas geen voorbeeld dat werkt (voor mij).

alleen om de cname test uit te voeren heb ik een extra blacklist entry nodig. een test op b.v. ads.ftl.test moet een mmotti regex triggeren (die ik aan mijn pihole heb toegevoegd)

[deHakkelaar]

@jpgview , ik dacht gewoon een nieuw draadje starten hiero:
Netwerken
En ff linkje plaatsen hier voor publiek.

Je kunt ook twee maal de pihole-FTL deamon opstarten met verwijzing naar vershillende config files, op verschillende poorten of binden op twee verschillende IP's.
Maar is een boel werk.
Makkelijkst is om dnsmasq of Pi-hole op een andere tux doos op te starten:

pi@ph5b:~ $ apt depends dnsmasq
dnsmasq
  Depends: netbase
  Depends: dnsmasq-base
    dnsmasq-base-lua
  Depends: init-system-helpers (>= 1.18~)
  Depends: lsb-base (>= 3.0-6)
  Conflicts: resolvconf (<< 1.15)
  Suggests: resolvconf
    openresolv

Heb nog te weinig ervaring met unbound helaas.

[ Voor 27% gewijzigd door deHakkelaar op 05-10-2021 18:04 ]

[Church of Noise]

Heeft nog iemand hier problemen met updates of veranderen van branch?
Heb de laatste week ongeveer het probleem dat ik de melding krijg 'permission denied'.
Heel bizar...

Voorbeeld: zonet pihole checkout dev , na een succesvolle pihole checkout master, met dit als resultaat:

code:

/opt/pihole/piholeCheckout.sh: line 197: /etc/.pihole/automated install/basic-install.sh: Permission denied

Ondertussen uitgeklaard: was een bug in de dev branch, en die werd ondertussen gefixed.

[ Voor 57% gewijzigd door Church of Noise op 05-10-2021 21:22 ]

[stormfly]

@nero355 or others, sinds gisteren over naar KPN met native IPv6. Ik heb IPv6 nu werkend op docker

-pihole IPv6 DNS in en out
-adguard IPv6 DNS in en out
-unbound IPv6 dns out....no in

Ik krijg met geen enkele mogelijkheid via het LAN een DNS bevraging gedaan op de unbound docker...willen jullie eens meedenken?

Unbound resolved IPv6 richting de rootservers perfect, feitelijk alleen maar IPv6 in het backend. Het frontend wil nog niet.

code:

server:
  verbosity: 3
  interface: 0.0.0.0
  interface: ::0
  access-control: 0.0.0.0/0 allow
  access-control: ::0/0 allow
  access-control: A:B:C::/48 allow
  logfile: /dev/stdout
  log-time-ascii: yes
  directory: "/etc/unbound"
  username: unbound
  auto-trust-anchor-file: trusted-key.key
  root-hints: "/etc/unbound/root.hints"
  do-ip4: yes
  do-ip6: yes
  prefer-ip6: yes
  do-udp: yes
  do-tcp: yes
  do-daemonize: no
  hide-identity: yes
  hide-version: yes
  minimal-responses: yes
  qname-minimisation: yes
  cache-min-ttl: 3600
  cache-max-ttl: 86400
  harden-glue: yes
  harden-dnssec-stripped: no
  harden-referral-path: no
  prefetch: yes
  prefetch-key: yes
  do-not-query-localhost: no
  max-udp-size: 4096
  msg-buffer-size: 65552
  so-reuseport: yes
  num-threads: 8
  rrset-cache-size: 8m
  rrset-roundrobin: yes
  msg-cache-size: 4m
  outgoing-num-tcp: 10
  serve-expired: no

[ Voor 6% gewijzigd door stormfly op 05-10-2021 21:49 ]

[geenwindows]

stormfly schreef op dinsdag 5 oktober 2021 @ 21:32:
@nero355 or others, sinds gisteren over naar KPN met native IPv6. Ik heb IPv6 nu werkend op docker

-pihole IPv6 DNS in en out
-adguard IPv6 DNS in en out
-unbound IPv6 dns out....no in

Ik krijg met geen enkele mogelijkheid via het LAN een DNS bevraging gedaan op de unbound docker...willen jullie eens meedenken?

Unbound resolved IPv6 richting de rootservers perfect, feitelijk alleen maar IPv6 in het backend. Het frontend wil nog niet.

[...]

als ik de unbound config uit van m'n opnsense mag geloven:

code:

# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::
interface-automatic: yes

en qua "acces-control" staan hier alle subnetten van mijn netwerk, zowel ipv4 als ipv6.

code:

access-control: 127.0.0.1/8 allow
access-control: ::1/64 allow
access-control: 10.0.0.1/24 allow
access-control: fe80::local:ipv6:adress:XXX/64 allow
access-control: LAN:IPv6:pre:fix:sub:network:XXXX:XXX/64 allow

[Wachten...]

Ik ben een nieuwe Pihole installatie aan het doen, en dit keer met DietPi.

Nu heb ik de image geïnstalleerd via Etcher, maar hij maakt dan 2 partites van mijn SD card. (een partitie met data erop, en de andere is leeg)

Klopt dit, want ik krijg later ook een melding tijdens de installatie van Dietpi
[ INFO ] Disable SD card hot plug detection │
│ │
│ An issue was detected on RPi, where the default regular SD card polling │
│ leads to significant CPU load, when no SD card is actually attached: │
│ - https://github.com/MichaIng/DietPi/issues/4602 │
│ │
│ The regular polling is required to allow SD card hot plug detection, so that │
│ you can instantly mount them, when plugged to a running Pi. │
│ │
│ As long as an SD card is present or used as system drive, it does not imply │
│ notable CPU load, but also hot plug detection is not needed then. We hence │
│ recommend to have this feature disabled on all RPi systems. │
│ │
│ Do you want to have SD card hot plug detection disabled now?

Een melding die ik in geen enkele andere installatie (tutorial) voorbij zie komen.
Ik vraag me af of het dus wel allemaal goed gaat.

[ Voor 53% gewijzigd door Wachten... op 06-10-2021 20:42 ]

[Wachten...]

Wordt de https://oisd.nl/ lijst trouwens nog steeds bijgehouden dat iemand weet?
@sjhgvr

Mijn systeem draait al een jaar of 3 o.i.d. met deze lijst, maar geen idee eigenlijk of alles nog een beetje up to date is.

[dss58]

Wachten... schreef op donderdag 7 oktober 2021 @ 00:45:
Wordt de https://oisd.nl/ lijst trouwens nog steeds bijgehouden dat iemand weet?
@sjhgvr

Mijn systeem draait al een jaar of 3 o.i.d. met deze lijst, maar geen idee eigenlijk of alles nog een beetje up to date is.

een paar keer per dag een update

[stormfly]

geenwindows schreef op woensdag 6 oktober 2021 @ 10:10:
[...]


als ik de unbound config uit van m'n opnsense mag geloven:

code:

# Interface IP(s) to bind to
interface: 0.0.0.0
interface: ::
interface-automatic: yes

en qua "acces-control" staan hier alle subnetten van mijn netwerk, zowel ipv4 als ipv6.

code:

access-control: 127.0.0.1/8 allow
access-control: ::1/64 allow
access-control: 10.0.0.1/24 allow
access-control: fe80::local:ipv6:adress:XXX/64 allow
access-control: LAN:IPv6:pre:fix:sub:network:XXXX:XXX/64 allow

Tnx ik neem nog wat van je tips over, ineens werkt het na een paar herstarts.

[Wachten...]

dss58 schreef op donderdag 7 oktober 2021 @ 02:29:
[...]

een paar keer per dag een update

Ik las het inderdaad op de website, maar ik zie op githib en Reddit al bijna 2 jaar geen reacties meer. Vandaar mijn vraag.

[geenwindows]

Wachten... schreef op donderdag 7 oktober 2021 @ 00:45:
Wordt de https://oisd.nl/ lijst trouwens nog steeds bijgehouden dat iemand weet?
@sjhgvr

Mijn systeem draait al een jaar of 3 o.i.d. met deze lijst, maar geen idee eigenlijk of alles nog een beetje up to date is.

als je het bestand zelf opend zie je dit boven aan staan:

code:

#    __ __ ____ ____                 
#   /  (  / ___(    \
#  (  O )(\___ \) D (
#   \__(__(____(____/
#
#  Title: oisd basic     
#  Syntax: dbl       
#  Entries: 91968  
#  TimeUpdated: 2021-10-07T00:11:52+02:00     
#  Maintainer: sjhgvr
#  Expires: 1 day (update frequency)
#  Homepage: https://oisd.nl

en daarbij staat op de website bij de FAQ dit:

code:

How often is the list updated?
The quick answer is; At least once every 24 hours.

It really depends on if there are changes in the source lists, and when false positives get removed from the oisd list.
A good guess from me would be:

oisd full: at least once every 24 hours
oisd basic: updated daily, but don't be surprised if there are some days it's not
oisd extra: updated only when a domain get's removed from oisd full that's listed in the default lists from either Pi-hole or Adguard (Those will get added to extra)