[Pi-Hole] Ervaringen & discussie

[BigSmurf]

Ik heb sinds enkele weken issues met m’n blacklist. Daar staan met name dingen op voor het blokkeren van alles van mijn LG OLED.

Voorbeeld: (^|\.)lgtvcommon\.com$. Ik zie doodleuk url’s voorbijkomen met dit domein die niet worden geblokkeerd, terwijl dit wel zou moeten. Enable/disable werkt niet.

Waar kan dit aan liggen?

[dss58]

BigSmurf schreef op woensdag 12 oktober 2022 @ 18:13:
Ik heb sinds enkele weken issues met m’n blacklist. Daar staan met name dingen op voor het blokkeren van alles van mijn LG OLED.

Voorbeeld: (^|\.)lgtvcommon\.com$. Ik zie doodleuk url’s voorbijkomen met dit domein die niet worden geblokkeerd, terwijl dit wel zou moeten. Enable/disable werkt niet.

Waar kan dit aan liggen?

heb je

(^|\.)lgtvcommon\.com$.

of

(^|\.)lgtvcommon\.com$

?
de laatste zou moeten werken.

[BigSmurf]

Het laatste, die punt is automatisme om een zin te beëindigen.

[dss58]

@BigSmurf ok, dan zou ik het ook niet weten

[ArieR]

BigSmurf schreef op woensdag 12 oktober 2022 @ 18:13:
Ik heb sinds enkele weken issues met m’n blacklist. Daar staan met name dingen op voor het blokkeren van alles van mijn LG OLED.

Voorbeeld: (^|\.)lgtvcommon\.com$. Ik zie doodleuk url’s voorbijkomen met dit domein die niet worden geblokkeerd, terwijl dit wel zou moeten. Enable/disable werkt niet.

Waar kan dit aan liggen?

Staan ze toegewezen? Kolom naast de vuilnisbak, die stonden bij mij op 'None selected'. Waarschijnlijk na een update gebeurd. Deze heb ik nu toegewezen (door erop te klikken en te kiezen voor All), nu werken de blokkades weer op de TV.

[nero355]

BigSmurf schreef op woensdag 12 oktober 2022 @ 18:13:
Ik heb sinds enkele weken issues met m’n blacklist.

Daar staan met name dingen op voor het blokkeren van alles van mijn LG OLED.

Waar heb je eigenlijk last van i.c.m. welk model TV precies ??

Ik heb namelijk niks extra geblokkeerd, maar wel twee verschillende EULA's niet geaccepteerd en nog wat andere zooi in het Menu/Instellingen uitgezet en daarmee is de TV redelijk rustig qua allerlei dumbass shit zoals die aangeraden zooi in het hoofdmenu aan de linkerkant bij een LG OLED TV uit 2018


Verder vind ik het een dikke aanrader om de Developer Mode aan te zetten en de YouTube Ads Free variant van de YouTube app uit de HomeBrew Channel te installeren die dan al die ellendige reclames voor je blokkeert!

Daarna nog een Cronjob op je Pi-Hole bakkie om de Developer Mode Session Time elke dag te refreshen en gaan met die banaan!

Er is zelfs een Linux Client om de hele Homebrew toestand te beheren en de juiste URL voor je sessie eruit te jatten!

[BigSmurf]

ArieR schreef op woensdag 12 oktober 2022 @ 21:04:
[...]

Staan ze toegewezen? Kolom naast de vuilnisbak, die stonden bij mij op 'None selected'. Waarschijnlijk na een update gebeurd. Deze heb ik nu toegewezen (door erop te klikken en te kiezen voor All), nu werken de blokkades weer op de TV.

Dit was het dus. Gewoon overheen gekeken. Ik hobby er echt te weinig mee merk ik wel. Thanks!

nero355 schreef op woensdag 12 oktober 2022 @ 22:51:
[...]

Waar heb je eigenlijk last van i.c.m. welk model TV precies ??

Ik heb namelijk niks extra geblokkeerd, maar wel twee verschillende EULA's niet geaccepteerd en nog wat andere zooi in het Menu/Instellingen uitgezet en daarmee is de TV redelijk rustig qua allerlei dumbass shit zoals die aangeraden zooi in het hoofdmenu aan de linkerkant bij een LG OLED TV uit 2018

Ik gebruik gewoon de apps voor streaming (OLED C9). Iets met gemak. Dan moet je dus wel die voorwaarden accepteren. Vind ik prima, blokkeer ik de boel zelf wel.

[Buffalo]

Freee!! schreef op dinsdag 11 oktober 2022 @ 21:15:
[...]

Het is altijd DNS Chrome!

Ik was toch te voorbarig denk ik.
Er gebeurd nu iets anders geks. Ik had weer adds in Chrome. Schakel ik de wifi even uit en weer in, geen adds meer.
Maar na een tijdje heb ik dan toch ineens weer adds. Herhaal ik het uit en inschakelen van de wifi, zijn de adds weer weg.

[Airw0lf]

Buffalo schreef op donderdag 13 oktober 2022 @ 09:14:
[...]


Ik was toch te voorbarig denk ik.
Er gebeurd nu iets anders geks. Ik had weer adds in Chrome. Schakel ik de wifi even uit en weer in, geen adds meer.
Maar na een tijdje heb ik dan toch ineens weer adds. Herhaal ik het uit en inschakelen van de wifi, zijn de adds weer weg.

Ik kan het (nog) niet hard maken. Maar ik verdenk google ervan dat ze in al hun producten op onderdelen toch gebruik maken van 8.8.8.8 - en niet alleen voor DNS... Dit blijkt de packet analyzes en een proef met een vuurmuur waarbij 8.8.8.8 op de blacklist werd gezet. Korte tijd later begonnen google-producten op onderdelen te haperen. Of werkten langzamer dan voorheen.

Bij een VPN-server was het helemaal bizar: daar zijn 4 velden voor DNS. Toen ik die alle 4 invulde met een eigen DNS-server kreeg ik op de VPN-client(!) de melding dat er een fout zat in de VPN-config. Bleek het eerst veld te zijn vergeven aan 8.8.8.8. En dit was geeneens een google product...

Dus tja... hoe goed de filters ook zijn... uiteindelijk heeft google/microsoft/apple het laatste woord...

[ Voor 4% gewijzigd door Airw0lf op 13-10-2022 09:33 ]

[jvanhambelgium]

Airw0lf schreef op donderdag 13 oktober 2022 @ 09:29:
[...]


Ik kan het (nog) niet hard maken. Maar ik verdenk google ervan dat ze in al hun producten op onderdelen toch gebruik maken van 8.8.8.8 - en niet alleen voor DNS... Dit blijkt de packet analyzes en een proef met een vuurmuur waarbij 8.8.8.8 op de blacklist werd gezet. Korte tijd later begonnen google-producten op onderdelen te haperen. Of werkten langzamer dan voorheen.

Dat klopt hoor, ik zie het hier op een Android phone & Chromecast ook. Echter op m'n firewall onderschep/NAT ik dat en presenteer ik het richting Pihole.
Ik probeer zoveel mogelijks DoX te blokken (DNS-over-TLS, DNS-over-QUIC, DNS-over-HTTS etc,etc)
Ik merk niet echt dat de Android producten trager/slechter werken.

[deHakkelaar]

Buffalo schreef op donderdag 13 oktober 2022 @ 09:14:
Ik was toch te voorbarig denk ik.
Er gebeurd nu iets anders geks. Ik had weer adds in Chrome. Schakel ik de wifi even uit en weer in, geen adds meer.
Maar na een tijdje heb ik dan toch ineens weer adds. Herhaal ik het uit en inschakelen van de wifi, zijn de adds weer weg.

Het blijft een Oneplus dus nogmaals, had je onderstaande al gecontroleerd?

deHakkelaar schreef op maandag 10 oktober 2022 @ 17:50:
@Buffalo , kun je op je Oneplus weergeven wat de geconfigureerde DNS servers zijn?
Op mijn Samsung telefoon namelijk niet.
Daarvoor moet ik onderstaande app installeren:
https://play.google.com/s...work.andreas.network_info

Kijk ofdat daar in de WiFi tab een non Pi-hole IP staat in het DNS lijstje?

Ik heb al meerder keren gezien dat op Oneplus clients het Google IP @8.8.8.8 automatisch wordt toegevoegd als alleen maar één DNS server via DHCP of IPv6 RA wordt toegewezen.
Vermoedelijk voor redundancy maar dan wel een heel slechte implementatie.

Ter info, als een client meerdere DNS servers krijgt toegewezen dan zal deze afhankelijk vd implementatie een DNS server kiezen afhankelijk van bv reactie snelheid/latency.
Maar hij kan na een poosje ook 1 vd andere DNS servers aanspreken.
Een beetje vergelijkbaar met onderstaande pihole-FTL implementatie:

Improve detection algorithm for determining the "best" forward destination¶

The DNS forward destination determination algorithm in FTLDNS's is modified to be much less restrictive than the original algorithm in dnsmasq. We keep using the fastest responding server now for 1000 queries or 10 minutes (whatever happens earlier) instead of 50 queries or 10 seconds (default values in dnsmasq).

https://docs.pi-hole.net/...-best-forward-destination

[deHakkelaar]

Airw0lf schreef op donderdag 13 oktober 2022 @ 09:29:
[...]


Ik kan het (nog) niet hard maken. Maar ik verdenk google ervan dat ze in al hun producten op onderdelen toch gebruik maken van 8.8.8.8 - en niet alleen voor DNS... Dit blijkt de packet analyzes en een proef met een vuurmuur waarbij 8.8.8.8 op de blacklist werd gezet. Korte tijd later begonnen google-producten op onderdelen te haperen. Of werkten langzamer dan voorheen.

Bij een VPN-server was het helemaal bizar: daar zijn 4 velden voor DNS. Toen ik die alle 4 invulde met een eigen DNS-server kreeg ik op de VPN-client(!) de melding dat er een fout zat in de VPN-config. Bleek het eerst veld te zijn vergeven aan 8.8.8.8. En dit was geeneens een google product...

Dus tja... hoe goed de filters ook zijn... uiteindelijk heeft google/microsoft/apple het laatste woord...

jvanhambelgium schreef op donderdag 13 oktober 2022 @ 11:42:
[...]

Dat klopt hoor, ik zie het hier op een Android phone & Chromecast ook. Echter op m'n firewall onderschep/NAT ik dat en presenteer ik het richting Pihole.
Ik probeer zoveel mogelijks DoX te blokken (DNS-over-TLS, DNS-over-QUIC, DNS-over-HTTS etc,etc)
Ik merk niet echt dat de Android producten trager/slechter werken.

Ik vind julie conlusies/aannames maar matig.
Vergeet niet dat het in dit geval gaat om Chrome en niet 1 of andere app zoals bv Netflix die z'n media/content moet beschermen en reclame inkomsten moet garanderen!
Als Chrome zomaar andere DNS servers gaat aanspreken, dan zou deze totaal ongeschikt zijn om bv in een enterprise omgeving toe te passen.
Plus vergeet ook niet de slechte publiciteit die dit zou genereren.

Het klinkt misschien een beetje bot maar ik heb nog geen bewijs gezien en ook niet op Pi-hole Discourse waar je dan zou verwachten dat er meerdere gebruikers zouden klagen.
En heb dit ook nog nooit zelf meegemaakt met de 4 Android apparaten, van vershillende merken, die hier thuis verbonden zijn (plus m'n oude stukke HTC telefoon ... RIP).
De keren dat ik daarover las lag de reden toch ergens anders zoals DoT, DoH, QUIC, IPv6 RA, Oneplus implementatie of aan de app zelf.

Laat de packets maar zien (tcpdump, Wireshark etc) of de firewall logs?
En vermeldt de apps en versie nummers waar dit optreedt?
Of een link waar dit onomstotelijk wordt bewezen?

[nero355]

BigSmurf schreef op woensdag 12 oktober 2022 @ 23:48:
Ik gebruik gewoon de apps voor streaming (OLED C9). Iets met gemak. Dan moet je dus wel die voorwaarden accepteren. Vind ik prima, blokkeer ik de boel zelf wel.

Ja, maar het zijn er 4 of zo en als je goed oplet hoef je alleen de eerste 2 te accepteren geloof ik!

Buffalo schreef op donderdag 13 oktober 2022 @ 09:14:
Ik was toch te voorbarig denk ik.
Er gebeurd nu iets anders geks. Ik had weer adds in Chrome. Schakel ik de wifi even uit en weer in, geen adds meer.
Maar na een tijdje heb ik dan toch ineens weer adds. Herhaal ik het uit en inschakelen van de wifi, zijn de adds weer weg.

Dat klinkt als een telefoon waarvan zowel de Data verbinding als de WiFi constant AAN staat en dat ding dus bepaalt hoe die naar buiten verbindt : Niet doen! Altijd zelf bepalen!

Airw0lf schreef op donderdag 13 oktober 2022 @ 09:29:
Dus tja... hoe goed de filters ook zijn... uiteindelijk heeft google/microsoft/apple het laatste woord...

En daarom beste mensen :
- Jolla Sailfish
- Ubuntu Touch
- PostmarketOS
- enz.

Weg met die Evil Corp zooi!

Lekker Linux op je telefoon draaien FTW!!!

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:19:
Als Chrome zomaar andere DNS servers gaat aanspreken, dan zou deze totaal ongeschikt zijn om bv in een enterprise omgeving toe te passen.

Dat is dan ook gewoon zo!

Maar helaas willen de gebruikers dat maar niet begrijpen en is dat kreng een soort "Internet Explorer 6.0 v2" geworden dus zitten er wereldwijd applicatiebeheerders/systeembeheerders constant met die rommel te worstelen als er weer eens een chrome://flags optie is verdwenen of veranderd!

Plus vergeet ook niet de slechte publiciteit die dit zou genereren.

Dat zou dus inderdaad eigenlijk wat vaker moet gebeuren!

[deHakkelaar]

nero355 schreef op donderdag 13 oktober 2022 @ 15:28:
Dat is dan ook gewoon zo!

Als dat zo is, dan werkt toch niks meer betrouwbaar op je intranet?

EDIT:

nero355 schreef op donderdag 13 oktober 2022 @ 15:28:
Dat zou dus inderdaad eigenlijk wat vaker moet gebeuren!

Als het werklijk zo was dan stond dat vast al in grote letter op het net.

EDIT2: Ow ik heb het natuurlijk over Chrome waarbij je IT afdeling al de flags en DoH etc heeft rechtgezet met de policy die wordt ge-pushed.

[ Voor 50% gewijzigd door deHakkelaar op 13-10-2022 15:41 ]

[deHakkelaar]

@nero355 , het is niet alleen Chrome waarbij zomaar DoH aan staat.
Ik las ook dat Firefox DoH heeft aan staan als je in de US bent.
Niet hier in Europa.

[Airw0lf]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:31:
[...]

Als dat zo is, dan werkt toch niks meer betrouwbaar op je intranet?

EDIT:

[...]

Als het werklijk zo was dan stond dat vast al in grote letter op het net.

Niet betrouwbaar werken is wat anders als "comes-with-side-effects".

Met in het verlengde:
Waarom zou dit met grote letters op het net gezet worden?
Ooit de gebruiks- en privacy voorwaarden gelezen?
Daar staat enkel in dat "het" transparant moet zijn.
Maar in de Google/Microsoft/Apple-voorwaarden staat dat ze alles van je mogen verzamelen als je gebruik maakt van hun diensten en producten. Er is geen onderscheid tussen privé/zakelijk of tussen gratis/betaald. Er zijn enkel andere rechten als je het ergens niet mee eens bent.

[deHakkelaar]

Airw0lf schreef op donderdag 13 oktober 2022 @ 15:54:
Waarom zou dit met grote letters op het net gezet worden?

Omdat de geruchten/aannames wel veelvuldig op het net geplaatst worden maar een gedegen onderzoek waar dit wordt bewezen niet.

EDIT: Typo
"comes-with-side-effects"

[ Voor 7% gewijzigd door deHakkelaar op 13-10-2022 15:59 ]

[Airw0lf]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:56:
[...]

Omdat de geruchten/aannames wel veelvuldig op het net geplaatst worden maar een gedegen onderzoek waar dit wordt bewezen niet.

EDIT: Typo
"comes-with-side-effects"

Bedankt voor de typo-pointer => aangepast.

Afgelopen week de proef-op-de-som genomen met twee Google Home producten: een Smartclock (Lenovo) en de Hub (Google). Beiden zijn niet te gebruiken als 8.8.8.8 op de blacklist staat: "er is geen Internet - controleer uw wifi en router of neem contact op met uw service provider" (of iets van die strekking).

[ Voor 3% gewijzigd door Airw0lf op 13-10-2022 16:08 ]

[deHakkelaar]

@Airw0lf , dat is alleen maar een check ofdat er een route is naar Internet en daarvoor gebruiken ze 8.8.8.8.
Heeft niks te maken ofdat 8.8.8.8 ook daadwerkleijk wordt gebruikt voor DNS.

[jvanhambelgium]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:19:
[...]


[...]

Ik vind julie conlusies/aannames maar matig.
Laat de packets maar zien (tcpdump, Wireshark etc) of de firewall logs?
En vermeldt de apps en versie nummers waar dit optreedt?
Of een link waar dit onomstotelijk wordt bewezen?

Voila, hieronder net m'n "Chromecast-with-GoogleTV" opgezet. Die krijgt netjes via DHCP een IP + DNS-servers toegewezen. Je zou denken dat deze gewoon strikt gevolgd moeten worden right ??



Bingo, toch zie je m'n Chromecast (internal IP = 172.29.45.22) een aantal packets naar 8.8.8.8 sturen wat ik niet gevraagd heb! Deze worden op m'n Mikrotik onderschept sowieso en geraken nooit rechtstreeks naar 8.8.8.8
Als ik in de Pihole logs kijk betreft het hier tal van lookups, sommige geblocked anderen doorgelaten.

[Airw0lf]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:14:
@Airw0lf , dat is alleen maar een check ofdat er een route is naar Internet en daarvoor gebruiken ze 8.8.8.8.
Heeft niks te maken ofdat 8.8.8.8 ook daadwerkleijk wordt gebruikt voor DNS.

Ja - zou je denken.
Maar als ik de blacklist aanpas naar 8.8.8.8 op TCP/UDP-poort 53 gebeurd er hetzelfde.

En nu?

[nero355]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:14:
Dat is alleen maar een check ofdat er een route is naar Internet en daarvoor gebruiken ze 8.8.8.8.
Heeft niks te maken ofdat 8.8.8.8 ook daadwerkleijk wordt gebruikt voor DNS.

Er zijn genoeg apparaten in de omloop die dan dus gewoon niks doen helaas...

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:52:
Het is niet alleen Chrome waarbij zomaar DoH aan staat.
Ik las ook dat Firefox DoH heeft aan staan als je in de US bent.
Niet hier in Europa.

Dat klopt, maar die heeft ook een prachtige zogenaamde canary domein die DoH automatisch uitzet en die is tegenwoordig standaard Enabled in Pi-Hole

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:31:
Als dat zo is, dan werkt toch niks meer betrouwbaar op je intranet?

EDIT:

[...]

Als het werklijk zo was dan stond dat vast al in grote letter op het net.

EDIT2: Ow ik heb het natuurlijk over Chrome waarbij je IT afdeling al de flags en DoH etc heeft rechtgezet met de policy die wordt ge-pushed.

Je hoeft me niet te geloven, maar toch is het gewoon zo!

Misschien wil @Hero of Time anders wel wat ervaringen met ons delen ??
Daarvan weet ik zeker dat die het met me eens zal zijn!

[Raymond P]

De hardware van Google gaat idd richting fixed DNS. Maar dat is toch niets nieuws

Nest Hub heb ik issues mee gehad tijdens de 1e installatie, ik heb toen m'n redirect uit moeten zetten.
Ik weet dat 'ie iig bij boot een call op 8.8.8.8 doet, waarom heb ik nooit naar gekeken.

Net zoals @jvanhambelgium maakt m'n Mikrotik daar gehakt van.

[deHakkelaar]

@jvanhambelgium , wbt die screenshot, dat kan best de check zijn die @Airw0lf hierboven omschreef om te controleren ofdat ze een route hebben naar Internet.
Kun je in die logs zien wat de packet inhoud is eg wat voor DNS verzoekje er wordt gemaakt?
En weet je ook welke app dit verkeer genereerd?
Zonder die gegevens kun je nog niks uitsluiten.

[deHakkelaar]

Airw0lf schreef op donderdag 13 oktober 2022 @ 16:18:
Ja - zou je denken.
Maar als ik de blacklist aanpas naar 8.8.8.8 op TCP/UDP-poort 53 gebeurd er hetzelfde.

En nu?

Ik weet niet precies hoe die Internet verbindingscontrole werkt.
Mogelijk is dat gewoon via DNS.

[jvanhambelgium]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:14:
@Airw0lf , dat is alleen maar een check ofdat er een route is naar Internet en daarvoor gebruiken ze 8.8.8.8.
Heeft niks te maken ofdat 8.8.8.8 ook daadwerkleijk wordt gebruikt voor DNS.

En waarom zie ik na 7 minuten, terwijl er beneden op TV al vrolijk een serie'je aan het spelen is, nogmaals zo'n "check" vertrekken naar 8.8.8.8 ?

Heb nog geen effectieve packet-capture genomen om te zien WAT er nu exact in zou zitten. Mischien is het enkel connectivy-check idd.

[deHakkelaar]

nero355 schreef op donderdag 13 oktober 2022 @ 16:19:
Dat klopt, maar die heeft ook een prachtige zogenaamde canary domein die DoH automatisch uitzet en die is tegenwoordig standaard Enabled in Pi-Hole

Nadeel van dat kanarie domein is dat als de DoH instelling handmatig is gewijzigd, dan werkt de kanarie niet.

[deHakkelaar]

jvanhambelgium schreef op donderdag 13 oktober 2022 @ 16:27:
En waarom zie ik na 7 minuten, terwijl er beneden op TV al vrolijk een serie'je aan het spelen is, nogmaals zo'n "check" vertrekken naar 8.8.8.8 ?

Heb nog geen effectieve packet-capture genomen om te zien WAT er nu exact in zou zitten. Mischien is het enkel connectivy-check idd.

Ik heb echt geen flauw idee hoe dat geimplementeerd is.

Er kan veel beweerd worden maar ik heb nog geen 1 keer een gedegen onderzoek gelezen ofdat Chrome zomaar 8.8.8.8 gaat aanspreken naast de DNS servers die al zijn toegewezen.
Behalve voor Oneplus apparaten met een hun vreemde DNS implementatie.

[ Voor 0% gewijzigd door deHakkelaar op 13-10-2022 16:56 . Reden: typo ]

[nero355]

jvanhambelgium schreef op donderdag 13 oktober 2022 @ 16:27:
En waarom zie ik na 7 minuten, terwijl er beneden op TV al vrolijk een serie'je aan het spelen is, nogmaals zo'n "check" vertrekken naar 8.8.8.8 ?

Omdat alle Android en Android TV apparaten dat nou eenmaal helaas doen...

Zo doen ook alle Microsoft produkten een soortgelijke check heel de dag door...

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:29:
Nadeel van dat kanarie domein is dat als de DoH instelling handmatig is gewijzigd, dan werkt de kanarie niet.

Dan werkt het dus precies zoals het ontworpen is door Mozilla als ik het me goed herinner

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:32:
Er kan veel beweerd worden maar ik heb nog geen 1 keer een gedegen onderzoek gelezen ofdat Chrome zomaar 8.8.8.8 gaat aanspreken naast de DNS servers die al zijn toegewezen.
Behalve voor Oneplus apparaten met een hun vreemde DNS implementatie.

Het QUIC protocol omzeilt sowieso je DNS Server nadat de browser eenmaal met de webserver verbinding heeft opgebouwd dus er zitten gewoon serieus veel opties in die je moet slopen om stiekem verkeer buiten jouw netwerkomgeving te voorkomen!

[jvanhambelgium]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:32:
[...]

Ik heb echt geen flauw idee hoe dat geimplementeerd is.

Er kan veel beweerd worden maar ik heb nog geen 1 keer een gedegen onderzoek gelezen ofdat Chrome zomaar 8.8.8.8 gaat aanspreken naast de DNS servers die al zijn toegewezen.
Behalve voor Oneplus apparaten met een hun vreemde DNS implementatie.

Je hebt een punt sowieso. Indien het consistent voor "lookups" zou gebruikt worden zou ik wel wat meer packets zien voorbij vliegen als hetgeen ik zie. Dat zou absoluut geen steek houden.
Als ik Google was zou ik daarbij zelfs poort 53 niet meer gebruiker maar iets sneaky op 443 doen ;-) en dan is het wel wat lastiger de content te achterhalen. Maar dan zouden er wel wat meer mensen beginnen roepen denk ik

[deHakkelaar]

@jvanhambelgium , ik ben er gewoon nog niet zeker van.
Vaak als je je verkeer gaat analyseren en je gaat te diep voor je eigen kennis niveau, dan kun je spoken zien

En ja Google en anderen doen dat al via DoH.
Daar gaat DNS en HTML allemaal over dezelfde poort 443 TCP (EDIT: encrypted behalve de SNI).

[ Voor 15% gewijzigd door deHakkelaar op 13-10-2022 16:47 ]

[Airw0lf]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:26:
[...]

Ik weet niet precies hoe die Internet verbindingscontrole werkt.
Mogelijk is dat gewoon via DNS.

Zou inderdaad ook nog kunnen - point-taken.

Ik ga verder ook geen tijd steken in het verzamelen van bewijslast.
Voor mij is het sop de kool niet waard... als je bedoeld wat ik begrijp...
En zelfs als het zo is kan ik er weinig aan doen.

[deHakkelaar]

@Airw0lf , ik zou graag iemand dit eens grondig zien uitzoeken.
Maar ik ga het ook niet doen omdat bij mij alles gewoon perfect werkt

[Airw0lf]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 16:51:
@Airw0lf , ik zou graag iemand dit eens grondig zien uitzoeken.
Maar ik ga het ook niet doen omdat bij mij alles gewoon perfect werkt

Maar dan heb je het eigenlijk toch al uitgezocht?

Maar vooruit - ik zal eens kijken wat Splunk er van vindt... wordt vervolgt.

[borft]

wat gebeurt er eigenlijk als je verkeer naar 8.8.8.8 op je router met iptables naar pi-hole stuurt? dan zou zowel ping als dns gewoon moeten werken

[deHakkelaar]

Ik denk dat ik wel een redelijk goede test heb om te controleren ofdat mogelijk 8.8.8.8 of een ander DNS IP wordt aangesproken in Chrome.
Zorg dat je client een enkele DNS IP krijgt toegewezen waar niks achter zit (gewoon een ongebruikt IP).
Als je dan nog op deze client het Internet op kan browsen, dan weet je dat ie ergens anders z'n DNS verzoekjes neerlegt.
Moet je niet zoiets hebben als een DNS filter op je firewall.

[Raven]

nero355 schreef op donderdag 13 oktober 2022 @ 15:28:
[...]

En daarom beste mensen :
- Jolla Sailfish
- Ubuntu Touch
- PostmarketOS
- enz.

Weg met die Evil Corp zooi!

Lekker Linux op je telefoon draaien FTW!!!

offtopic:
* Raven kijkt naar zijn PineTab met Mobian

[deHakkelaar]

borft schreef op donderdag 13 oktober 2022 @ 17:14:
wat gebeurt er eigenlijk als je verkeer naar 8.8.8.8 op je router met iptables naar pi-hole stuurt? dan zou zowel ping als dns gewoon moeten werken

Sommige routers hebben daar al een instelling voor:
https://github.com/RMerl/asuswrt-merlin.ng/wiki/DNS-Filter

Maar dan moet je wel een uitzondering maken voor de Pi-hole host anders creeer je (EDIT: mogelijk) een DNS loop en gaat alles brak.

[Raymond P]

Heb een vinkje bij log gezet en ben een film gaan kijken...



Chromecasts, TV's, droids, speaker en nest hub zijn allemaal gewoon actief op 53...
Amazon, Disney+, Netflix vooral als ik de timestamps laat overlappen met querylog (Dus niet noodzakelijk Google subsystem die de calls doet).

edit: de nest mini doet (idle) enkel query voor *.ntpns.org.

[ Voor 8% gewijzigd door Raymond P op 13-10-2022 19:53 ]

[nero355]

borft schreef op donderdag 13 oktober 2022 @ 17:14:
wat gebeurt er eigenlijk als je verkeer naar 8.8.8.8 op je router met iptables naar pi-hole stuurt? dan zou zowel ping als dns gewoon moeten werken

Zitten wat haken en ogen aan :
- Regulier DNS verkeer kan je via DNAT/SNAT omleiden.
- De verschillende "pings" die Google produkten doen zouden dan weleens kunnen mislukken, want die verwachten naast het zeer simpele antwoord van de andere kant namelijk ook nog eens een bepaald Certificaat van Google zelf...

Dat laatste geldt trouwens ook voor produkten van Microsoft en nog een aantal anderen!

[Raymond P]

@borft Zoals hierboven, enkel port 53 bereik je al best veel mee.
Cert pinning heeft een keerzijde.

Wat voor mij belangrijk is is dat ik alle telemetrie eruit filter, en dat gaat best prima met pi-hole.
M'n TV (Sony) relayed elke actie door naar een logserver bijvoorbeeld, dat ervaar ik als extreem vervelend.

[deHakkelaar]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 17:18:
Ik denk dat ik wel een redelijk goede test heb om te controleren ofdat mogelijk 8.8.8.8 of een ander DNS IP wordt aangesproken in Chrome.
Zorg dat je client een enkele DNS IP krijgt toegewezen waar niks achter zit (gewoon een ongebruikt IP).
Als je dan nog op deze client het Internet op kan browsen, dan weet je dat ie ergens anders z'n DNS verzoekjes neerlegt.
Moet je niet zoiets hebben als een DNS filter op je firewall.

Ok, ik heb bovenstaande check uitgevoerd.
Ik heb onderstaande DHCP optie aangemaakt voor m'n Samsung telefoon met twee dode DNS IP's:

pi@ph5a:~ $ sudo nano /etc/dnsmasq.d/99-my-settings.conf
dhcp-host=0C:2F:B0:XX:XX:XX,set:dood
dhcp-option=tag:dood,option:dns-server,10.0.0.98,10.0.0.99

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

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

En op m'n telefoon de vliegtuig modes aan en uit gezet om de DHCP lease te vernieuwen.

De "Network Info" app geeft netjes die twee DNS servers weer in de WiFi tab.
Maar ik kan nu niet meer met Chrome op het Internet browsen "This site cant be reached".
Wel kan ik nog naar Pi-hole browsen op:

code:

http://10.0.0.4/admin

EDIT: En:

code:

https://1.1.1.1/

[ Voor 1% gewijzigd door deHakkelaar op 13-10-2022 21:05 . Reden: typo ]

[nero355]

Raymond P schreef op donderdag 13 oktober 2022 @ 20:20:
M'n TV (Sony) relayed elke actie door naar een logserver bijvoorbeeld, dat ervaar ik als extreem vervelend.

Moet jij niet misschien ook wat EULA's eruit gooien toevallig

Sony TV's gebruiken Android TV dus misschien is het niet eens mogelijk, maar kijk er in ieder geval effe naar!

[Raymond P]

@nero355 Tjah, er draait bijvoorbeeld een samba tv service op en ondanks dat die EULA niet geaccepteerd is én vinkje uit staat zie ik nog steeds pogingen tot resolven.
M'n vorige Bravia (non-android) deed (lees: probeerde) het ook erg actief.

Ik ben bekend met de perikelen. Het punt dat ik mij er druk om maak ben ik lang geleden al gepasseerd.
Als ik het zie gebeuren doe ik m'n uiterste best het tegen te gaan, en meestal lukt dat prima.

Het probleem is het multi-account gebeuren in Android TV, denk ik. M'n vriendin kan (en mag) dat geaccepteerd hebben natuurlijk...

[Webgnome]

Ach het zal niet de eerste keer zijn dat een apparaat netjs om de eula vraagt om er volgens compleet niks mee te doen. Heb hier om de zoveel weken een spike van mijn robotstofzuiger die als een malle bepaalde domeinen probeert te resolven. Heeft die even pech dat pihole er tussen zit Gaat om een 14k aanvragen in een paar uur elke x weken. En elke keer resolved ie niks.

[ Voor 13% gewijzigd door Webgnome op 13-10-2022 21:57 ]

[jpgview]

lang geleden...

sinds gisteren lees ik dat mensen devices ervan verdenken dat:

- een hardcoded dns (meestal 8.8.8.8) gebruiken en dus pihole omzeilen.
- mogelijks (o)DoH gebruiken en dus pihole omzeilen.
- QUIC protocol gebruiken om een en ander te omzeilen.

Hier en daar lees ik dat dit moeilijk te bewijzen valt.

hardcoded dns: Catching Firewall redirected DNS requests, hier (PDF!).

(o)DoH: Block DNS over HTTPS (DoH), using pfsense, hier (PDF!), mogelijke opties:
- firewal rules
- response policy zone (RPZ), hier (PDF!).
- pihole blocklist

QUIC: firewall rules block port 80 & 443 (UDP only) rules actief sinds dec 2021, geen problemen, een uitzondering op QUIC 443 UDP voor een mobile met whatsapp (gebruikt voor callmebot)

edit
Microsoft internet connectivity check, lees hier. Resultaat is wel dat je niet langer internet conectivity checked, maar wel de pihole lighttpd (web server) response.
/edit

enjoy...

[ Voor 11% gewijzigd door jpgview op 14-10-2022 09:12 . Reden: added NCSI ]

[Buffalo]

deHakkelaar schreef op donderdag 13 oktober 2022 @ 15:15:
[...]

Het blijft een Oneplus dus nogmaals, had je onderstaande al gecontroleerd?

[...]

Ter info, als een client meerdere DNS servers krijgt toegewezen dan zal deze afhankelijk vd implementatie een DNS server kiezen afhankelijk van bv reactie snelheid/latency.
Maar hij kan na een poosje ook 1 vd andere DNS servers aanspreken.
Een beetje vergelijkbaar met onderstaande pihole-FTL implementatie:

[...]

https://docs.pi-hole.net/...-best-forward-destination

De Network Info app geïnstalleerd. Hier zie ik 2x het IP van mijn Pihole staan. Maar deze kan ik ook zien bij de Wifi settings zelf en ook wijzigen.
Zijn er in die Network Info app nog meer belangrijke waardes om te checken?

nero355 schreef op donderdag 13 oktober 2022 @ 15:28:
[...]

Dat klinkt als een telefoon waarvan zowel de Data verbinding als de WiFi constant AAN staat en dat ding dus bepaalt hoe die naar buiten verbindt : Niet doen! Altijd zelf bepalen!

[...]

Getest, met alleen mobiele data uitzetten en ook de sim volledig uitschakelen maakt geen verschil helaas. Wellicht dat er nog een vertraging zit dat Pihole het weer opppakt?
Daarbij: Als het wel zou werken moet ik steeds handmatig schakelen tussen wifi en mobiele data, dat is ook niet zo handig.

nero355 schreef op donderdag 13 oktober 2022 @ 15:28:
En daarom beste mensen :
- Jolla Sailfish
- Ubuntu Touch
- PostmarketOS
- enz.

Weg met die Evil Corp zooi!

Lekker Linux op je telefoon draaien FTW!!!

Geldt dit ook voor Lineage OS? Het staat namelijk al een tijdje op mijn lijst om die op mijn Oneplus te installeren.

[nero355]

Buffalo schreef op vrijdag 14 oktober 2022 @ 12:17:
Geldt dit ook voor Lineage OS?

Het staat namelijk al een tijdje op mijn lijst om die op mijn Oneplus te installeren.

Helaas wel : https://duckduckgo.com/?q=deGoogle+LineageOS

[deHakkelaar]

Buffalo schreef op vrijdag 14 oktober 2022 @ 12:17:
De Network Info app geïnstalleerd. Hier zie ik 2x het IP van mijn Pihole staan. Maar deze kan ik ook zien bij de Wifi settings zelf en ook wijzigen.

Ok, ik kan deze niet zien in de wifi settings.
Ik moet dan omschakelen naar static IP ipv via DHCP en dan worden de veldjes al automatisch ingevuld met de eerder verkregen DNS IP's via DHCP.

Als je alleen twee maal het Pi-hole IP ziet voor DNS dan moet dit aspect goed zitten volgens mij.

Buffalo schreef op vrijdag 14 oktober 2022 @ 12:17:
Zijn er in die Network Info app nog meer belangrijke waardes om te checken?

Ach er staat wat meer info dan die in de Android settings zelf worden weergegen.
Kan soms handig zijn.

Wbt dat er nog ads doorkomen, ik heb geen idieeen meer.
Kun je mogelijk hier een linkje plaatsen waar je nog ads ziet?

[Buffalo]

deHakkelaar schreef op vrijdag 14 oktober 2022 @ 22:52:
[...]

Ok, ik kan deze niet zien in de wifi settings.
Ik moet dan omschakelen naar static IP ipv via DHCP en dan worden de veldjes al automatisch ingevuld met de eerder verkregen DNS IP's via DHCP.

Als je alleen twee maal het Pi-hole IP ziet voor DNS dan moet dit aspect goed zitten volgens mij.

[...]

Ach er staat wat meer info dan die in de Android settings zelf worden weergegen.
Kan soms handig zijn.

Wbt dat er nog ads doorkomen, ik heb geen idieeen meer.
Kun je mogelijk hier een linkje plaatsen waar je nog ads ziet?

Ik kan op mijn Oneplus kiezen in Wifi settings voor DHCP of statisch. Hij stond op statisch en kon daar 2 DNS servers invullen. Hier heb ik 2x het IP van mijn Pihole ingevuld. Dit zie ik ook in Network Info.

Als ik Wifi settings op DHCP zet zie ik ook niets meer in de Wifi settings en zie ik in Network Info bij DNS1 het IP adres van mijn Pihole en bij DNS2 staat 0.0.0.0

In beiden situaties worden er even een tijdje adds geblokt. Ook heb ik de combinatie mobiele data aan/uit geprobeerd. Mar dit geeft hetzelfde resultaat.

Eigenlijk op alle websites waar ik op surf zie ik adds. Bijvoorbeeld ad.nl, nu.nl. Maar ook via Google Now (als dat nog zo heet, op het hoofdscherm naar rechts schuiven). Tussen de suggesties zie ik dan geen ads, maar wel op websites waar je dan op klikt.

De conclusie is denk ik dat het ofwel aan Oneplus ligt of aan Chrome op Android. Dit laatste is dan toch weer vreemd, omdat zoals eerder gemeld het op een Sony Xperia 10 mark 4 wel goed gaat.
Wifi even uit en weer aan lost het probleem dan wel op voor een tijdje.

EDIT: Als ik naar de logs kijk in Pihole op het IP adres van mijn telefoon word er toch wel veel geblokt, maar ook veel doorgelaten. Hier heb ik nog nooit iets aan gewijzigd omdat het in het verleden altijd goed werkte. Kan ik ervanuit gaan dat wat in die log rood is ook echt gelokt hoort te worden en wat groen is ook echt doorgelaten moet worden?

[ Voor 9% gewijzigd door Buffalo op 15-10-2022 11:36 ]

[Church of Noise]

jpgview schreef op vrijdag 14 oktober 2022 @ 09:02:
lang geleden...

sinds gisteren lees ik dat mensen devices ervan verdenken dat:

- een hardcoded dns (meestal 8.8.8.8) gebruiken en dus pihole omzeilen.
- mogelijks (o)DoH gebruiken en dus pihole omzeilen.
- QUIC protocol gebruiken om een en ander te omzeilen.

Hier en daar lees ik dat dit moeilijk te bewijzen valt.

hardcoded dns: Catching Firewall redirected DNS requests, hier (PDF!).

(o)DoH: Block DNS over HTTPS (DoH), using pfsense, hier (PDF!), mogelijke opties:
- firewal rules
- response policy zone (RPZ), hier (PDF!).
- pihole blocklist

QUIC: firewall rules block port 80 & 443 (UDP only) rules actief sinds dec 2021, geen problemen, een uitzondering op QUIC 443 UDP voor een mobile met whatsapp (gebruikt voor callmebot)

edit
Microsoft internet connectivity check, lees hier. Resultaat is wel dat je niet langer internet conectivity checked, maar wel de pihole lighttpd (web server) response.
/edit

enjoy...

Lang geleden inderdaad!

Ik ga je internet connectivity check approach eens gebruiken, met als verschil dat ik in de local DNS settings van pi-hole het adres van m'n Pi-Hole ga ingeven voor

code:

dns.msftncsi.com

en de andere die je in je cname lijst hebt staan, of gaat dat niet lukken?
Reden van deze aanpak is dat m'n werk-laptop helemaal dichtgetimmerd is en ik dus quasi geen instellingen kan bijsturen

Is QUIC op zich een probleem als de DNS queries door Pi-Hole worden geresolved? (ik ken niet genoeg van QUIC om heel eerlijk te zijn)

[Raymond P]

@Church of Noise https://www.rfc-editor.org/rfc/rfc9250
M.a.w. Nog een protocol om te resolven.

QUIC is op zich een mooie ontwikkeling imho.
edit: afaik is dat nog niet in gebruik...

[ Voor 13% gewijzigd door Raymond P op 15-10-2022 12:08 ]

[jpgview]

Church of Noise schreef op zaterdag 15 oktober 2022 @ 11:51:
of gaat dat niet lukken?

géén idee, ik heb het geimplementeerd, zoals in het forum topic beschreven is en het werkt, proberen maar zou ik zeggen...

Church of Noise schreef op zaterdag 15 oktober 2022 @ 11:51:
[Is QUIC op zich een probleem als de DNS queries door Pi-Hole worden geresolved? (ik ken niet genoeg van QUIC om heel eerlijk te zijn)

De reden waarom ik QUIC blokkeer is het bestaan van DOQ (DNS over QUIC). Ok, default port 853 (bij mij nooit allowed - beperkte lijst van toegelaten poorten op de firewall) maar de RFC laat toe DOQ op een andere poort te gebruiken, wat de mogelijkheid openhoud het op poort 443 te doen. Die poort is uiteraard wel mogelijk (anders gebeurd er niet veel meer). Een iot device zou dus DOQ op poort 443 kunnen gebruiken, om DNS resolving van hun eigen domains toe te laten, en zo toch verbinding te maken, om stats e.d. te verzamelen. Dus, block QUIC port 80 en 443...

de rule doet af en toe zijn ding, niet noodzaklijk door DOQ veroorzaakt...

[Church of Noise]

Dank!
Ik had je oude post er nog even bij gehaald

jpgview schreef op maandag 6 juni 2022 @ 23:35:
Ik las hier (AdGuard Home 0.107.7 - af en toe lezen welke nieuwe dingen zij verzinnen/toevoegen) dat RFC9250 (DoQ - DNS over QuiC) geacepteerd is, wat natuurlijk niet goed is voor pihole gebruikers, zodra er apps, browsers, devices te voorschijn komen die dit kunnen gebruiken.

Na wat zoeken vond ik hier een document, waarin de mogelijke poorten staan vermeld:

<quote>
using all proposed ports (UDP/784, /853, and /8853)
</quote>

Er slingert ergens een pfsense (netgate) document rond, met aanbevelingen voor een firewall setup. Het aanbevolen princiepe: block everything, allow what you need.
- Wie zijn firewall op die manier heeft ingericht hoeft eigelijk alleen maar te controleren of de aangegeven poorten niet voor een of andere reden toegelaten zijn.
- Wie echter alles toelaat, en alleen specifieke dingen blocked, heeft waarschijnlijk al een block toegevoegd voor TCP port 853 (DoT). Nakijken of aanpassen, nu ook dus UDP + block rule (UDP only) voor de twee andere poorten (784 en 8853)

Voor zover ik alles correct lees en begrijp, zou dit voldoende zijn om DoQ queries te blokkeren.

Toch even aangeven dat ik reeds lange tijd QUIC block ( UDP port 80 & 443), zonder problemen; slechts een uitzondering: devices met whatsapp (port UDP/443), reden: voice calls. Weer een voordeel van signal, waarvoor helemaal geen uitzonderingen hoeven gemaakt te worden.

[nero355]

Buffalo schreef op zaterdag 15 oktober 2022 @ 11:30:
Eigenlijk op alle websites waar ik op surf zie ik adds.
Bijvoorbeeld ad.nl, nu.nl.

Op welke manier ?! Browser/App/Iets anders ?!

Maar ook via Google Now (als dat nog zo heet, op het hoofdscherm naar rechts schuiven). Tussen de suggesties zie ik dan geen ads, maar wel op websites waar je dan op klikt.

Dat is dan weer iets dat afhankelijk is van de Android System WebView functionaliteit als het goed is en dat is dit spul : https://www.makeuseof.com/what-is-android-system-webview/

Ik heb echter geen idee of de Settings van Chrome daarmee worden gesynct of niet, want je kan tenslotte Android System WebView op je telefoon/tablet hebben zonder Google Chrome geïnstalleerd te hebben staan!

Het wordt ook gebruikt voor WiFi Portals en zo...

De conclusie is denk ik dat het ofwel aan Oneplus ligt of aan Chrome op Android. Dit laatste is dan toch weer vreemd, omdat zoals eerder gemeld het op een Sony Xperia 10 mark 4 wel goed gaat.
Wifi even uit en weer aan lost het probleem dan wel op voor een tijdje.

Stupid question : Heb je wel elke keer de volledige Cache geleegd van je browser voordat je gaat testen

Als ik naar de logs kijk in Pihole op het IP adres van mijn telefoon word er toch wel veel geblokt, maar ook veel doorgelaten.
Hier heb ik nog nooit iets aan gewijzigd omdat het in het verleden altijd goed werkte.

Kan ik ervanuit gaan dat wat in die log rood is ook echt gelokt hoort te worden en wat groen is ook echt doorgelaten moet worden?

Dat zou inderdaad zo moeten zijn!

Raymond P schreef op zaterdag 15 oktober 2022 @ 12:07:
QUIC is op zich een mooie ontwikkeling imho.

No it's not!

QUICK moet dood en gauw een beetje!

Typisch gevalletje van een "Double-edged sword"

[deHakkelaar]

Buffalo schreef op zaterdag 15 oktober 2022 @ 11:30:
EDIT: Als ik naar de logs kijk in Pihole op het IP adres van mijn telefoon word er toch wel veel geblokt, maar ook veel doorgelaten. Hier heb ik nog nooit iets aan gewijzigd omdat het in het verleden altijd goed werkte. Kan ik ervanuit gaan dat wat in die log rood is ook echt gelokt hoort te worden en wat groen is ook echt doorgelaten moet worden?

Ja daar kun je vanuit gaan.
Als ik naar nu.nl browse dan zie ik bv het volgende in de logs:

pi@ph5a:~ $ pihole -t
[..]
Oct 15 18:21:02 dnsmasq[649]: query[A] fonts.googleapis.com from 10.0.0.11
Oct 15 18:21:02 dnsmasq[649]: forwarded fonts.googleapis.com to 127.0.0.1
Oct 15 18:21:02 dnsmasq[649]: reply fonts.googleapis.com is 172.217.168.234
[..]
Oct 15 18:21:02 dnsmasq[649]: query[A] advertising-cdn.dpgmedia.cloud from 10.0.0.11
Oct 15 18:21:02 dnsmasq[649]: gravity blocked advertising-cdn.dpgmedia.cloud is 0.0.0.0

Die eerste fonts.googleapis.com wordt niet geblokkeerd en je krijgt netjes een valide IP terug namelijk 172.217.168.234.
Die tweede advertising-cdn.dpgmedia.cloud wordt wel geblokkeerd en je krijgt 0.0.0.0 terug als antwoord.

Dit kun je valideren op je PC met onderstaande waarbij 10.0.0.4 mijn Pi-hole host is:

C:\>nslookup -type=a fonts.googleapis.com 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Non-authoritative answer:
Name:    fonts.googleapis.com
Address:  172.217.168.234

C:\>nslookup -type=a advertising-cdn.dpgmedia.cloud 10.0.0.4
Server:  pi.hole
Address:  10.0.0.4

Name:    advertising-cdn.dpgmedia.cloud
Address:  0.0.0.0

En je kunt controleren ofdat een domein in 1 vd blocklists staat met onder op Pi-hole:

pi@ph5a:~ $ pihole -q fonts.googleapis.com
  [i] No results found for fonts.googleapis.com within the block lists

pi@ph5a:~ $ pihole -q advertising-cdn.dpgmedia.cloud
 Match found in https://raw.githubusercontent.com/StevenBlack/hosts/master/hosts:
   advertising-cdn.dpgmedia.cloud

[Kabouterplop01]

Quick is zeker lelijk, snel uitzetten die rommel. Iedereen probeert te zorgen dat er zo min mogelijk amplification attacks mogelijk zijn, nee dan ga je udp/80 open zetten, Google is knetterg...arrogant!

[Pierre]

deHakkelaar schreef op zondag 9 oktober 2022 @ 18:45:
@Pierre , komt vaak langs:

https://discourse.pi-hole...ver-1-1-1-1-to-1232/56876

Is niks ernstigs maar packet size omlaag werkt efficienter.

@deHakkelaar

Beetje een late reply, maar hoe ga ik die packet size omlaag brengen?
CLI shell ben ik niet zo thuis in ja PiHole -up dat snap ik nog net

[deHakkelaar]

@Pierre , door een nieuw config bestandje aan te maken met:

code:

sudo tee /etc/dnsmasq.d/99-edns.conf <<< 'edns-packet-max=1232'

Herstarten om toe te passen:

code:

pihole restartdns

EDIT: Ow en in Linux noemen we het niet CLI maar een shell of een Bash prompt

[ Voor 17% gewijzigd door deHakkelaar op 19-10-2022 08:43 ]

[Trunksmd]

Ik had tot gisteren mijn pi-hole en unbound in gebruik (geinstalleerd met guide op de pi-hole website). Werkte perfect. Pi-hole had static ip en DHCP server actief (DHCP router uit). static IPs buiten de range van de DHCP server.
Gisteren kreeg ik een nieuwe router van mijn ISP. En toen begon de ellende. Ik vergat natuurlijk ten eerste de DHCP server uit te zetten van pi-hole, want die van de nieuwe ISP router staat standaard aan. Uiteindelijk had ik mijn router (DHCP uit) geconfigureerd en pi-hole werkte. Echter ik kan niet meer op de webpagina van pi-hole en ik kan ook niet meer via SSH naar binnen. Lokaal kan in wel via CLI inloggen. En ping x.x.x.x veel packet drops. ping google.com werkt niet meer. Hoe kan ik dit oplossen en niet meteen nieuwe sd kaart installeren?

[deHakkelaar]

@Trunksmd , op wat voor hardware?
Welke distro en versie?
In Docker of bare metal?
Hoe verbonden, via koper, glas of wifi?

EDIT: Hieronder hoe je handmatig IP instellingen kunt wijzigen.
Maar dit is niet reboot persistent.
Daarvoor moet je uitvinden wat voor network manager voor jou distro wordt toegepast.
https://discourse.pi-hole...-linux-router-rpi/56880/9

[ Voor 69% gewijzigd door deHakkelaar op 19-10-2022 09:11 ]

[Trunksmd]

Sorry, niet verteld. Bare metal. Raspberry pi 3B met RaspberripiOS lite. En dat is het enige wat deze raspberry pi doet. Direct via kabel aan router verbonden.
ipadres is nooit veranderd. gecontroleerd met ifconfig

[ Voor 44% gewijzigd door Trunksmd op 19-10-2022 09:16 ]

[deHakkelaar]

@Trunksmd , en welke distro heb je geflashed naar de SD?
Ow zag de edit te laat.
Momentje!

[ Voor 27% gewijzigd door deHakkelaar op 19-10-2022 09:15 ]

[Trunksmd]

deHakkelaar schreef op woensdag 19 oktober 2022 @ 09:14:
@Trunksmd , en welke distro heb je geflashed naar de SD?

RaspberripiOS lite

Ah, net gelezen dat ifconfig is depreciated. Zal het straks nog eens bekijken met iproute2

[ Voor 19% gewijzigd door Trunksmd op 19-10-2022 09:18 ]

[deHakkelaar]

@Trunksmd , gedetecteerde Links/interfaces weergeven incl MAC:

code:

ip -br l

Huidige IP Adressen weergeven:

code:

ip -br a

Huidige Routes weergeven:

code:

ip r

Je ontdekte buren (Neighbors) weergeven:

code:

ip n

Pi-OS/Raspbian hanteert dhcpcd als default network manager.
Bij mij staan de statische IP gegevens in onderstaande bestandje helemaal onderaan geconfigureerd:

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=home.dehakkelaar.nl
  static domain_name_servers=10.0.0.1

Als je wat wijzigt in bovenstaande bestandje kun je proberen ofdat onderstaande volstaat maar zoniet, rebooten:

code:

sudo service dhcpcd restart

EDIT: Ow en controleren wat ie allemaal doet met:

code:

journalctl --no-pager --full -u dhcpcd

OW2: Als je wat wijzigt, zul je mogelijk ook Pi-hole daarvan op de hoogte moeten stellen met onder en dan "reconfigure" selecteren.
Maar hoef je pas te doen als netwerk weer hersteld is en je weer met SSH naar binnen kunt.

code:

pihole -r

[ Voor 20% gewijzigd door deHakkelaar op 19-10-2022 22:05 . Reden: typo ]

[nero355]

Pierre schreef op woensdag 19 oktober 2022 @ 07:44:
Beetje een late reply, maar hoe ga ik die packet size omlaag brengen?
CLI shell ben ik niet zo thuis in ja PiHole -up dat snap ik nog net

Wat ik al zei : nero355 in "[Pi-Hole] Ervaringen & discussie"
Jouw Unbound config is outdated!

Dus Copy -> Paste effe de nieuwe in je config file : https://docs.pi-hole.net/guides/dns/unbound/

[Pierre]

nero355 schreef op woensdag 19 oktober 2022 @ 15:56:
[...]



Wat ik al zei : nero355 in "[Pi-Hole] Ervaringen & discussie"
Jouw Unbound config is outdated!

Dus Copy -> Paste effe de nieuwe in je config file : https://docs.pi-hole.net/guides/dns/unbound/

Hoe doe ik dat de hulp wordt erg gewaardeerd trouwens.

[ed1703]

Pierre schreef op woensdag 19 oktober 2022 @ 16:49:
[...]

Hoe doe ik dat de hulp wordt erg gewaardeerd trouwens.

Het staat in de link die @nero355 geeft..
Leesvoer en edit /etc/unbound/unbound.conf.d/pi-hole.conf of maak deze zelfs compleet nieuw aan.
Mits je daar geen speciale dingen in hebt staan natuurlijk.

Er zit zelfs een copy-knop op die pagina om het je makkelijk te maken.

[deHakkelaar]

Pierre schreef op woensdag 19 oktober 2022 @ 16:49:
Hoe doe ik dat de hulp wordt erg gewaardeerd trouwens.

Heb je wel unbound draaien dan want dat lees ik nergens of heb ik gemist?

code:

systemctl is-active unbound

EDIT: Mocht unbound toch active zijn en heb je deze opgezet volgens de officiele Pi-hole Unbound gids:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

[ Voor 25% gewijzigd door deHakkelaar op 19-10-2022 21:27 ]

[Trunksmd]

deHakkelaar schreef op woensdag 19 oktober 2022 @ 09:24:
@Trunksmd , gedetecteerde Links/interfaces weergaven incl MAC:

code:

ip -br l

Huidige IP Adressen weergeven:

code:

ip -br a

Huidige Routes weergeven:

code:

ip r

Je ontdekte buren (Neighbors) weergeven:

code:

ip n

Pi-OS/Raspbian hanteert dhcpcd als default network manager.
Bij mij staan de statische IP gegevens in onderstaande bestandje helemaal onderaan geconfigureerd:

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=home.dehakkelaar.nl
  static domain_name_servers=10.0.0.1

Als je wat wijzigt in bovenstaande bestandje kun je proberen ofdat onderstaande volstaat maar zoniet, rebooten:

code:

sudo service dhcpcd restart

EDIT: Ow en controleren wat ie allemaal doet met:

code:

journalctl --no-pager --full -u dhcpcd

OW2: Als je wat wijzigt, zul je mogelijk ook Pi-hole daarvan op de hoogte moeten stellen met onder en dan "reconfigure" selecteren.
Maar hoef je pas te doen als netwerk weer hersteld is en je weer met SSH naar binnen kunt.

code:

pihole -r

Lokaal kan in wel via CLI inloggen. En ping x.x.x.x veel packet drops. ping google.com werkt niet meer.

Probleem was dus hardware gerelateerd (mijn dhcpcd.conf was hetzelfde geconfigureerd). Ethernet kabeltje was niet goed aangesloten. Nu werkt het perfect

[deHakkelaar]

@Trunksmd , ouch
YouTube: IBM - Of Je Stopt de Stekker Er In, Meneer de Computerexpert (NL) (1...

EDIT: Ow ter info, als de stekker er niet goed in zat, dan wordt dat weergegeven met het ip l commando namelijk met de <NOCARRIER> status/flag.

[ Voor 24% gewijzigd door deHakkelaar op 19-10-2022 21:42 ]

[Pierre]

deHakkelaar schreef op woensdag 19 oktober 2022 @ 21:22:
[...]

Heb je wel unbound draaien dan want dat lees ik nergens of heb ik gemist?

code:

systemctl is-active unbound

EDIT: Mocht unbound toch active zijn en heb je deze opgezet volgens de officiele Pi-hole Unbound gids:
deHakkelaar in "[Pi-Hole] Ervaringen & discussie"

Ik heb inderdaag geen Unbound draaien, maar dat moet ik misschien dan toch maar eens gaan doen In het weekend ga ik eens kijken of ik het kan fixen.

[nero355]

Trunksmd schreef op woensdag 19 oktober 2022 @ 21:35:
Probleem was dus hardware gerelateerd (mijn dhcpcd.conf was hetzelfde geconfigureerd). Ethernet kabeltje was niet goed aangesloten. Nu werkt het perfect

https://www.imperva.com/l...ation-security/osi-model/

Altijd op Layer 1 beginnen met troubleshooting hé!

[Freee!!]

nero355 schreef op donderdag 20 oktober 2022 @ 14:53:
[...]

https://www.imperva.com/l...ation-security/osi-model/

Altijd op Layer 1 beginnen met troubleshooting hé!

De problemen zitten anders te vaak op Layer 8

[Raven]

@Freee!! Pebkac ?

[sweetdude]

zijn er meer mensen met deze melding?

code:

[i] Target: dbl.oisd.nl
  [✗] Status: Connection Refused
  [✗] List download failed: using previously cached list
  [i] Analyzed 1266907 domains

de website (https://oisd.nl/) lijkt wel in de lucht te zijn

De eerste melding kwam voor mij op 2022-10-23 04:52:19
maar volgens mij is het een wekelijkse automatische refresh

[ Voor 18% gewijzigd door sweetdude op 25-10-2022 11:13 ]

[Webgnome]

Dat is toch gewoon het updaten van je blocklists ( pihole -g maar dan in cron ) die mis gaat omdat ie niet bij die url kan? Kun je eens kijken wat er gebeurd als je die lijst in de browser probeert te openen of vanaf de commandline op de rpi probeert binnen te hengelen?

[ninjazx9r98]

Doet in de browser gewoon een download van 27,19MB. Nog niet gekeken op de piholes hier.

[nero355]

sweetdude schreef op dinsdag 25 oktober 2022 @ 11:11:
zijn er meer mensen met deze melding?

code:

[i] Target: dbl.oisd.nl
  [✗] Status: Connection Refused
  [✗] List download failed: using previously cached list
  [i] Analyzed 1266907 domains

de website (https://oisd.nl/) lijkt wel in de lucht te zijn

De eerste melding kwam voor mij op 2022-10-23 04:52:19
maar volgens mij is het een wekelijkse automatische refresh

Zie : grote_oever in "[Pi-Hole] Ervaringen & discussie"

Dus als je een probleem hebt met die lijst dan moet je @sjhgvr daar effe voor aanspreken/taggen!

[sweetdude]

nero355 schreef op dinsdag 25 oktober 2022 @ 14:13:
[...]

Zie : grote_oever in "[Pi-Hole] Ervaringen & discussie"

Dus als je een probleem hebt met die lijst dan moet je @sjhgvr daar effe voor aanspreken/taggen!

ja ik wist dat hij hier rond lurkte, maar ik ben niet tot pagina 13 (voor mij dan) terug gegaan terwijl ik op pagina 84 wat post en zoeken op de lijstnaam geeft ook heel veel hits.
En het was meer een vraag of het aan mij lag of dat er meer met hetzelfde probleem zijn.

[deHakkelaar]

sweetdude schreef op dinsdag 25 oktober 2022 @ 11:11:

[i] Target: dbl.oisd.nl
  [✗] Status: Connection Refused

Is het linkje wel HTTPS en niet HTTP?

pi@ph5b:~ $ curl -IL http://dbl.oisd.nl
curl: (7) Failed to connect to dbl.oisd.nl port 80: Connection refused

pi@ph5b:~ $ nc -vz dbl.oisd.nl 80
nc: connect to dbl.oisd.nl (51.178.86.254) port 80 (tcp) failed: Connection refused

Vs:

pi@ph5b:~ $ curl -IL https://dbl.oisd.nl
HTTP/2 200
[..]
date: Tue, 25 Oct 2022 13:35:37 GMT
server: Apache

pi@ph5b:~ $ nc -vz dbl.oisd.nl 443
Connection to dbl.oisd.nl (51.178.86.254) 443 port [tcp/https] succeeded!

[sjhgvr]

deHakkelaar schreef op dinsdag 25 oktober 2022 @ 15:40:
[...]

Is het linkje wel HTTPS en niet HTTP?

pi@ph5b:~ $ curl -IL http://dbl.oisd.nl
curl: (7) Failed to connect to dbl.oisd.nl port 80: Connection refused

pi@ph5b:~ $ nc -vz dbl.oisd.nl 80
nc: connect to dbl.oisd.nl (51.178.86.254) port 80 (tcp) failed: Connection refused

Vs:

pi@ph5b:~ $ curl -IL https://dbl.oisd.nl
HTTP/2 200
[..]
date: Tue, 25 Oct 2022 13:35:37 GMT
server: Apache

pi@ph5b:~ $ nc -vz dbl.oisd.nl 443
Connection to dbl.oisd.nl (51.178.86.254) 443 port [tcp/https] succeeded!

sweetdude schreef op dinsdag 25 oktober 2022 @ 11:11:
zijn er meer mensen met deze melding?

code:

[i] Target: dbl.oisd.nl
  [✗] Status: Connection Refused
  [✗] List download failed: using previously cached list
  [i] Analyzed 1266907 domains

de website (https://oisd.nl/) lijkt wel in de lucht te zijn

De eerste melding kwam voor mij op 2022-10-23 04:52:19
maar volgens mij is het een wekelijkse automatische refresh

Snap m al. In plaats van http naar https redirecten staat poort 80 nu dicht.

Gaat ik ff fixen.

Edit; Fixed. (Pas van host geswitched. Loop soms nog ff tegen wat kleinigheidjes aan)

[ Voor 49% gewijzigd door sjhgvr op 25-10-2022 17:07 ]

[sweetdude]

deHakkelaar schreef op dinsdag 25 oktober 2022 @ 15:40:
[...]

Is het linkje wel HTTPS en niet HTTP?

pi@ph5b:~ $ curl -IL http://dbl.oisd.nl
curl: (7) Failed to connect to dbl.oisd.nl port 80: Connection refused

pi@ph5b:~ $ nc -vz dbl.oisd.nl 80
nc: connect to dbl.oisd.nl (51.178.86.254) port 80 (tcp) failed: Connection refused

Vs:

pi@ph5b:~ $ curl -IL https://dbl.oisd.nl
HTTP/2 200
[..]
date: Tue, 25 Oct 2022 13:35:37 GMT
server: Apache

pi@ph5b:~ $ nc -vz dbl.oisd.nl 443
Connection to dbl.oisd.nl (51.178.86.254) 443 port [tcp/https] succeeded!

Ook handig inderdaad. zie nu dat ik inderdaad alleen dbl.oisd.nl in de blocklist had staan zonder http of https ervoor. Als het jaren werkt zie je er zo overheen. Leer je nog wat. ik zit nu op de https link en de redirect is ook geregeld aan de andere kant

[deHakkelaar]

@sjhgvr , zo'n vermoeden had ik al
Of dat je 80 TCP helemaal vaarwel zwaait.

EDIT: 302:

pi@ph5b:~ $ curl -IL http://dbl.oisd.nl
HTTP/1.1 302 Found
[..]
Location: https://dbl.oisd.nl/
[..]
HTTP/2 200
[..]
date: Tue, 25 Oct 2022 16:18:01 GMT
server: Apache

[ Voor 147% gewijzigd door deHakkelaar op 25-10-2022 18:21 ]

[deHakkelaar]

sweetdude schreef op dinsdag 25 oktober 2022 @ 17:34:
zie nu dat ik inderdaad alleen dbl.oisd.nl in de blocklist had staan zonder http of https ervoor.

curl wordt ook gebruikt om de ad/blocklists binnen te slurpen:

pi@ph5b:~ $ man curl
[..]
SYNOPSIS
       curl [options / URLs]
[..]
       If  you  specify URL without protocol:// prefix, curl will attempt
       to guess what protocol you might want. It  will  then  default  to
       HTTP  but  try  other protocols based on often-used host name pre‐
       fixes. For example, for host names starting with "ftp." curl  will
       assume you want to speak FTP.

       curl  will  do its best to use what you pass to it as a URL. It is
       not trying to validate it as a syntactically correct  URL  by  any
       means but is instead very liberal with what it accepts.

EDIT:
https://github.com/pi-hol...f223d4906/gravity.sh#L645

[ Voor 5% gewijzigd door deHakkelaar op 25-10-2022 18:13 ]

[nero355]

sweetdude schreef op dinsdag 25 oktober 2022 @ 14:32:
ja ik wist dat hij hier rond lurkte, maar ik ben niet tot pagina 13 (voor mij dan) terug gegaan terwijl ik op pagina 84 wat post en zoeken op de lijstnaam geeft ook heel veel hits.

Letterlijk de 4de reactie als je zoekt op de URL van de lijst : Search naar "dbl.oisd.nl" in "[Pi-Hole] Ervaringen & discussie"

[ Voor 25% gewijzigd door nero355 op 25-10-2022 19:51 ]

[Raymond P]

@nero355 Ik had klaarblijkelijk verkeerd geteld en was de 5e reactie aan het lezen. Totale kortsluiting.

[MJV]

Op een of andere manier is hier plots het casten via de NPO naar de Chromecast ermee opgehouden sinds een dag of drie. "Pi-hole disable" loste het probleem op. Ik denk dat de NPO app extra domeinen nodig heeft sinds een recente update. Ik heb er nu maar een drietal gewhitelist, misschien niet alle drie nodig (maar kinderen ongeduldig):

code:

static.doubleclick.net
tag.aticdn.net
static.cloudflareinsights.com

Edit: blijkbaar was die tag.aticdn.net al bekend, alleen nog niet gewhitelist op mijn Pi-hole voor IoT (waaronder Chromecast devices. Kom nu ook deze tegen:

code:

api.ipify.org

[ Voor 18% gewijzigd door MJV op 26-10-2022 08:00 ]

[Webgnome]

MJV schreef op woensdag 26 oktober 2022 @ 07:43:
Op een of andere manier is hier plots het casten via de NPO naar de Chromecast ermee opgehouden sinds een dag of drie. "Pi-hole disable" loste het probleem op. Ik denk dat de NPO app extra domeinen nodig heeft sinds een recente update. Ik heb er nu maar een drietal gewhitelist, misschien niet alle drie nodig (maar kinderen ongeduldig):

code:

static.doubleclick.net
tag.aticdn.net
static.cloudflareinsights.com

Ik zal vanavond eens kijken of dat ik dit ook heb. NPO is wel wat specifiek qua domeinen. Echter als je static.doubleclick.net moet gaan whitelisten kun je net zo goed pihole opheffen

[MJV]

Webgnome schreef op woensdag 26 oktober 2022 @ 07:58:
[...]


Ik zal vanavond eens kijken of dat ik dit ook heb. NPO is wel wat specifiek qua domeinen. Echter als je static.doubleclick.net moet gaan whitelisten kun je net zo goed pihole opheffen

Eens mbt doubleclick. Ik heb 'm nu weer van de whitelist afgegooid. Zie edit, kwam ook nog twee an dere domeinen tegen: api.ipify.org en cws.conviva.com. Heel lekker werkt het nog niet tot nu toe.

Blijkbaar zit 't m in die twee, waar de Chromecast een request naar doet. Die cws.conviva.com lijkt gerandomiseerd, ik zie bijv deze in de logs:

code:

    dfa978b5c517fdc7032c36c3d26737324368a4d0.ipv6.cws.conviva.com

.

Conclusie:
Als volgt gewhitelist:

code:

(\.|^)cws\.conviva\.com$    
cws.conviva.com 
api.ipify.org
tag.aticdn.net

[ Voor 26% gewijzigd door MJV op 26-10-2022 08:10 ]

[Wachten...]

nero355 schreef op zaterdag 16 november 2019 @ 21:57:
[...]

Doe je wel een DNS Flush op zo'n moment samen met een Clear Cache van je browser

Blacklisten/Whitelisten doe ik bijna nooit, maar ik zou wel op zo'n moment met dit soort dingen rekening houden!

Daarnaast moet je ook uitkijken met Chrome of Chromium based browsers, want die hebben een paar nare dingen die je het liefst altijd moet uitschakelen via de chrome://flags opties :
- QUIC protocol
- A-Sync DNS
- Allerlei andere troep die je lokale DNS server niet respecteert...

Deze post van jou is al even geleden, maar ik vroeg me af hoe relevant dit nog is? Zijn er in de tussentijd ook nog andere dingen bij gekomen die echt troep zijn in de flag settings?

Edit: Laat maar, ik had nog een later lijst van je gezien met DNS over HTTPS.
Het enige wat ik zie in Brave (die ik enkel gebruik voor Youtube), is dat er 2 opties zijn qua DNS over HTTPS. Dienen deze beide uitgeschakeld te worden?

• Support for HTTPS records in DNS
• Use DNS https alpn

[ Voor 29% gewijzigd door Wachten... op 26-10-2022 10:23 ]

[nero355]

Wachten... schreef op woensdag 26 oktober 2022 @ 10:16:
Deze post van jou is al even geleden, maar ik vroeg me af hoe relevant dit nog is? Zijn er in de tussentijd ook nog andere dingen bij gekomen die echt troep zijn in de flag settings?

Geen idee, want ik gebruikte Google Chrome onder Android voor één specifieke website en dat is gelukkig niet meer nodig!

In feite kan je na elke update/upgrade ellende verwachten dus blijf alert zou ik zeggen!

Edit: Laat maar, ik had nog een later lijst van je gezien met DNS over HTTPS.
Het enige wat ik zie in Brave (die ik enkel gebruik voor Youtube), is dat er 2 opties zijn qua DNS over HTTPS. Dienen deze beide uitgeschakeld te worden?

• Support for HTTPS records in DNS
• Use DNS https alpn

[Afbeelding]

Die twee zou ik lekker uitschakelen!

[Raymond P]

Nou, ik dacht DOH ook maar eens aan te gaan zetten op IPv6 zodat ik mobiel geen issues meer heb.
Dat gaat mij niet makkelijk af.

Iemand hier die dat zelf doet en een duwtje de juiste richting op kan geven?

[deHakkelaar]

Wachten... schreef op woensdag 26 oktober 2022 @ 10:16:
Het enige wat ik zie in Brave (die ik enkel gebruik voor Youtube), is dat er 2 opties zijn qua DNS over HTTPS. Dienen deze beide uitgeschakeld te worden?

• Support for HTTPS records in DNS
• Use DNS https alpn

Wbt HTTPS DNS records, deze hebben karakteristieken vergelijkbaar met SRV DNS records als je daar bekent mee bent.
En ik geloof dat Pi-hole nog niet een deep scan doet voor deze records net als dat er voor CNAME records wordt gedaan.
Dus kan Pi-hole hierdoor ook mee omzeild worden.
HTTPS records zijn ook vrij nieuw en geloof nog in "draft" dus nog niet wijd toegepast:
https://datatracker.ietf....ft-ietf-dnsop-svcb-https/

[ Voor 0% gewijzigd door deHakkelaar op 26-10-2022 23:20 . Reden: typo ]

[deHakkelaar]

Raymond P schreef op woensdag 26 oktober 2022 @ 19:13:
Nou, ik dacht DOH ook maar eens aan te gaan zetten op IPv6 zodat ik mobiel geen issues meer heb.

DoH is onafhankelijk vd transport layer.
Als er een IPv6 route is, dan zal deze de voorkeur hebben over IPv4.
Wat voor "issues" heb je?

[Raymond P]

deHakkelaar schreef op woensdag 26 oktober 2022 @ 21:33:
[...]

DoH is onafhankelijk vd transport layer.
Als er een IPv6 route is, dan zal deze de voorkeur hebben over IPv4.
Wat voor "issues" heb je?

De vertaling naar ipv4 voor de backend in m'n proxy gaat niet goed. Of eigenlijk het antwoord terug naar ipv6 voor zover ik debugged heb.

Ik heb nu dus al wat jaren Nginx ervoor hangen (DOT+DOH) en voordat ik daar energie in ga steken was ik benieuwd of er al een fatsoenlijke en ongecompliceerde proxy daemon voor was.

[dss58]

deHakkelaar schreef op woensdag 26 oktober 2022 @ 21:32:
[...]

Wbt HTTPS DNS records, deze hebben karakteristieken vergelijkbaar met SRV DNS records als je daar bekent mee bent.
En ik geloof dat Pi-hole nog niet een deep scan doet voor deze records net als dat er voor CNAME records wordt gedaan.
Dus kan Pi-hole hierdoor ook mee omzeilt worden.
HTTPS records zijn ook vrij nieuw en geloof nog in "draft" dus nog niet wijd toegepast:
https://datatracker.ietf....ft-ietf-dnsop-svcb-https/

kwestie van tijd vermoed ik, misschien versie 6 maar ik heb geen idee van die ontwikkelingen, mij te ingewikkeld als ik eerlijk ben

[Raymond P]

Nou, issue lag dus ergens in de loop en vertaalslag tussen DOH en DOT en headers met conversie terug naar ipv6.

Te veel gedoe voor nu, ik wil morgenochtend gewoon weer pihole hebben. Dus nu heb ik er (weer) coredns voor gegooid en geen gedoe.

[Pierre]

sweetdude schreef op dinsdag 25 oktober 2022 @ 11:11:
zijn er meer mensen met deze melding?

code:

[i] Target: dbl.oisd.nl
  [✗] Status: Connection Refused
  [✗] List download failed: using previously cached list
  [i] Analyzed 1266907 domains

de website (https://oisd.nl/) lijkt wel in de lucht te zijn

De eerste melding kwam voor mij op 2022-10-23 04:52:19
maar volgens mij is het een wekelijkse automatische refresh

Ik heb het ook, alleen ik heb geen idee hoe ik het kan oplossen.
Wel trouwens vandaag Unbound met succes geinstalleerd

[sweetdude]

Pierre schreef op vrijdag 28 oktober 2022 @ 15:56:
[...]

Ik heb het ook, alleen ik heb geen idee hoe ik het kan oplossen.
Wel trouwens vandaag Unbound met succes geinstalleerd

de oplossing is dus om als blocklist letterlijk:

code:

https://dbl.oisd.nl

op te nemen (dus met https:// ervoor)

[ Voor 3% gewijzigd door sweetdude op 28-10-2022 16:22 ]