[Pi-Hole] Ervaringen & discussie

[EverLast2002]

Thalamus schreef op maandag 28 oktober 2024 @ 11:06:
[...]


Sorry voor de late reactie

ik heb zoiets als een DNS Director (denk ik), ik forceer dat alle DNS requests naar mijn docker gaat
[Afbeelding]


Maar dan begrijp ik niet dat ' alle' DNS request met unbound werkt behalve transavia

Geldt dit ook voor DoH/DoT DNS verkeer dat poort 53 niet gebruikt?

[alex3305]

EverLast2002 schreef op maandag 28 oktober 2024 @ 14:50:
Geldt dit ook voor DoH/DoT DNS verkeer dat poort 53 niet gebruikt?

Nee. Alleen verkeer over poort 53 volgens het screenshot van @Thalamus.

Gek genoeg had ik net wel een zeer vergelijkbaar probleem. Mijn Unbound gaf volgens AdGuard Home een SERVFAIL op www.imdb.com. Nadat ik een directe query op Unbound deed naar www.imdb.com werkte het spontaan weer. Ik heb dat weleens vaker en na wat Googlen kom ik tegen dat ik daarin niet de enige ben. Niet helemaal een Pi-Hole probleem, maar wellicht wel de moeite waard om nog eens uit te zoeken .

[Yucko]

EverLast2002 schreef op maandag 28 oktober 2024 @ 14:50:
[...]


Geldt dit ook voor DoH/DoT DNS verkeer dat poort 53 niet gebruikt?

tja, DoH zal moeilijk worden om dat eruit te pikken tussen de rest van het verkeer. DoT gebruikt doorgaans poort 853 dus kun je meenemen in je rules.

Ik leid zelf niets om (volgens mij kan die niet eens op mijn UDR) maar blokkeer al het uitgaande verkeer voor poorten 53, 853 en 8853 (QUIC) behalve voor PiHole en AGH instance.

Daarnaast 8.8.8.8 en 8.8.4.4 in zijn geheel geblokt, dus mocht een rogue android device denken de DHCP instellingen te negeren en toch met Google DNS te gaan babbelen via bv. DoH dan is dat toch echt jammer

Niet waterdicht indien een DoH server anders dan die van Google gebruikt wordt, maar so be it. Als men via een VPN gaat dan ben je ook shit out of luck.

[nero355]

Yucko schreef op maandag 28 oktober 2024 @ 15:18:
Ik leid zelf niets om (volgens mij kan die niet eens op mijn UDR) maar blokkeer al het uitgaande verkeer voor poorten 53, 853 en 8853 (QUIC) behalve voor PiHole en AGH instance.

Ubiquiti heeft blijkbaar onlangs eindelijk na 10+ jaar DNAT/SNAT opties aan de UniFi Controller toegevoegd dus al hun Routers vanaf de UDR/UDM/UXG generatie kunnen daar eindelijk gebruik van maken
_{Het werd wel een beetje tijd zullen we maar zeggen...}

Echter kan je dat alleen gebruiken om DNS poort 53 om te leiden en niet 853/8853 en andere DoH/DoT/enz. technieken : Die moet je gewoon blokkeren

Wat ook een optie is voor bijvoorbeeld OPNsense/pfSense is een Firewall Rule maken die het opgevraagde IP adres checkt in een aantal Block Lists waarop allerlei DoH/DoT/enz. Servers staan en als er dan een match is dan wordt het verkeer richting zo'n IP adres geblokkeerd

Ik geloof dat @jpgview ook ooit zoiets heeft gepost in het verleden !!

[sweetdude]

Ik had van het weekeinde eens tijd om met een pi die vrijgekomen was om te experimenteren met de nieuwe PiHole v6. Alles werkte in principe zoals het zou moeten.
Alleen het jammere is dat PiVPN niet met PiHole V6 samenwerkt. PiVPN kijkt namelijk naar een var.conf bestand wat vervallen is in de v6 versie.

Hierdoor krijg je wel het scherm dat hij PiHole ziet.
Maar krijg je bij het aanmaken van een client een melding dat hij die file niet meer kan vinden.

[ Voor 22% gewijzigd door sweetdude op 11-11-2024 11:02 ]

[nero355]

sweetdude schreef op maandag 11 november 2024 @ 11:01:
Alleen het jammere is dat PiVPN niet met PiHole V6 samenwerkt.

PiVPN kijkt namelijk naar een var.conf bestand wat vervallen is in de v6 versie.

Hierdoor krijg je wel het scherm dat hij PiHole ziet.
Maar krijg je bij het aanmaken van een client een melding dat hij die file niet meer kan vinden.

Wat probeert PiVPN dan te doen op dat moment

De enige reden dat PiVPN iets via Pi-Hole doet lijkt me DNS verkeer dus als een of andere automatische detectie niet werkt dan kan je dat ook zelf opgeven denk ik ?!
Of gaat het om actief zijn op de wg0 Interface ? Ook dat kan je waarschijnlijk wel zelf fixen

[EverLast2002]

offtopic:
ik las iets over PiVPN the end...?
hopelijk wordt het verder opgepakt of een fork ervan want het is wel een handige vpn tool.

[Pazo]

EverLast2002 schreef op dinsdag 12 november 2024 @ 11:31:
offtopic:
ik las iets over PiVPN the end...?
hopelijk wordt het verder opgepakt of een fork ervan want het is wel een handige vpn tool.

Ah, dat verklaard waarschijnlijk waarom ik laatst geen verbinding met thuis kon krijgen...
Doe dat heel af en toe via PiVPN als ik iets nodig heb, maar lukte dus laatst niet. Maar had nog niet de moeite genomen om uit te zoeken wat het probleem was. Waarschijnlijk werkt het nu dus niet meer. Dus moeten we op zoek naar een alternatief. Wel jammer, ik vond het makkelijk te configureren en werkte icm Wireguard altijd heel goed.

[EverLast2002]

Pazo schreef op dinsdag 12 november 2024 @ 11:37:
[...]


Ah, dat verklaard waarschijnlijk waarom ik laatst geen verbinding met thuis kon krijgen...
Doe dat heel af en toe via PiVPN als ik iets nodig heb, maar lukte dus laatst niet. Maar had nog niet de moeite genomen om uit te zoeken wat het probleem was. Waarschijnlijk werkt het nu dus niet meer. Dus moeten we op zoek naar een alternatief. Wel jammer, ik vond het makkelijk te configureren en werkte icm Wireguard altijd heel goed.

Volgens mij kun je PiVPN nog steeds installeren en gebruiken,
alleen wordt er niks meer ontwikkeld, gepatched, geupdate. De repo staat op read-only.

[Toet3r]

EverLast2002 schreef op dinsdag 12 november 2024 @ 11:31:
offtopic:
ik las iets over PiVPN the end...?
hopelijk wordt het verder opgepakt of een fork ervan want het is wel een handige vpn tool.

Jammer, pivpn was erg handig. Misschien dat iemand het nog forked en het door ontwikkeld.

[Pazo]

EverLast2002 schreef op dinsdag 12 november 2024 @ 11:53:
[...]


Volgens mij kun je PiVPN nog steeds installeren en gebruiken,
alleen wordt er niks meer ontwikkeld, gepatched, geupdate. De repo staat op read-only.

Ja dat is wel weer waar. Binnenkort maar even induiken, maar misschien wel overstappen naar wat anders, wat PiVPN wordt dus een doodlopende weg.

[DikkieDick]

Thalamus schreef op maandag 28 oktober 2024 @ 12:21:


Ik heb het een beetje opgegeven om het probleem te zoeken in de cbcrowe docker

Heb docker van pluim003 geinstalleerd en werkt

Volgens mij is Chris ook niet erg actief meer. Blij te horen dat die van mij wel werkt. Ben overigens nog niet zover om hem met pihole 6 aan de praat te krijgen. Wellicht ooit eens als ik wat meer tijd heb.

[W1ck1e]

Pazo schreef op dinsdag 12 november 2024 @ 12:14:

Ja dat is wel weer waar. Binnenkort maar even induiken, maar misschien wel overstappen naar wat anders, wat PiVPN wordt dus een doodlopende weg.

Getriggerd door de recente berichtjes, gegoogled op "pivpn atlernative"
Reddit

wireguard zonder docker

en aangezien ik dietpi ook wel mooi vind, daar is wireguard ook een optie


nog niks mee gedaan, later misschien wel.

[ Voor 14% gewijzigd door W1ck1e op 12-11-2024 13:50 ]

[GG85]

Dietpi is top. Draai al paar jaar naar volle tevredenheid.

Nog nieuws qua V6? Man man dat duurt

[Toet3r]

@GG85
Ze hebben geen datum of andere hint gegeven.
de development branch van docker wordt ook niet heel vaak meer geupdate. Laatste update is van 3 dagen geleden. Die daarvoor was dacht iets van een maand geleden. Dit geeft wel aan dat de ontwikkeling nu een stuk minder hard gaat dan een tijdje geleden.
We zullen toch nog even geduld moeten hebben.

[Raven]

Pazo schreef op dinsdag 12 november 2024 @ 12:14:
[...]


Ja dat is wel weer waar. Binnenkort maar even induiken, maar misschien wel overstappen naar wat anders,

VPN-server op de oude handmatige manier opzetten , is in mijn geval sowieso nodig daar er geen PiVPN(-achtige) oplossing is die nftables ondersteund of een "do not touch firewall"-optie heeft

[ Voor 10% gewijzigd door Raven op 12-11-2024 15:28 ]

[Church of Noise]

Toet3r schreef op dinsdag 12 november 2024 @ 14:43:
@GG85
Ze hebben geen datum of andere hint gegeven.
de development branch van docker wordt ook niet heel vaak meer geupdate. Laatste update is van 3 dagen geleden. Die daarvoor was dacht iets van een maand geleden. Dit geeft wel aan dat de ontwikkeling nu een stuk minder hard gaat dan een tijdje geleden.
We zullen toch nog even geduld moeten hebben.

Als je sneller updates wil, kan je de nightly tag gebruiken...
(doe ik overigens ook)
Het gaat nog altijd goed vooruit overigens.

[ed1703]

Raven schreef op dinsdag 12 november 2024 @ 15:25:
[...]

VPN-server op de oude handmatige manier opzetten , is in mijn geval sowieso nodig daar er geen PiVPN(-achtige) oplossing is die nftables ondersteund of een "do not touch firewall"-optie heeft

Van oplossingen zoals PiVPN leer je ook weinig. Makkelijk wel, maar ik vind de leercurve van openvpn ook wat hoger dan wireguard imho.

[nero355]

EverLast2002 schreef op dinsdag 12 november 2024 @ 11:31:
offtopic:
ik las iets over PiVPN the end...?
hopelijk wordt het verder opgepakt of een fork ervan want het is wel een handige vpn tool.

IMHO geen ramp, want alles wat erin zit kan je zelf (gedeeltelijk) nabouwen met standaard oplossingen als het goed is

Raven schreef op dinsdag 12 november 2024 @ 15:25:
VPN-server op de oude handmatige manier opzetten

WebMin + OpenVPN plug-in + Een paar keer clicken = KLAAR!!!

Misschien kan je zoiets ondertussen ook i.c.m. Wireguard doen

Is in mijn geval sowieso nodig daar er geen PiVPN(-achtige) oplossing is die nftables ondersteund of een "do not touch firewall"-optie heeft

Eigenlijk wel gek : Zoveel opties en die optie vervolgens nooit erbij zetten ?!

ed1703 schreef op dinsdag 12 november 2024 @ 17:55:
Van oplossingen zoals PiVPN leer je ook weinig. Makkelijk wel, maar ik vind de leercurve van openvpn ook wat hoger dan wireguard imho.

Soms heb je ook geen zin om bepaalde dingen te doen ook al weet je verdomd goed wat je zou moeten doen om het handmatig werkend te krijgen

Ik vond het in ieder geval echt een super scriptje voor effe snel wat aanklooien en bovendien kwamen er door de tijd heen allerlei mooie webGUI dingetjes of zelfs geheel vervangende oplossingen met een mooie webGUI erbij waarmee je NOG makkelijker alles kon regelen !!

[Raven]

nero355 schreef op dinsdag 12 november 2024 @ 19:16:
[...]

WebMin + OpneVPN plug-in + Een paar keer clicken = KLAAR!!!

Misschien kan je zoiets ondertussen ook i.c.m. Wireguard doen

Nope, die plugin had ik al geprobeerd (error tijdens genereren certificaten), plus een iets meer bijgewerkte fork op Github (deze was het geloof ik), maar alsnog te oud De client klaagde over "certificate is too weak" en "cannot load inline certificate file".

nero355 schreef op dinsdag 12 november 2024 @ 19:16:
[...]

Eigenlijk wel gek : Zoveel opties en die optie vervolgens nooit erbij zetten ?!

Ooit wel request voor ingediend, evenals bij een alternatief, maar nftables-ondersteuning implementeren zou te ingewikkeld zijn, ook nadat ik voorbeeldregels erbij stopte én een bash-script dat de bestaande iptables-regels opvraagt en omzet naar nftables.

Een optie voor "do not touch the firewall" is er ook nooit in gekomen

edit:
@nero355
https://amazingrdp.com/se...-a-server-key-for-webmin/

The standard hash algorithm of the WebMin module is set to md5, but it needs to be changed to sha256. Let’s go to the ssl config file.

sudo nano /etc/openvpn/openvpn-ssl.cnf

Next line default_md = md5 change md5 to sha256

default_md = sha256

Now the official OpenVPN client will not complain about the weak hash algorithm.

Zou het zo simpel zijn , later maar eens proberen.

[ Voor 19% gewijzigd door Raven op 12-11-2024 19:55 ]

[nero355]

Raven schreef op dinsdag 12 november 2024 @ 19:46:
Nope, die plugin had ik al geprobeerd (error tijdens genereren certificaten), plus een iets meer bijgewerkte fork op Github (deze was het geloof ik), maar alsnog te oud De client klaagde over "certificate is too weak" en "cannot load inline certificate file".

edit:
@nero355
https://amazingrdp.com/se...-a-server-key-for-webmin/

[...]

Zou het zo simpel zijn , later maar eens proberen.

Het is dan ook een tijdje geleden dat ik die optie in een VM heb getest dus misschien moet je toch inderdaad het een en ander zelf een beetje uitvogelen

Maar je houdt wel een relaxe webGUI over voor je OpenVPN beheer

[Raven]

nero355 schreef op woensdag 13 november 2024 @ 15:23:
[...]

Het is dan ook een tijdje geleden dat ik die optie in een VM heb getest dus misschien moet je toch inderdaad het een en ander zelf een beetje uitvogelen

Maar je houdt wel een relaxe webGUI over voor je OpenVPN beheer

offtopic:
Dat blijkt, er lijkt inmiddels wel wat meer out of date te zijn (buiten die md5 -> sha256 config), ook in de fork van de addon.

De server-config krijgt geen absolute paden (wat OpenVPN niet leuk vind, klaagt over niet kunnen vinden van certificaten, keys en log-map), maar maak ik de paden absoluut, dan kan Webmin er niet mee overweg: "No server keys configured".
edit: Dit gefixed door de relatieve paden in de config te laten, maar "--cd /etc/openvpn" in de systemd-file toe te voegen.

Dan is er nog:
DEPRECATED OPTION: --cipher set to 'AES-128-CBC' but missing in --data-ciphers (AES-256-GCM:AES-128-GCM:CHACHA20-POLY1305). OpenVPN ignores --cipher for cipher negotiations.
edit: Dit bleek zo simpel als "data-ciphers AES-128-CBC" toevoegen aan het "Additional Configurations"-veld

gevolgd door
WARNING: Compression for receiving enabled. Compression has been used in the past to break encryption. Sent packets are not compressed unless "allow-compression yes" is also set.
^ maar uitzetten en alsof dat nog niet genoeg was:

ERROR: Cannot open TUN/TAP dev /dev/net/tun: Operation not permitted (errno=1)

Kijk later wel weer wat verder.

[ Voor 13% gewijzigd door Raven op 14-11-2024 10:15 ]

[nero355]

Raven schreef op donderdag 14 november 2024 @ 09:37:

offtopic:
Dat blijkt, er lijkt inmiddels wel wat meer out of date te zijn (buiten die md5 -> sha256 config), ook in de fork van de addon.

- knip -

Kijk later wel weer wat verder.

offtopic:
Dat is echt heel erg jammer dan, want zoveel moeite hoort het niet te kosten...

[Raven]

offtopic:
@nero355

Dat van die md5 is wel raar, gezien de fork een paar jaar na het stoppen met ondersteunen daarvan is gemaakt, althans, dit is afgaand op Google-hits.

De paden kan pebkac zijn, ik had de systemd-file zelf geschreven op basis van voorbeelden. Daar stond niets over het gebruiken van "--cd /etc/openvpn", maar dat Webmin de absolute paden niet herkend is iets waar ik niets aan kan doen. Relatieve paden in de config, zoals de Webmin-plugin het doet, i.c.m. "--cd /etc/openvpn" wordt zowel door OpenVPN als de Webmin-plugin geaccepteerd.

Dat van data-ciphers lijkt iets van na het gemaakt zijn van de fork, als ik alles werkend heb eens de issue die ik een tijd terug had gemaakt bijwerken.

Voor de compression-melding lijkt hetzelfde te gelden, zo op het eerste gezicht verschenen na het gemaakt zijn van de fork.

De permissie-error moet ik nog naar kijken. Hangt mij iets van bij dat ik ook zoiets had toen ik de router-pc als PIA-client (in network namespace met proxy erbij) wilde opzetten. Daar heb ik nog niet weer naar gekeken.

[mrdemc]

ed1703 schreef op dinsdag 12 november 2024 @ 17:55:
[...]

Van oplossingen zoals PiVPN leer je ook weinig. Makkelijk wel, maar ik vind de leercurve van openvpn ook wat hoger dan wireguard imho.

Als je dat wilt, probeer voor de gein dan eens Strongswan

[_Eend_]

FYI: Gravity Sync (https://github.com/vmstan/gravity-sync) is sinds 26 juli 2024 gearchiveerd op GitHub, maw. het wordt niet meer onderhouden. Alternatieven zijn o.a.:

• https://github.com/mattwebbio/orbital-sync
• https://github.com/lovelaze/nebula-sync

Daar kwam ik dus net achter toen ik wat aan het stoeien was met mijn pi-holes.

[Webgnome]

@_Eend_ dat gebruik je, als ik het goed lees, om twee of meerdere piholes in sync te houden?

[Toet3r]

_Eend_ schreef op vrijdag 22 november 2024 @ 08:04:
FYI: Gravity Sync (https://github.com/vmstan/gravity-sync) is sinds 26 juli 2024 gearchiveerd op GitHub, maw. het wordt niet meer onderhouden. Alternatieven zijn o.a.:

• https://github.com/mattwebbio/orbital-sync
• https://github.com/lovelaze/nebula-sync

Daar kwam ik dus net achter toen ik wat aan het stoeien was met mijn pi-holes.

Heb een hele tijd geleden orbital sync geprobeerd. Werkte toen goed.
Toet3r in "[Pi-Hole] Ervaringen & discussie"

[_Eend_]

@Webgnome correct.

Zelf heb ik het draaien op twee pihole VM's die op twee verschillende proxmox hosts draaien, dan kan ik de ene host rebooten zonder dat ik de VM hoef te migreren naar de andere host.

[_Eend_]

Toet3r schreef op vrijdag 22 november 2024 @ 08:16:
[...]

Heb een hele tijd geleden orbital sync geprobeerd. Werkte toen goed.
Toet3r in "[Pi-Hole] Ervaringen & discussie"

Maar je gebruikt het niet meer?

[Webgnome]

offtopic:
@_Eend_ heb zelf twee piholes echter zijn ze ook DHCP server. Kun je kiezen om dat niet te syncen? Want anders krijg je ip conflicten natuurlijk

[ Voor 4% gewijzigd door Webgnome op 22-11-2024 09:31 ]

[Toet3r]

@_Eend_
Nee, heb nu 1x pihole draaien als docker container.

[_Eend_]

offtopic:
@Webgnome geen idee, ik gebruik de DHCP server van pihole niet

[MadMax12]

Lees nu net dat de PiVPN dus niet meer ontwikkeld wordt, jarenlang met plezier gebruikt.

Dacht zal eens kijken hoe mijn VPN loopt, maar ik gebruik al maanden niet meer de PiVPN zie ik net.
Sinds Unifi Wireguard ondersteunt heb ik daar ook een VPN over lopen en daar heb ik de DNS servers van mijn Pi-Hole's op staan, werkt als een trein en als er iets mis gaat is het eigenlijk altijd iets met de Raspberry's waar de Pi-Hole's op draaien.

Zowel mijn iPhone als MacBook pakken buiten huis automatisch Wireguard op zodat alles via "thuis" loopt.

[nero355]

MadMax12 schreef op vrijdag 22 november 2024 @ 12:58:
Sinds Unifi Wireguard ondersteunt heb ik daar ook een VPN over lopen en daar heb ik de DNS servers van mijn Pi-Hole's op staan, werkt als een trein en als er iets mis gaat is het eigenlijk altijd iets met de Raspberry's waar de Pi-Hole's op draaien.

Totdat Ubiquiti weer eens een halvegare Firmware/Controller Update/Upgrade uitbrengt en de boel sloopt

* nero355 zijn DIY Router een knuffel geeft

[Raven]

@MadMax12 Nog geen bedrijfs-/school-/gasten-netwerken tegengekomen waar UDP geblokkeerd wordt? Dat is een (volgens mij) veelvoorkomende klacht bij Wireguard.

[Get!em]

Zo, hier nu eindelijk ook eens pi-hole geactiveerd. Ik had altijd NextDNS op mijn apparaten, maar ervaarde daar soms wat hickups mee. Met name duckdns problemen verergerden en ook locale netwerk adressen werden soms (ondanks whitelist) geblokkeerd. Een vaak was het wel snel, maar bij vlagen ook enorm traag.

Nu op mijn homeserver de proxmox lxc geactiveerd middels de proxmox helperscripts van tteck, en meteen unbound geactiveerd. Binnen 3 minuten up and running.

Ik heb Pihole nog niet als default DNS voor gehele netwerk geactiveerd, gezien ik eerst even wil leren wat wel en niet werkt. Eerste problemen al gezien, omdat herstart volgorde van mijn lxc op proxmox nog in verkeerde volgorde stond (Pihole als laatste, en dat was 5 minuten na restarting server, vanwege een ingestelde vertraging bij andere servers die in specifieke volgorde up moeten zijn).

OISD lists nu geactiveerd.

Ook Tailscale geactiveerd op de Pihole, en daarmee meteen de primary globaal dns van mijn tailscale net gemaakt. Daardoor nu meteen ook gefilterd verkeer op mijn mobiel en tablet.

Wel nog even een vraag die ik zo snel nog niet kon vinden: als unbound actief is, moeten dan de upstream DNS uitgezet worden? In de handleiding lijkt het screenshot dat te suggereren, maar ze staan nu juist wel aan bij mij (openDNS en cloudflare, incl dnssec check)

Zijn er nog specifieke settings die performance van DNS requests bevorderen?

[Webgnome]

@Get!em als je unbound gebruikt moet je in pihle aangeven dat die deze als dns server gebruiken. Anders zit die inderdaad niets te doen.
Welke performance zou je willen bevorderen. Als je dit topic doorneemt dan zul je zien dat DNS erg snel is van zichzelf. En als je problemen hebt met laden van pagina's dat je het eerder ergens anders moet zoeken. Wat je zou kunnen doen is in unbound de config aan te passen zodat er meer gecached word, of je daar blij van word is natuurlijk dan weer de vraag

[Get!em]

Webgnome schreef op woensdag 11 december 2024 @ 14:38:
@Get!em als je unbound gebruikt moet je in pihle aangeven dat die deze als dns server gebruiken. Anders zit die inderdaad niets te doen.
Welke performance zou je willen bevorderen. Als je dit topic doorneemt dan zul je zien dat DNS erg snel is van zichzelf. En als je problemen hebt met laden van pagina's dat je het eerder ergens anders moet zoeken. Wat je zou kunnen doen is in unbound de config aan te passen zodat er meer gecached word, of je daar blij van word is natuurlijk dan weer de vraag

Uiteraard staat deze als DNS server (custom local) aangegeven. ( 127.0.0.1#5335 ).
Maar dan kan de rest dus uit, of is dat nog een fallback en is er een volgorde?

Ook de DNSMASQ limit 150 max simultaneous requests limiet al ontdekt helaas. Deze net opgehoogd

#### EDIT SETTINGS
dns-forward-max=5096
min-cache-ttl=300
rebind-domain-ok=
#### END EDIT

[Room42]

Get!em schreef op woensdag 11 december 2024 @ 14:28:
[...] Met name duckdns problemen verergerden [...]

Je bent wat dit betreft wel op de hoogte dat die problemen bij DuckDNS liggen? Zie ook nieuws: DuckDNS werkt niet goed vanwege storing

[Webgnome]

Get!em schreef op woensdag 11 december 2024 @ 14:41:
[...]

Uiteraard staat deze als DNS server (custom local) aangegeven. ( 127.0.0.1#5335 ).
Maar dan kan de rest dus uit, of is dat nog een fallback en is er een volgorde?

Ook de DNSMASQ limit 150 max simultaneous requests limiet al ontdekt helaas. Deze net opgehoogd

#### EDIT SETTINGS
dns-forward-max=5096
min-cache-ttl=300
rebind-domain-ok=
#### END EDIT

Als die unbound server gewoon stabiel draait zou ik die andere gewoon er uit halen. Ik draai hier al ~3 jaar met een unbound op een orange pi en dat werkt als een tierelier. Je zou qua performance deze eens kunnen lezen al denk ik dat bij een standaard unbound install je er ook al bent.

[ Voor 13% gewijzigd door Webgnome op 11-12-2024 15:08 ]

[Get!em]

Room42 schreef op woensdag 11 december 2024 @ 14:57:
[...]

Je bent wat dit betreft wel op de hoogte dat die problemen bij DuckDNS liggen? Zie ook nieuws: DuckDNS werkt niet goed vanwege storing

Klopt. Maar vervolgens is de interactie die NextDNS daarop had verergerend

Nu met Pihole en Tailscale ben ik van beide af

[ Voor 5% gewijzigd door Get!em op 11-12-2024 17:14 ]

[Pazo]

Goedenavond,

Ik heb een vraag mbt het verkeer vanuit een andere VLAN naar mijn Pi-hole.


Ik heb (o.a.) een VLAN 20 (192.168.2.x) en een VLAN 30 (192.168.3.x).
Mijn Pi-hole zit in VLAN 20 met vast adres 192.168.2.2
Al het verkeer van de apparaten in VLAN 20 gaat keurig door de Pi-hole en zie ik dus ook terug in het dashboard.
Het verkeer van de apparaten in VLAN 30 niet.
Ik heb overal waar mogelijk (in de settings van de VLAN, in sommige apparaten zelf) het DNS ingesteld naar 192.168.2.2, dus naar de Pi.
VLAN 20 en VLAN 30 kunnen met elkaar praten. Als ik verbinding heb via VLAN 20 kan ik gewoon apparaten in VLAN 30 benaderen en vice versa.

Waarom krijg ik het verkeer van de VLAN 30 apparaten niet door de Pi-hole? Ik heb dit in het verleden wel werkend gehad, maar een tijdje geleden een compleet nieuw netwerk opgezet en nu lukt / werkt het niet meer. Is dit een instelling in de Pi-hole dat is ergens mis, of ligt het toch aan mijn VLAN configuratie? Iemand een idee wat het kan zijn of waar ik moet zoeken?

In de Pi-hole diagnostics zie ik trouwens 1 melding staan, die wel betrekking heeft op een apparaat uit VLAN 30:

Warning in dnsmasq core:
ignoring query from non-local network 192.168.3.6 (logged only once)

De documentatie zegt:

dnsmasq can be configured to only accept queries from at-most-one-hop-away addresses using the option local-service. Other queries are discarded in this case.

This is meant to be a safe default to keep otherwise unconfigured installations safe. Note that local-service is ignored if any access-control config is in place (interface, except-interface, listen-address or auth-server).

Helaas zegt mij dit niet zo veel / reikt mijn kennis te kort, maar ik heb wel het gevoel dat ik bij Pi-hole moet zoeken?

Alvast bedankt.

[Airw0lf]

@Pazo - Pihole zijn vlan ondersteuning is beperkt tot de dashboards.

Wat ik daarmee wil zeggen is dat je met "settings => DNS => Permit all origins" er wel voor kunt zorgen dat Pihole alle DNS aanvragen voor alle vlans gaat beantwoorden. Maar nog steeds voor slechts één vlan ook DHCP server gaat zijn.

Wil je Pihole (of beter DNSMASQ) ook voor alle vlans DHCP server laten zijn, dan zul je in de config-bestandjes-wereld van DNSMASQ moeten duiken.

In beide gevallen gaan de DNS-dashboards je alles laten zien.
Maar alleen in het tweede geval laten de dashboards ook zien voor welke vlans welke IP's er zijn uitgedeeld via DHCP.

[Pazo]

Dank je wel @Airw0lf , ik zal die instelling binnenkort eens testen.

[MAdD]

Airw0lf schreef op woensdag 11 december 2024 @ 22:03:
@Pazo - Pihole zijn vlan ondersteuning is beperkt tot de dashboards.

Wat ik daarmee wil zeggen is dat je met "settings => DNS => Permit all origins" er wel voor kunt zorgen dat Pihole alle DNS aanvragen voor alle vlans gaat beantwoorden. Maar nog steeds voor slechts één vlan ook DHCP server gaat zijn.

Wil je Pihole (of beter DNSMASQ) ook voor alle vlans DHCP server laten zijn, dan zul je in de config-bestandjes-wereld van DNSMASQ moeten duiken.

In beide gevallen gaan de DNS-dashboards je alles laten zien.
Maar alleen in het tweede geval laten de dashboards ook zien voor welke vlans welke IP's er zijn uitgedeeld via DHCP.

of je maakt een bestand je aan in zoals hier onder

code:

nano /etc/dnsmasq.d/02-MAdD.conf

code:

rev-server=VLAN1,gateway
rev-server=VLAN2,gateway

Bijvoorbeeld
rev-server=192.168.1.0/24,192.168.1.1
rev-server=192.168.2.0/24,192.168.2.1

dit zorgt er ook voor, dat alle apparaten die bekend zijn bij de DHCP server ook worden weergegeven in Pi-Hole

[jubeth]

Voor mensen die nog een handig shell-scriptje zochten om een aantal bekende domeinen te whitelisten in pihole (deze hebben voorrang op de blocklists, dus je komt een heel end). Heb het zojuist even afgetikt:
https://gist.github.com/j...428f8d22a7e5107b9d1abc0dc

Je kunt je eigen whitelist domeinen eraan toevoegen in een file, en dit script trekt 2 door mij gebruikte whitelist URLs binnen. Dit is vooral onstaan door collega's en huisgenoten die maar bleven smeken over de-blokkade van bepaalde domeinen.

[Webgnome]

@jubeth ziet er goed uit het eerste wat ik wel als verbeterpuntje zou zien is dat je in de while data gaat chunken en zo meerdere entries tegelijk toevoegd. Nu voeg je voor elke line een entry los toe dat kan beter/sneller

[jubeth]

Webgnome schreef op zaterdag 14 december 2024 @ 13:35:
@jubeth ziet er goed uit het eerste wat ik wel als verbeterpuntje zou zien is dat je in de while data gaat chunken en zo meerdere entries tegelijk toevoegd. Nu voeg je voor elke line een entry los toe dat kan beter/sneller

Dat heb ik geprobeerd, pihole accepteert geen andere optie. Als het je lukt, feel free to fork.
En eerlijk is eerlijk, het hele script kost je minder dan een minuut, dus om tijd/snelheid zit ik nu niet echt te zuchten of zo...

[ Voor 13% gewijzigd door jubeth op 14-12-2024 14:13 ]

[sweetdude]

Ik ben van het weekeinde nog eens bezig geweest om een nieuwe installatie van pihole in combinatie met unbound en pivpn te doen. inclusief een poging om ook ipv6 aan de praat te krijgen
Ondertussen is het gelukt. en heb ik pihole v6 via de dev branch werkend. Ook lijkt het geluk om het via ipv6 werkend te krijgen.
Echter loop ik nog tegen een klein weergave probleempje aan wat ik niet kan verklaren. Mogelijk dat het een tekortkoming van pihole 6 is.

In de "client activity" zie ik weinig clients terug komen van mijn netwerk maar voornamelijk "other clients" en de router. Terwijl in de overzichten top clients total/ blocked ze wel netjes met naam en toenaam staan.

Kan dit komen dat ik bij de conditional forwarding alleen het IPv4 adres heb gebruikt. Of is dit gewoon nog een probleempje van pihole6?

[Get!em]

Pihole draait hier nu bijna een week. Gaat prima. Redelijk snel, al zie ik queries voorbij komen die >90ms zijn.

Sommige sites zijn daarom wat trager met eerste start.

Ook zie ik elke ochtend rond 10u een piek aan verkeer voorbij komen, waardoor pihole een melding maakt dat er afgelopen 15 min meer verkeer is geweest dan geconfigureerde processors (1.2>1). Nog eens uitzoeken wat dat is.
Ook een client max requests voorbij zien komen, die nu iets opgehoogd.

Vooralsnog zijn de statistieken schokkend. 33,6% van al t verkeer wordt geblockt… terwijl alles nog steeds normaal werkt.

[dss58]

Get!em schreef op zondag 15 december 2024 @ 21:35:
Pihole draait hier nu bijna een week. Gaat prima. Redelijk snel, al zie ik queries voorbij komen die >90ms zijn.

Sommige sites zijn daarom wat trager met eerste start.

Ook zie ik elke ochtend rond 10u een piek aan verkeer voorbij komen, waardoor pihole een melding maakt dat er afgelopen 15 min meer verkeer is geweest dan geconfigureerde processors (1.2>1). Nog eens uitzoeken wat dat is.
Ook een client max requests voorbij zien komen, die nu iets opgehoogd.

Vooralsnog zijn de statistieken schokkend. 33,6% van al t verkeer wordt geblockt… terwijl alles nog steeds normaal werkt.

33,6% is niet bijzonder veel, ik weet niet wat voor bloklijst(en) en regex je gebruikt, ik zit ongeveer op 33% met win10 als client bij 2,9 miljoen domains geblokt.
Maar dat het schrikbarend veel is dat is wat mij betreft wel duidelijk.

[Airw0lf]

Get!em schreef op zondag 15 december 2024 @ 21:35:
Pihole draait hier nu bijna een week. Gaat prima. Redelijk snel, al zie ik queries voorbij komen die >90ms zijn.

Sommige sites zijn daarom wat trager met eerste start.

Ook zie ik elke ochtend rond 10u een piek aan verkeer voorbij komen, waardoor pihole een melding maakt dat er afgelopen 15 min meer verkeer is geweest dan geconfigureerde processors (1.2>1). Nog eens uitzoeken wat dat is.
Ook een client max requests voorbij zien komen, die nu iets opgehoogd.

Vooralsnog zijn de statistieken schokkend. 33,6% van al t verkeer wordt geblockt… terwijl alles nog steeds normaal werkt.

Welke externe dns server(s) heb je ingesteld?

Ik zit op 30-40% per 24 uur. Met als uitschieters een Lenovo Android tablet, Levono ChromeOS notebook en een Samsung foon. De tablet spant de kroon met pieken tot 70% - waarschijnlijk door de spelletjes die erop gespeeld worden. Gevolgd door ChromeOS met pieken tot 50% - hier staan geen spelletjes op - is plain ChromeOS.

[Get!em]

Airw0lf schreef op maandag 16 december 2024 @ 07:55:
[...]


Welke externe dns server(s) heb je ingesteld?

Unbound

[Airw0lf]

Get!em schreef op maandag 16 december 2024 @ 08:00:
[...]

Unbound

Dan zit daar waarschijnlijk je vertraging - Unbound gaat bij alle aanvragen te rade bij de root servers van het opgegeven domein. En dat kost gewoon tijd.

[ Voor 6% gewijzigd door Airw0lf op 16-12-2024 08:04 ]

[Get!em]

dss58 schreef op zondag 15 december 2024 @ 22:47:
[...]

ik weet niet wat voor bloklijst(en) en regex je gebruikt,

Oisd big
Adguard dns list
Adguard spyware
Steve black (default)
Firebog easy privacy

Altijd geïnteresseerd in aanvullende lijsten.

[dss58]

Get!em schreef op maandag 16 december 2024 @ 08:07:
[...]

Oisd big
Adguard dns list
Adguard spyware
Steve black (default)
Firebog easy privacy

Altijd geïnteresseerd in aanvullende lijsten.

zoeken op blocklist pihole en je vind er een hele hoop
met regex kun je veel tegen houden
https://github.com/mmotti/pihole-regex

[Get!em]

dss58 schreef op maandag 16 december 2024 @ 09:40:
[...]

zoeken op blocklist pihole en je vind er een hele hoop
met regex kun je veel tegen houden
https://github.com/mmotti/pihole-regex

Wat is de ervaring daar mee? Zie dat het 4 jaar geleden is dat er wat aan gedaan is. Alleen whitelist is een jaar geleden nog bijgewerkt, en er staan best wat issues daarop open.

Voordat ik zomaar code toevoeg aan de pihole...

[dss58]

Get!em schreef op maandag 16 december 2024 @ 10:44:
[...]

Wat is de ervaring daar mee? Zie dat het 4 jaar geleden is dat er wat aan gedaan is. Alleen whitelist is een jaar geleden nog bijgewerkt, en er staan best wat issues daarop open.

Voordat ik zomaar code toevoeg aan de pihole...

Ik zou zeggen, verdiep je is in regular expression (regex)
als voorbeeld dit:
^stat(s|istics)?[0-9]*[_.-]
alles waar stat, stats, statistics in een URL voor komt wordt geblokt, zo moet je het lezen in dit geval, en ik vertel je, is best ingewikkeld
Wikipedia: Regular expression
Is echt de moete waard om er is wat tijd in te steken, het wiel hoef je niet uit te vinden want dat heeft die mmotti op github al voor je gedaan, en het voordeel is dat dit maar 1 keer hoeft, vandaar dat het kort na introductie van regex in pihole is ontwikkeld, 4 jaar geleden dus

[Get!em]

dss58 schreef op maandag 16 december 2024 @ 10:55:
[...]

Ik zou zeggen, verdiep je is in regular expression (regex)
als voorbeeld dit:
^stat(s|istics)?[0-9]*[_.-]
alles waar stat, stats, statistics in een URL voor komt wordt geblokt, zo moet je het lezen in dit geval, en ik vertel je, is best ingewikkeld
Wikipedia: Regular expression
Is echt de moete waard om er is wat tijd in te steken, het wiel hoef je niet uit te vinden want dat heeft die mmotti op github al voor je gedaan, en het voordeel is dat dit maar 1 keer hoeft, vandaar dat het kort na introductie van regex in pihole is ontwikkeld, 4 jaar geleden dus

Ja, ik weet wat regex is, al jaren in gebruik. Maar een script ben ik toch altijd even wat huiveriger voor.

Maar na inlezen zie ik nu, dat de regex gewoon via user-interface in de black/whitelist overzichten erin gezet kunnen worden. No problems

[Raymond P]

Imo een prima uitgangspunt. Bij het zien van een curl gevolgd door een pipe en exec gaat het hier ook kietelen als ik de bron niet ken.

[_Eend_]

Raymond P schreef op maandag 16 december 2024 @ 11:14:
Imo een prima uitgangspunt. Bij het zien van een curl gevolgd door een pipe en exec gaat het hier ook kietelen als ik de bron niet ken.

Nog spannender wordt het als er ook nog een sudo tussen staat.

Dan doe ik wel even een ouderwetsch wget en -na controle- voer ik het script handmatig uit.

[Get!em]

_Eend_ schreef op maandag 16 december 2024 @ 11:23:
[...]


Nog spannender wordt het als er ook nog een sudo tussen staat.

Dan doe ik wel even een ouderwetsch wget en -na controle- voer ik het script handmatig uit.

Nog veiliger:

Je opent gewoon de regex list en copy paste de regels in de userinterface voor black/whitelist
https://github.com/mmotti...ex/blob/master/regex.list

Veel meer doet t script namelijk niet.

[ Voor 4% gewijzigd door Get!em op 16-12-2024 11:39 ]

[Webgnome]

Misschien moeten we niet allemaal regexen / bloklisten toevoegen om het toevoegen maar gericht kijken naar waar de requests vandaan komen, of ze te veklaren zijn en logishc. immers een blockrate van 100% wil je ook niet.

Over unbound, je kunt natuurlijjk als je weet dat er bepaalde domeinen vaak worden geraadpleeg een scriptje maken dat elke x minuten die domeinen opvraagt zodat unbound ze blijft cachen. Het kan ook helpen om eens naar de unbound pagina te gaan en daar de perfomance dingetjes te lezen zodat je de tijd die domeinen gecached blijven word verhoogd.

De spikes die je soms ziet op gezette tijden kan komen door bepaalde devices en je moet je afvragen of dat normaal gedrag is of niet. Mijn computer thuis bijvoorbeeld doet bij eerste opstart iets van 1000 ~ 2000 requests. Als ik dan kijk wat dat allemaal is, dan is dat volkomen normaal ( allemaal services die gestart worden en willen weten of hun dienst nog bestaat )

[Airw0lf]

Kort geleden is me wat raars opgevallen - voor mij dan toch...

Stel een apparaat heeft als fqdn tablet.wifi.lan (Android) of pandora.wired.lan (Windows 11).
Waarbij wifi.lan en wired.lan domeinnamen zijn van een vlan en alleen lokaal leven.

Toch zie ik soms rare DNS aanvragen voorbij komen als microsoft.com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Kort daarvoor zie ik diezelfde aanvraag langskomen - alleen dan zonder wired.lan en wifi.lan.
Waarbij de aanvraag met googleads.g.doubleclick.net geblocked wordt - die met microsoft.com niet.

Iemand een idee waar die rare DNS aanvragen vandaan komen?
Is dit ergens een pihole/dnsmasq instelling of zo?

[ Voor 12% gewijzigd door Airw0lf op 19-12-2024 15:24 ]

[EverLast2002]

Airw0lf schreef op donderdag 19 december 2024 @ 08:34:
Kort geleden is me wat raars opgevallen - voor mij dan toch...

Stel een apparaat heeft als fqdn tablet.wifi.lan (Android) of pandora.wired.lan (Windows 11). Dan zie ik soms DNS aanvragen voorbij komen als microsoft..com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Kort daarvoor zie ik diezelfde aanvraag langskomen - alleen dan zonder wired.lan en wifi.lan.
Waarbij de aanvraag met googleads.g.doubleclick.net geblocked wordt - die met microsoft.com niet.

Iemand een idee waart dit vandaan komt? Is dit ergens een pihole/dnsmasq instelling of zo?

wellicht omdat microsoft.com niet in een blocklist staat (of begrijp ik je vraag niet goed?)

[Airw0lf]

EverLast2002 schreef op donderdag 19 december 2024 @ 14:38:
[...]

wellicht omdat microsoft.com niet in een blocklist staat (of begrijp ik je vraag niet goed?)

Je begrijpt mijn vraag niet - wat wil zeggen dat de vraagstelling niet duidelijk is/was...

Ik zou graag willen weten waar die rare DNS aanvragen vandaan komen.
En dan heb ik het over aanvragen als microsoft.com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Want de domeinen wired.lan en wifi.lan horen bij een vlan - wat alleen maar lokaal leeft.

[EverLast2002]

Airw0lf schreef op donderdag 19 december 2024 @ 15:23:
[...]


Je begrijpt mijn vraag niet - wat wil zeggen dat de vraagstelling niet duidelijk is/was...

Ik zou graag willen weten waar die rare DNS aanvragen vandaan komen.
En dan heb ik het over aanvragen als microsoft.com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Want de domeinen wired.lan en wifi.lan horen bij een vlan - wat alleen maar lokaal leeft.

heb je DNS (Unbound) lokaal draaien icm pi-hole, of laat je alles resolven via een externe DNS server?

[Airw0lf]

EverLast2002 schreef op donderdag 19 december 2024 @ 16:19:
[...]


heb je DNS (Unbound) lokaal draaien icm pi-hole, of laat je alles resolven via een externe DNS server?

Afgezien van de vlan domeinnamen wordt alles extern geresolved via Cloudflare.
Er is dus geen unbound (of vergelijkbaar).

[EverLast2002]

Airw0lf schreef op donderdag 19 december 2024 @ 16:30:
[...]


Afgezien van de vlan domeinnamen wordt alles extern geresolved via Cloudflare.
Er is dus geen unbound (of vergelijkbaar).

En waar heb je je VLANs geconfigureerd, in een router?
Geeft die router eventueel de extensies wifi.lan en wired.lan mee.

[Airw0lf]

EverLast2002 schreef op donderdag 19 december 2024 @ 17:15:
[...]

En waar heb je je VLANs geconfigureerd, in een router?
Geeft die router eventueel de extensies wifi.lan en wired.lan mee.

Nee - de vlans zitten in de DNSMASQ van PiHole.
De default gateway heeft die vlans ook; inclusief domeinnamen.

[nero355]

Airw0lf schreef op donderdag 19 december 2024 @ 08:34:
Kort geleden is me wat raars opgevallen - voor mij dan toch...

Stel een apparaat heeft als fqdn tablet.wifi.lan (Android) of pandora.wired.lan (Windows 11).
Waarbij wifi.lan en wired.lan domeinnamen zijn van een vlan en alleen lokaal leven.

Toch zie ik soms rare DNS aanvragen voorbij komen als microsoft.com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Kort daarvoor zie ik diezelfde aanvraag langskomen - alleen dan zonder wired.lan en wifi.lan.
Waarbij de aanvraag met googleads.g.doubleclick.net geblocked wordt - die met microsoft.com niet.

Iemand een idee waar die rare DNS aanvragen vandaan komen?
Is dit ergens een pihole/dnsmasq instelling of zo?

Dat staat ergens in dit topic uitgelegd, maar ik heb geen idee meer hoe je dat gaat terugvinden of wat de reden precies is dat het gebeurt

Het is ook uitgelegd geweest @ https://discourse.pi-hole.net/ als het goed is dus daar kan je het ook vinden op de een of andere manier...

[Get!em]

Even een crosspost link:

Als je in je netwerk HomeAssistant en Pi-Hole tegelijk hebt, kun je ontdekken dat er 1000+ PTR requests voorbijkomen vanuit HomeAssistant (local network subnet discovery), steeds in kort tijdsbestek, elk uur herhalend.

Ik heb hier een van de mogelijke oplossingen gepost:
Get!em in "Home Assistant: Open source Python3 home automation - deel 5"

[nero355]

@Get!em Maar waarom gebeurt het überhaupt precies dan

Wat een rare toestand...

[Get!em]

nero355 schreef op zondag 22 december 2024 @ 18:34:
@Get!em Maar waarom gebeurt het überhaupt precies dan

Wat een rare toestand...

Normaal handelt je router/dhcp server dit af en zie je t niet.
Met je pihole heb je een ander apparaat dan je router die de local dns requests afhandelt en dat moet met conditional goed gaan.
Het is aantal requests is overigens niet abnormaal, het is gewoon functionaliteit van Home Assistant om op de hoogte te blijven van veranderingen in je netwerk met verbinden slimme apparaten en hun evt dns. Sommige add ons leunen er zelfs geheel op.

Maar zoek maar eens op: “home assistant PTR spamming”. Dan zie je dat heel veel mensen het als irritant ervaren.

[ Voor 8% gewijzigd door Get!em op 22-12-2024 18:54 ]

[nero355]

Get!em schreef op zondag 22 december 2024 @ 18:52:
Normaal handelt je router/dhcp server dit af en zie je t niet.
Met je pihole heb je een ander apparaat dan je router die de dns requests afhandelt en dat moet met conditional goed gaan.

Ja, maar dat is wat anders : Daar gaat het om het voorkomen van IP conflicten

Het is aantal requests is overigens niet abnormaal, het is gewoon functionaliteit van Home Assistant om op de hoogte te blijven van veranderingen in je netwerk met verbinden slimme apparaten en hun evt dns. Sommige add ons leunen er zelfs geheel op.

Maar waarom "pingt" die dan niet gewoon die apparaten i.p.v. je hele netwerk te gaan zitten flooden

Ik ben echt blij dat ik daar niks mee doe in ieder geval, want dat soort dingen vind ik echt totaaaal niet tof !!!

Zo minimaliseer ik ook het Multicast verkeer op mijn netwerk door het een en ander te disablen waar het kan

[Get!em]

nero355 schreef op zondag 22 december 2024 @ 18:57:
[...]

Ja, maar dat is wat anders : Daar gaat het om het voorkomen van IP conflicten


[...]

Maar waarom "pingt" die dan niet gewoon die apparaten i.p.v. je hele netwerk te gaan zitten flooden

Ik ben echt blij dat ik daar niks mee doe in ieder geval, want dat soort dingen vind ik echt totaaaal niet tof !!!

Zo minimaliseer ik ook het Multicast verkeer op mijn netwerk door het een en ander te disablen waar het kan

Originele toevoeging praat over het Discovery deel mbt local names die (nieuwe) apparaten zelf toevoegen.
Dan moet je dus reverse lookup doen over het hele subnet om die te ontdekken.

https://github.com/home-assistant/core/pull/45087

[Raven]

Get!em schreef op vrijdag 20 december 2024 @ 10:37:
Even een crosspost link:

Als je in je netwerk HomeAssistant en Pi-Hole tegelijk hebt, kun je ontdekken dat er 1000+ PTR requests voorbijkomen vanuit HomeAssistant (local network subnet discovery), steeds in kort tijdsbestek, elk uur herhalend.

Ik heb hier een van de mogelijke oplossingen gepost:
Get!em in "Home Assistant: Open source Python3 home automation - deel 5"

nero355 schreef op zondag 22 december 2024 @ 18:34:
@Get!em Maar waarom gebeurt het überhaupt precies dan

Wat een rare toestand...

* Raven doet PiHole checken
42.8% van alle queries zijn PTR , querylog laten filteren op PTR, vrijwel alles van HomeAssistant.

Had er al over gehoord, maar nu net toch maar ff checken, yikes

edit: Elk uur wordt elk IP-adres in de /24 door HASS gecheckt.

[ Voor 3% gewijzigd door Raven op 22-12-2024 19:53 ]

[DaRk PoIsOn]

Het gene dat helpt bij de HA requests is zeroconf en ssdp uitschakelen.
Nadeel is dat je dan je configuration.yaml geheel moet aanpassen.

Post 16,17 en 18:

https://community.home-as...uests-from-hass/307352/16

[Get!em]

DaRk PoIsOn schreef op zondag 22 december 2024 @ 21:01:
Het gene dat helpt bij de HA requests is zeroconf en ssdp uitschakelen.
Nadeel is dat je dan je configuration.yaml geheel moet aanpassen.

Post 16,17 en 18:

https://community.home-as...uests-from-hass/307352/16

Ik heb dus dhcp uitgeschakeld, werkt ook.

Je hoeft de yaml niet aan te passen, zie mijn post, default_config_disabler hacs integratie doet t werk.

[Raven]

@Get!em Maar doet het automatisch detecteren van nieuwe ondersteunde apparaten het dan nog wel? Las ergens dat dat bij het uitschakelen van dhcp niet meer werkt.

[Get!em]

Raven schreef op maandag 23 december 2024 @ 09:16:
@Get!em Maar doet het automatisch detecteren van nieuwe ondersteunde apparaten het dan nog wel? Las ergens dat dat bij het uitschakelen van dhcp niet meer werkt.

Goede kans dat dat niet meer werkt ja.

Maar goed, hoevaak voeg je wat nieuws toe na de eerste twee maanden…

Net getest, met zeroconf en ssdp uit en dhcp aan, krijg ik gewoon weer uurlijks de PTR requests.

[ Voor 11% gewijzigd door Get!em op 23-12-2024 09:28 ]

[Raven]

@Get!em Hmm, die heb ik zo nu en dan wel nodig. Las ook in een van de Github-issues dat sommige integraties dit ook gebruiken om wijzigingen (van IP-adres bijv) via die weg oppikken. Gezien er nogal wat dingen aan HASS hangen, is dat wel nodig.

[Get!em]

Raven schreef op maandag 23 december 2024 @ 09:36:
@Get!em Hmm, die heb ik zo nu en dan wel nodig. Las ook in een van de Github-issues dat sommige integraties dit ook gebruiken om wijzigingen (van IP-adres bijv) via die weg oppikken. Gezien er nogal wat dingen aan HASS hangen, is dat wel nodig.

Ik voorkom dat door de meeste zaken die een internetverbinding hebben een vast op adres te geven in mijn router.

[Raven]

@Get!em Meeste heeft hier static DHCP op basis van mac.

[Cloud_VII]

Heb naast mijn pi-hole nog andere DNS server staan voor het geval mijn pi een keer problemen heeft. Nu ging dit altijd goed.
Na een update op mijn iPhone naar iOS 18.2 lijkt iPhone niet meer de eerste DNS server te kiezen.
Beperk IP adres tracking onder WiFi settings maakt geen verschil. Heb nu handmatig DNS ingesteld met enkel IP naar mijn pihole en dat werkt wel. Meer mensen die dit ervaren?

[W1ck1e]

Cloud_VII schreef op maandag 23 december 2024 @ 13:31:
Heb naast mijn pi-hole nog andere DNS server staan voor het geval mijn pi een keer problemen heeft. Nu ging dit altijd goed.
Na een update op mijn iPhone naar iOS 18.2 lijkt iPhone niet meer de eerste DNS server te kiezen.
Beperk IP adres tracking onder WiFi settings maakt geen verschil. Heb nu handmatig DNS ingesteld met enkel IP naar mijn pihole en dat werkt wel. Meer mensen die dit ervaren?

Als je wilt dat jouw internet blijft werken wanneer je pihole (-raspberrypi) niet functioneert, moet je een 2de pihole installeren op een ander device (mag ook weer een raspberrypi zijn). Afhankelijk van keuzes wordt er verschillende omgegaan met meer dan 1 dns server op een device.

Een normale dns server instellen zorgt ervoor dat je toch advertenties krijgt. Gelukkig is een rpi2 voldoende, helaas zijn die niet meer goed verkrijgbaar.

[ed1703]

W1ck1e schreef op maandag 23 december 2024 @ 13:40:
[...]

Als je wilt dat jouw internet blijft werken wanneer je pihole (-raspberrypi) niet functioneert, moet je een 2de pihole installeren op een ander device (mag ook weer een raspberrypi zijn). Afhankelijk van keuzes wordt er verschillende omgegaan met meer dan 1 dns server op een device.

Hier 2x RPi met PiHole (in docker) en keepalived. Werkt als een zonnetje, kan ook gewoon 1 vd 2 opnieuw installeren of andere werkzaamheden zonder dat het impact heeft. Alleen keepalived even stoppen die ik eruit haal.

[nero355]

W1ck1e schreef op maandag 23 december 2024 @ 13:40:
Gelukkig is een rpi2 voldoende, helaas zijn die niet meer goed verkrijgbaar.

Ik zag laatst iemand een Intel NUC met Atom 2820 en RAM + SSD weggeven dus misschien kom je met een beetje geluk iemand tegen die zijn Raspberry Pi 2B weg wil geven

ed1703 schreef op maandag 23 december 2024 @ 14:35:
Hier 2x RPi met PiHole (in docker) en keepalived. Werkt als een zonnetje, kan ook gewoon 1 vd 2 opnieuw installeren of andere werkzaamheden zonder dat het impact heeft. Alleen keepalived even stoppen die ik eruit haal.

Iets van CARP/VRRP is inderdaad het magische woord als je meerdere Pi-Hole instances gaat draaien


@Get!em @Raven @DaRk PoIsOn

Bedankt voor de info

Echt belachelijk hoe dat Home Assistant geheel in elkaar zit...
Zal eraan denken om die meuk nooit op mijn netwerk te draaien

[Toet3r]

W1ck1e schreef op maandag 23 december 2024 @ 13:40:
[...]

Als je wilt dat jouw internet blijft werken wanneer je pihole (-raspberrypi) niet functioneert, moet je een 2de pihole installeren op een ander device (mag ook weer een raspberrypi zijn). Afhankelijk van keuzes wordt er verschillende omgegaan met meer dan 1 dns server op een device.

Een normale dns server instellen zorgt ervoor dat je toch advertenties krijgt. Gelukkig is een rpi2 voldoende, helaas zijn die niet meer goed verkrijgbaar.

Ik draai al een aantal jaar pihole icm unbound en heb de ervaring dat raspberry pi OS en pihole zo stabiel zijn dat een backup niet nodig is. Daarnaast als je meerdere piholes hebt moet je ze voor goede werking ook gesynchroniseerd houden met bijv Gravity sync of orbital sync.

[W1ck1e]

Toet3r schreef op maandag 23 december 2024 @ 18:48:
[...]

Ik draai al een aantal jaar pihole icm unbound en heb de ervaring dat raspberry pi OS en pihole zo stabiel zijn dat een backup niet nodig is. Daarnaast als je meerdere piholes hebt moet je ze voor goede werking ook gesynchroniseerd houden met bijv Gravity sync of orbital sync.

Eens, maar het punt was meer dat je met een normale dns server de werking van pihole onderuit haalt.

Ik wil wel die redundantie met een extra pihole. En ik doe graag het beheer van de 2 piholes met de hand. Ik ben toch thuis

[ Voor 11% gewijzigd door W1ck1e op 23-12-2024 19:45 ]

[Airw0lf]

Get!em schreef op vrijdag 20 december 2024 @ 10:37:
Even een crosspost link:

Als je in je netwerk HomeAssistant en Pi-Hole tegelijk hebt, kun je ontdekken dat er 1000+ PTR requests voorbijkomen vanuit HomeAssistant (local network subnet discovery), steeds in kort tijdsbestek, elk uur herhalend.

Ik heb hier een van de mogelijke oplossingen gepost:
Get!em in "Home Assistant: Open source Python3 home automation - deel 5"

Dit werkt voor mij niet.

Uiteindelijk "opgelost" door de HASS-VM alleen nog maar in het domotica/iot-vlan actief te laten zijn. En te voorzien van AdGuard. Hierdoor blijven alle DNS aanvragen lokaal.

[Airw0lf]

Airw0lf schreef op donderdag 19 december 2024 @ 08:34:
Kort geleden is me wat raars opgevallen - voor mij dan toch...

Stel een apparaat heeft als fqdn tablet.wifi.lan (Android) of pandora.wired.lan (Windows 11).
Waarbij wifi.lan en wired.lan domeinnamen zijn van een vlan en alleen lokaal leven.

Toch zie ik soms rare DNS aanvragen voorbij komen als microsoft.com.wired.lan en googleads.g.doubleclick.net.wifi.lan.

Kort daarvoor zie ik diezelfde aanvraag langskomen - alleen dan zonder wired.lan en wifi.lan.
Waarbij de aanvraag met googleads.g.doubleclick.net geblocked wordt - die met microsoft.com niet.

Iemand een idee waar die rare DNS aanvragen vandaan komen?
Is dit ergens een pihole/dnsmasq instelling of zo?

Ik denk de oorzaak gevonden te hebben - namelijk Pi-Hole...

Als een site geblocked wordt dan doen sommige sites (niet allemaal) een poging door het subdomein van de client toe te voegen aan het host-deel van de URL. In de hoop/verwachting dat die dan wel geresolved wordt waardoor ze alsnog hun dingetje kunnen doen.

Op het moment dat die URL of dat apparaat is ge-white-list wordt de initiële aanvraag gewoon beantwoordt en is een aanvraag met het lokale subdomein niet meer nodig.

[TheCeet]

Hotfix release voor Fedora 41 users:

This release is purely a hotfix to fix installing v5 on Fedora 41 - there is nothing relevant to users on other operating systems

v5.18.4 changelog

[sweetdude]

Ik kwam deze unbound.conf nog tegen, die mij de moeite waard leek om hier te delen. Aangezien er wat extra info en parameters instaan dan de standaard die vaak bij de Pi Hole tutorials staan.
Misschien dat er nog wat mensen zijn die hier aanvullingen/ opmerkingen over hebben?

Bron:
https://github.com/anudeepND/pihole-unbound

code:

server:

    # The  verbosity  number, level 0 means no verbosity, only errors.
    # Level 1 gives operational information. Level  2  gives  detailed
    # operational  information. Level 3 gives query level information,
    # output per query.  Level 4 gives  algorithm  level  information.
    # Level 5 logs client identification for cache misses.  Default is
    # level 1.
    verbosity: 0
    
    interface: 127.0.0.1
    port: 5335
    do-ip4: yes
    do-udp: yes
    do-tcp: yes
    
    # May be set to yes if you have IPv6 connectivity
    do-ip6: no

    # You want to leave this to no unless you have *native* IPv6. With 6to4 and
    # Terredo tunnels your web browser should favor IPv4 for the same reasons
    prefer-ip6: no
    
    # Use this only when you downloaded the list of primary root servers!
    # Read  the  root  hints from this file. Make sure to 
    # update root.hints evry 5-6 months.
    root-hints: "/var/lib/unbound/root.hints"
    
    # Trust glue only if it is within the servers authority
    harden-glue: yes
    
    # Ignore very large queries.
    harden-large-queries: yes
    
    # Require DNSSEC data for trust-anchored zones, if such data is absent, the zone becomes BOGUS
    # If you want to disable DNSSEC, set harden-dnssec stripped: no
    harden-dnssec-stripped: yes
    
    # Number of bytes size to advertise as the EDNS reassembly buffer
    # size. This is the value put into  datagrams over UDP towards
    # peers. The actual buffer size is determined by msg-buffer-size
    # (both for TCP and UDP).
    edns-buffer-size: 1232
    
    # Rotates RRSet order in response (the pseudo-random 
    # number is taken from Ensure privacy of local IP 
    # ranges the query ID, for speed and thread safety).  
    # private-address: 192.168.0.0/16
    rrset-roundrobin: yes
    
    # Time to live minimum for RRsets and messages in the cache. If the minimum
    # kicks in, the data is cached for longer than the domain owner intended,
    # and thus less queries are made to look up the data. Zero makes sure the
    # data in the cache is as the domain owner intended, higher values,
    # especially more than an hour or so, can lead to trouble as the data in
    # the cache does not match up with the actual data anymore
    cache-min-ttl: 300
    cache-max-ttl: 86400
    
    # Have unbound attempt to serve old responses from cache with a TTL of 0 in
    # the response without waiting for the actual resolution to finish. The
    # actual resolution answer ends up in the cache later on. 
    serve-expired: yes
    
    # Harden against algorithm downgrade when multiple algorithms are
    # advertised in the DS record.
    harden-algo-downgrade: yes
    
    # Ignore very small EDNS buffer sizes from queries.
    harden-short-bufsize: yes
    
    # Refuse id.server and hostname.bind queries
    hide-identity: yes
    
    # Report this identity rather than the hostname of the server.
    identity: "Server"
    
    # Refuse version.server and version.bind queries
    hide-version: yes
    
    # Prevent the unbound server from forking into the background as a daemon
    do-daemonize: no
    
    # Number  of  bytes size of the aggressive negative cache.
    neg-cache-size: 4m
    
    # Send minimum amount of information to upstream servers to enhance privacy
    qname-minimisation: yes
    
    # Deny queries of type ANY with an empty response.
    # Works only on version 1.8 and above
    deny-any: yes

    # Do no insert authority/additional sections into response messages when
    # those sections are not required. This reduces response size
    # significantly, and may avoid TCP fallback for some responses. This may
    # cause a slight speedup
    minimal-responses: yes
    
    # Perform prefetching of close to expired message cache entries
    # This only applies to domains that have been frequently queried
    # This flag updates the cached domains
    prefetch: yes
    
    # Fetch the DNSKEYs earlier in the validation process, when a DS record is
    # encountered. This lowers the latency of requests at the expense of little
    # more CPU usage.
    prefetch-key: yes
    
    # One thread should be sufficient, can be increased on beefy machines. In reality for 
    # most users running on small networks or on a single machine, it should be unnecessary
    # to seek performance enhancement by increasing num-threads above 1.
    num-threads: 1

    # more cache memory. rrset-cache-size should twice what msg-cache-size is.
    msg-cache-size: 50m
    rrset-cache-size: 100m
   
    # Faster UDP with multithreading (only on Linux).
    so-reuseport: yes
    
    # Ensure kernel buffer is large enough to not lose messages in traffix spikes
    so-rcvbuf: 4m
    so-sndbuf: 4m
    
    # Set the total number of unwanted replies to keep track of in every thread.
    # When it reaches the threshold, a defensive action of clearing the rrset
    # and message caches is taken, hopefully flushing away any poison.
    # Unbound suggests a value of 10 million.
    unwanted-reply-threshold: 100000
    
    # Minimize logs
    # Do not print one line per query to the log
    log-queries: no
    # Do not print one line per reply to the log
    log-replies: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    log-servfail: no
    # Do not print log lines to inform about local zone actions
    log-local-actions: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    logfile: /dev/null
    
    # Ensure privacy of local IP ranges
    private-address: 192.168.0.0/16
    private-address: 169.254.0.0/16
    private-address: 172.16.0.0/12
    private-address: 10.0.0.0/8
    private-address: fd00::/8
    private-address: fe80::/10

Toevoegingen ten opzichte van de default:

code:

    # Ignore very large queries.
    harden-large-queries: yes

code:

    # Rotates RRSet order in response (the pseudo-random 
    # number is taken from Ensure privacy of local IP 
    # ranges the query ID, for speed and thread safety).  
    # private-address: 192.168.0.0/16
    rrset-roundrobin: yes

code:

    # Time to live minimum for RRsets and messages in the cache. If the minimum
    # kicks in, the data is cached for longer than the domain owner intended,
    # and thus less queries are made to look up the data. Zero makes sure the
    # data in the cache is as the domain owner intended, higher values,
    # especially more than an hour or so, can lead to trouble as the data in
    # the cache does not match up with the actual data anymore
    cache-min-ttl: 300
    cache-max-ttl: 86400

code:

    # Have unbound attempt to serve old responses from cache with a TTL of 0 in
    # the response without waiting for the actual resolution to finish. The
    # actual resolution answer ends up in the cache later on. 
    serve-expired: yes

code:

    # Harden against algorithm downgrade when multiple algorithms are
    # advertised in the DS record.
    harden-algo-downgrade: yes

code:

    # Ignore very small EDNS buffer sizes from queries.
    harden-short-bufsize: yes

code:

    # Refuse id.server and hostname.bind queries
    hide-identity: yes

code:

    # Report this identity rather than the hostname of the server.
    identity: "Server"

code:

    # Refuse version.server and version.bind queries
    hide-version: yes

code:

    # Prevent the unbound server from forking into the background as a daemon
    do-daemonize: no

code:

    # Number  of  bytes size of the aggressive negative cache.
    neg-cache-size: 4m

code:

    # Send minimum amount of information to upstream servers to enhance privacy
    qname-minimisation: yes

code:

    # Deny queries of type ANY with an empty response.
    # Works only on version 1.8 and above
    deny-any: yes

code:

    # Do no insert authority/additional sections into response messages when
    # those sections are not required. This reduces response size
    # significantly, and may avoid TCP fallback for some responses. This may
    # cause a slight speedup
    minimal-responses: yes

code:

    # Fetch the DNSKEYs earlier in the validation process, when a DS record is
    # encountered. This lowers the latency of requests at the expense of little
    # more CPU usage.
    prefetch-key: yes

code:

    # more cache memory. rrset-cache-size should twice what msg-cache-size is.
    msg-cache-size: 50m
    rrset-cache-size: 100m

code:

    # Faster UDP with multithreading (only on Linux).
    so-reuseport: yes

code:

    # Ensure kernel buffer is large enough to not lose messages in traffix spikes
    so-rcvbuf: 4m
    so-sndbuf: 4m

code:

    # Set the total number of unwanted replies to keep track of in every thread.
    # When it reaches the threshold, a defensive action of clearing the rrset
    # and message caches is taken, hopefully flushing away any poison.
    # Unbound suggests a value of 10 million.
    unwanted-reply-threshold: 100000

code:

    # Minimize logs
    # Do not print one line per query to the log
    log-queries: no
    # Do not print one line per reply to the log
    log-replies: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    log-servfail: no
    # Do not print log lines to inform about local zone actions
    log-local-actions: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    logfile: /dev/null

[ Voor 38% gewijzigd door sweetdude op 01-01-2025 11:18 ]

[nero355]

sweetdude schreef op dinsdag 31 december 2024 @ 12:01:
Aangezien er wat extra info en parameters instaan dan de standaard die vaak bij de Pi Hole tutorials staan.
Misschien dat er nog wat mensen zijn die hier aanvullingen/ opmerkingen over hebben?

- Noem dan effe de verschillen op ?!
- Zet lange CODE blokken tussen QUOTE Tags

[sweetdude]

nero355 schreef op dinsdag 31 december 2024 @ 17:40:
[...]

- Noem dan effe de verschillen op ?!
- Zet lange CODE blokken tussen QUOTE Tags

code:

beter?

[TheByteBoy]

Heeft iemand wel eens gewerkt met reply type in een regular expression?

Ik heb bij Domains > Regex de volgende toegevoegd (Default group, Regex whitelist):

code:

(\.|^)mijndomein\.iets$;reply=192.168.1.1

Als ik het goed begrijp zou dat betekenen dat als ik op een client in nslookup randomnaam.mijndomein.iets invul, pihole altijd 192.168.1.1 als reply zou moeten geven.
Dit werkt echter niet, nslookup geeft

code:

*** pi.hole can't find randomnaam.mijndomein.iets: Non-existent domain

In de Query log staat NXDOMAIN als reply

Als ik op de pihole console het volgende uitvoer

code:

pihole-FTL regex-test randomnaam.mijndomein.iets

Dan krijg ik

code:

[i] Checking domain against whitelist...
    (\.|^)mijndomein\.iets$;reply=192.168.1.1 matches (regex whitelist, DB ID 12)
    Hint: This regex forces reply type IP

Dus mijn regex wordt wel geraakt. Waarom geeft deze dan NXDOMAIN als reply ipv 192.168.1.1?

Update: als ik er een regex blacklist van maak, dan werkt het. Ik begrijp nog niet goed waarom, maar ik kan weer verder

[ Voor 5% gewijzigd door TheByteBoy op 01-01-2025 17:25 ]

[nero355]

sweetdude schreef op woensdag 1 januari 2025 @ 15:35:

LOL!

sweetdude schreef op dinsdag 31 december 2024 @ 12:01:

code:

    # Time to live minimum for RRsets and messages in the cache. If the minimum
    # kicks in, the data is cached for longer than the domain owner intended,
    # and thus less queries are made to look up the data. Zero makes sure the
    # data in the cache is as the domain owner intended, higher values,
    # especially more than an hour or so, can lead to trouble as the data in
    # the cache does not match up with the actual data anymore
    cache-min-ttl: 300
    cache-max-ttl: 86400

code:

    # Minimize logs
    # Do not print one line per query to the log
    log-queries: no
    # Do not print one line per reply to the log
    log-replies: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    log-servfail: no
    # Do not print log lines to inform about local zone actions
    log-local-actions: no
    # Do not print log lines that say why queries return SERVFAIL to clients
    logfile: /dev/null

Bovenstaande kan eventueel nuttig zijn :
- Sommige dingen wat langer in Cache houden ook al is de Minimum waarde maar 5 x 60 seconden...
- De Logging een beetje beperken om je microSDXC kaartje te ontzien

Echter vind ik dit best wel stupid :

code:

    # Have unbound attempt to serve old responses from cache with a TTL of 0 in
    # the response without waiting for the actual resolution to finish. The
    # actual resolution answer ends up in the cache later on. 
    serve-expired: yes

En zelfs conflicterend met bovenstaande Min/Max TTL Caching verhaal

Alle andere dingen kan je IMHO negeren, want :
- Zien je Pi-Hole als EVIL terwijl de kans daarop 0,0 is over het algemeen.
- Hardening die alleen nuttig is als je direkt aan het Internet gaat hangen.
- Andere dingen die op 127.0.0.1 geen nut hebben...
- Hier en daar dingen die misschien wat resources zullen schelen, maar je waarschijnlijk nooit tegenaan zal lopen...

Mijn gok is dat de beste meneer ietsje te enthousiast los is gegaan met zoveel mogelijk meuk toepassen waarvan hij niet helemaal de werking begrijpt

[Asprine]

Hi, loop te stoeien met mijn whitelist. Sinds een week geeft Tradingview.com aan dat ik een adblocker aan heb staan en blokkeert zelf de content.
Wat ik deed:
Dubbel checken gedaan of Pihole de trigger is, als ik die uitzet geen pop up. Dus ja.
Controleerde wat Tradingview aanroept en alles gewhitelist. Geen succes TV blijft mekkeren dat ik een adblocker aan heb staan.

Wat zie ik over het hoofd?
Wat moet ik whitelisten/doen om TV wel te laten werken,( prima als daar wel ads te zien zijn als het maar werkt.)
Thanks