Software-update: Pi-hole Core 4.3.5

Pi-hole versie 4.3.3, die gisteren is verschenen, kende helaas enkele foutjes en is in korte tijd twee keer van een update voorzien. Pi-hole is een advertising-aware dns- en webserver bedoeld om te draaien op een Raspberry Pi in het netwerk. Als op de router naar Pi-hole wordt verwezen voor dns-afhandelingen, zullen alle apparaten binnen het netwerk er automatisch gebruik van maken zonder dat er instellingen moeten worden aangepast. Vervolgens worden advertenties niet meer opgehaald, waardoor pagina's sneller laden. In potentie kan er ook malware mee buiten de deur worden gehouden. Voor meer informatie verwijzen we jullie door naar de uitleg en video's op deze pagina, of deze handleiding van tweaker jpgview. Sinds versie 4.3.3 zijn de volgende verbeteringen aangebracht:

Pi-hole Core v4.3.5
Apologies for all the release excitement folks!

• Fix an issue with the grep command when trying to detect the latest version of FTL

Pi-hole Core v4.3.4

• Contains an additional commit that we did not cherry pick into 4.3.3. Resolves issues with FTL saying there was an update, even though there was not one.
• Fixes debug process to properly show the running daemon on required ports, shows green/red comparison.

Versienummer	4.3.5
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Pi-hole
Download	https://github.com/pi-hole/pi-hole/releases/tag/v4.3.5
Licentietype	GPL

Reacties (99)

Hoe zit het in v5.0 met hardcoded DNS zoals op Google Chromecast?

Pihole kan alleen DNS requests behandelen die by het device toekomen. Als Je DHCP server b.v. 192.168.2.14 als DNS server aanbied, en Chromecast negeert dit (door de hardcoded DNS entry 8.8.8.8) kan je dit alleen opvangen door op je firewall een NAT rule te configureren die all DNS requests die NIET VAN PIHOLE KOMEN, om te leiden naar pihole. Heeft niets met pihole te maken, gelijk welk ander product dat je in je network plaatst kan alleen een antwoord geven als het een vraag krijgt. Chromecast vraagt niets (aan pihole), pihole kan dus ook niet antwoorden.

In Openwrt de volgende regel invoeren is de oplossing voor alle brakke devices met hardcoded DNS.

#keep network on pi-hole
iptables -t nat -I PREROUTING -i br-lan -p tcp --dport 53 -j DNAT --to 10.0.0.xx:53
iptables -t nat -I PREROUTING -i br-lan -p udp --dport 53 -j DNAT --to 10.0.0.xx:53

#punch DNS hole for pi-hole
iptables -t nat -I PREROUTING -i br-lan -p tcp -s 10.0.0.xx --dport 53 -j ACCEPT
iptables -t nat -I PREROUTING -i br-lan -p udp -s 10.0.0.xx --dport 53 -j ACCEPT

Je kan die ook consolideren tot:

iptables -t nat -I PREROUTING -i br-lan -p tcp --dport 53 -s ! 10.0.0.xx -j DNAT --to 10.0.0.xx:53
iptables -t nat -I PREROUTING -i br-lan -p udp --dport 53 -s ! 10.0.0.xx -j DNAT --to 10.0.0.xx:53

(dus effectief zeg je dan dat alles wat op port 53 binnenkomt, en NIET van je pi-hole afkomt, moet doorgestuurd worden naar je pi-hole)

Ik heb jouw regels even getest, maar deze werken niet bij mij. Misschien een beetje een noob vraag maar wat is het voordeel van consolideren?

Gewoon minder regels. Verder niet een concreet voordeel. Nettere configuratie

Dank voor de zeer verhelderende uitleg. De iptables van @mocem lijken te werken met mijn Openwrt router. (ingevoerd als custom firewall rule in LuCI) Ik krijg nu alle quries te zien van de Chromecast.

Dit is misschien wat makkelijker te doen door alle traffic te blocken wat via 53 tcp/udp naar buiten probeert te gaan. (Behalve je Pi-hole host ofc)
Dan vallen je google devices terug op je dhcp lease.

Mijn Pi-hole draait ook als DHCP, maar het probleem van hardcoded DNS devices is irritant. Ik heb (helaas) een Experiabox V10. Is het op dat apparaat mogelijk om zo'n NAT rule in te stellen die jij beschrijft of wat dat niet ondersteund op de V10?

Experiabox V10. Is het op dat apparaat mogelijk om zo'n NAT rule in te stellen

geen idee, ik gebruik pfsense. Als het niet kan, is het een zwakke schakel (aandachtspunt - security) in je netwerk, en moet je overwegen een volwaardige firewall/router te kopen, of er zelf een te bouwen (hardware + b.v. pfsense of OPNsense)

Moet ik opnieuw Pi-Hole installeren of is het "gewoon" een update? pihole -up

Thanks!

Btw, wat ik iedereen kan aanraden is een 2e Pi-Hole als backup. De eerste een 2 of 3 en dan als backup een 2 of een zero. Liever een 2, geen gedoe met dongels etc. Ik had al een paar keer een Pi-Hole, maar daar deed hij het op een gegeven moment niet meer, nu dat ik er 2 heb, 1tje primary en 1tje secondary werkt het echt goed, tot nu toe geen problemen etc. Ook lekker snel met meerdere blacklists.

Het probleem met een secondary DNS server moeten gebruiken is dat bijvoorbeeld Windows 7 en hoger, pas na één seconde de secondary DNS server gaat gebruiken 'per zoekopdracht'. Windows zal niet zelf de eerste DNS server 'uitschakelen' en na een tijdje weer proberen. Elk DNS-verzoek duurt dan dus minimaal 1 seconde (wat uiteraard onwerkbaar lang is. Internetverkenners bouwen wel een cache op waardoor het surfen in elk geval 'redelijk' zal gaan)
https://support.microsoft...lient-resolution-timeouts

Bij Linux en de populaire UNIXen is dit zelfs 2 of 5 seconden afhankelijk van de distro. (is in te stellen, je kan ze ook roulerend gebruiken, maar dan krijg je onvoorspelbaar gedrag)
https://linux.die.net/man/5/resolv.conf

Een Secondary DNS is leuk, maar je moet er niet van afhankelijk willen zijn.

Je kunt je beter afvragen waarom dat die ene het ineens niet meer deed? Zelf heb ik pihole op een zero draaien en dat draaid gewoon als een zonnetje. Het is niet zo heel complexe software dat je daar superveel power voor nodig heb.

Daar geef ik je gelijk in, wat ik ook graag wil is een snappy GUI. Dat had ik toen niet met de blacklists die ik had, hij was zo langzaam..

En ja, ik heb gekeken waarom hij zo langzaam was en het dan op een gegeven moment niet meer deed. Tot vandaag nog steeds geen idee waarom.

Hoe ik het heb ingesteld is in me modem de 1ste Pi als Primary en de 2e Pi als secondary, dan primary pi 1.1.1.1 en 1.1.1.1 en de secondary op 1.0.0.1 en 1.0.0.1. Werkt letterlijk echt snel. En ja ik ben gewend aan snelle aanvragen en merk ook wel als het wat langer duurt dan normaal.

Wat ik dan probeer is de primary en secondary op mijn 1ste Pi te leggen. Kijken hoe dat werkt. Dan kan ik me ander Pi voor wat anders gebruiken

Zou iemand mij in de richting van een goede (actuele, v5) guide kunnen wijzen waarin staat wat ik precies moet kopen en moet doen om zo'n PiHole goed op te zetten?

v5 is nog niet gereleased, voorlopig moet je een 4.3.5 opzetten, en dan de instructies uit de announcement toepassen (OK, enough reading.. how do I switch to the beta?)

Ik ben bezig met de pihole v5 manual voor te bereiden, een aantal secties zijn klaar, hier dus (draft). Als er iets niet klopt, hoor ik dat graag.

Als je beta5 instaleerd, doe je er goed aan dagelijks 'pihole -up' te draaien.

Onlangs onderstaande blocklist gaan gebruiken wat echt een absolute aanrader is!
https://dbl.oisd.nl

De blocklist https://dbl.oisd.nl van @sjhgvr levert bij mij ruim 900.000 extra domains op en nu staat het totaal in de Pi-Hole op 1.030.454 domains.

Misschien kan iemand mij vertellen, waarom zoveel noodzakelijk is? Ik begrijp natuurlijk dat hoe meer domains door de Pi-Hole kunnen worden geblockt, hoe beter/fijner het browsen is. Maar is het motto 'hoe meer, hoe beter' echt beter? Of is dit ( niet boos worden, ik bedoel het goed !! ) typisch weer Nederlandse verzameldrift, zoals je wel vaker ziet?

Je zou denken, dat hoe meer domains, hoe trager de Pi-Hole wordt. Zijn er echt zoveel domains in 'onze omgeving' of is deze lijst een samenvoegen van lijsten van over de hele wereld? Waarvan een zeer groot percentage, voor mij ( een doorsnee Nederlander, die af en toe, hier en daar browsed ) gewoon overhead is, omdat de kans dat ik die sites ooit bezoek minimaal is.

Misschien zou een blocklist per regio ( b.v. Europa ) + de top 5.000 ( noem wat ) van de wereld, veel beter zijn ?

[Reactie gewijzigd door PsiTweaker op 25 februari 2020 10:58]

Meer is zeker niet beter. Meer domeinen hoeft ook zeker niet te betekenen dat browsen prettiger is.

Hoe dat de oisd lijst samengesteld wordt kun je nalezen op de reddit pagina.

Van de hoeveelheid domeinen zou je niks moeten merken in snelheid. Wel zal wat meer RAM in gebruik zijn op de Pi-hole.

Één lijst, ten kost van wat extra geheugen gebruik. En wil je dat niet, gebruik je de lijst toch niet?

Wel zal wat meer RAM in gebruik zijn op de Pi-hole.

Niet langer in Beta5 (soon v5)

quote
And since we’re not holding any gravity domain (but only the root of the tree) in memory, there is also not really a difference in memory usage here (in fact, Pi-hole v5.0 should use less memory for everyone!).
/quote

zie hier voor meer context over aantal regels vs efficientie.

Nog leuker; deze blocklist is van een tweakers. Namelijk @sjhgvr

Grappig! Heb er via Reddit een aantal keer contact mee gehad over whitelisten van domains

En inderdaad de beste blocklist die er momenteel is!

Op welke site staat meer informatie over deze blocklist?
(Bedankt alvast)

https://redd.it/dwxgld

Gebruik ik ook inderdaad, maar nog te weinig om er iets van te vinden

Hier meer info over de blocklist van @sjhgvr
https://www.reddit.com/r/...rnets_1_domain_blocklist/

Niets ten nadele van deze lijst, gezien de beperkingen van Pi-Hole, maar zie ook: jpgview in 'downloads: Pi-hole Core 4.3.5' (=enkel om context te geven betreffende het aantal blacklist regels en effectiviteit)

[Reactie gewijzigd door Tomazzo op 26 februari 2020 09:56]

Pi-Hole kan alleen geen CNAME requests blokken en gebruikt niet de wildcard domain blocking functies die in dnsmasq zitten (Pi-Hole is een web UI bovenop dnsmasq). Een lijst als iosd is daarom mega groot, omdat men voor iedere losse sub-hostname een regel aan moet maken (ad1.ads.google.com, ad2.ads.google.com ipv een regel ads.google.com). Altijd vreemd gevonden dat ze dit niet doen, maar wel regex implementeren (= veeel trager dan address= rules in dnsmasq).

Voor de beste dns filtering kun je tegenwoordig veel beter dnscrypt-proxy gebruiken icm met https://github.com/notracking/hosts-blocklists zie: https://github.com/notrac...ki/Install-dnscrypt-proxy

Pi-Hole kan alleen geen CNAME requests blokken

Pihole beta5 kan dit wel, en doet het zelfs op zo een manier dat je via de web interface heel eenvoudig kan achterhalen welke CNAME verantwoordelijk is voor de domain block.

niet de wildcard domain blocking functies die in dnsmasq zitten

Deze discussie steekt af en toe de kop op. Er zijn verschillende scripts in omloop om de gravity list van pihole op te splitsen in een verkorte gravity list en een dnsmasq wildcard config file. Probleem hiermee is dat tegen de tijd dat het script klaar is met de conversie, de block lists een update hebben gekregen, en je dus opnieuw kan beginnen. Het is trouwens perfect mogelijk zelf een statische conf file te maken, waarin je de dnsmasq syntax voor wildcards gebruikt, die heeft dan wel niets meer te maken met de weekly update (is beschreven in mijn manual).

maar wel regex implementeren (= veeel trager dan address= rules in dnsmasq)
Opnieuw, in beta 5 kunnen de regex entries (whitelist en blacklist) gebruikt worden om per client blocking op te zetten. Dit maakt het mogelijk dat een domain op het toestel van je WAG gewhitelist word, op je eigen toestel geblockt blijft, wat het aantal huiselijke conflicten drastisch zal verminderen. Ik heb zelf nooit getest of dnsmasq wildcard zoveel sneller is dan regex, wel weet ik dat je voor wijzigingen aan een conf file (bestand waarin de dnsmasq wildcard entries address= zijn opgelijst) pihole-FTL (= dnsmasq +) moet herstarten, wat een network onderbreking tot gevolg heeft, die best lang kan duren (afhankelijk van het aantal blocklist entries. Een wijziging aan regex, whitelist en blacklist daarentegen word aan pihole-FTL gemeld met een USR signal (load new data), pihole-FTL stopt er dus niet mee, geen network onderbreking.

Voor de beste dns filtering kun je tegenwoordig veel beter dnscrypt-proxy gebruiken

Prima keuze, als je alle problemen kan oplossen zonder web interface, voor de doorsnee gebruiker (niet tweaker) niet echt een oplossing. Iedereen gebruikt uiteraard de oplossing die hij / zij wil, Er is ook nog AdGuard Home, er zijn mensen die zijn overgestapt, echter, als je over dnscrypt-proxy of AdGuard Home wil discussieren, moet je maar eens een nieuwe download aan melden, wanneer er een update te voorschijn komt.

Beta5 is ondertussen uiterst stabiel, het aantal aangemelde beta5 problemen op discourse is in de laatste week drastisch gedaald, wat er nog openstaat (niet opgelost) zijn requests van mensen die het nooit genoeg zullen vinden. Als je een en ander wil automatiseren, zal het nodig zijn je sqlite3 kennis op te poetsen, zonder sqlite3 valt er niet veel meer te scripten.

Ik draai beta5 nu drie weken, als primary pihole, zonder noemenswaardige problemen, heb een business case gevonden voor client based regex whitelist (groupmanagement), oplossing werkt perfect (whitelist op android toestellen, blacklist op de rest). Mijn pihole 5 draft manual hier, er word nog aan gewerkt...

CNAME - Goed om te zien dat daar aan gewerkt word!

Wildcard - Is Pi-Hole ondertussen al overgestapt van hostname filters (0.0.0.0 ads.google.com) naar domain filters (address=/ads.google.com/#)? Pas als dit het geval is kan men efficientere blocklists gebruiken, zoals de hiervoor genoemde. Pi-Hole gebruikt toch al een branched versie van dnsmasq, waarom dan niet een reload functie toevoegen om de lokale cache te flushen en de blocklists opnieuw in te lezen? (100.0000 address regels laden in minder dan 1 seconden op mijn lowpowered systeem). Alternatief is om een secondary dns te hosten en deze sequencieel te restarten als 2 seconden downtime niet acceptabel is.

REGEX - Dit gebruiken om *.ads.google.com en ads.google.com te blokkeren is gewoon erg traag (REGEX vs STRCMP), dit ga je zeker merken in situaties met veel clients. Ik heb dit zelf ook ondervonden bij het ontwikkelen van een content filter (+dns blocking) addon voor Squid.

address=/ads.google.com/#

Deze syntax is toegevoegd aan dnsmasq v2.81, en zal, volgens de pihole developpers nooit gebruikt worden, omdat die regels in een conf file zitten, voor een conf file moet dnsmasq (en dus ook pihole-FTL) herstart worden, wat een onderbreking tot gevolg heeft. De developers willen zo weinig mogelijk aan de originele source code wijzigen, om toe te laten eventuele nieuwe versies van dnsmasq te kunnen blijven volgen (alle wijzigingen die de developpers hebben toegevoegd opnieuw in de nieuwere versie van dnsmasq aanbrengen).

REGEX - Dit gebruiken om *.ads.google.com en ads.google.com te blokkeren

het is niet aan te raden om voor dit doel twee regex regels te gebruiken. Velen onder ons gebruiken al een hele tijd de regex list van mmotti. De eerste regex in die lijst alleen al, vervangt de regex entries die jij hebt aangehaald, en nog veel meer.

Niet heel erg relevant, maar het '#' (NXDOMAIN) deel van de address= config optie is bij 2.81 geintroduceerd, address= bestaat al veel langer in dnsmasq.

Het probleem van het niet willen implementeren van de address opties is dat een lijst zoals oisd nooit fatsoenlijke dekking kan geven door ad servers met dynamische subdomeinen. Zie als klein voorbeeld:

# curl -s https://dbl.oisd.nl/ |grep "302br\.net" |wc -l
17978

Alleen dit zijn al 18k regels voor een enkel domein die geeneens effectief zijn (actief gebruike hostnames van 302br.net staan er geeneens in). Dit is ook de reden dat Pi-Hole lists zo onnodig groot worden en nooit de juiste dekking kunnen geven, zonder duizenden REGEX filters toe te voegen (dat wat de developers zelf ook adviseren om niet te doen..). De notracking lijst icm dnscrypt of een adblockplus gebaseerde dns resolver heeft daarom met 100k regels vele malen meer dekking als Pi-Hole lijsten met miljoenen+ regels.

De AdblockPlus standaard voor network filters werkt ook zoals deze in dnscrypt-proxy geimplementeerd zijn (||302br.net^ == address=/302br.net/# == *.302br.net + 302br.net)

Ps. Zie ook AdblockPlus commentaar over het gebruik van REGEX filters: https://help.eyeo.com/en/...-to-write-filters#regexps
En hier voor meer achtergrond over optimale blocklist syntax (Pi-Hole gebruikt alleen de `=example.com` variant): https://github.com/DNSCry...i/Filters#filter-patterns

[Reactie gewijzigd door Tomazzo op 26 februari 2020 11:00]

Het probleem van het niet willen implementeren van de address opties ...

Niets dat je tegenhoud zelf een fork van dnsmasq of pihole-FTL (of zelfs pihole) te maken, waarin je die mogelijkheid toevoegd. Wie weet, misschien word het een hit.

Blijf je echter pihole gebruiken? -> pointless to discuss it, it ain't gonna happen. De developers (open source en free product) hebben een keuze gemaakt. Niet akkoord? -> don't use the product.

@jpgview , bedankt voor het sparren.

Nee ik heb geen interesse om een fork van PiHole te maken, wilde alleen duidelijk hebben dat er technisch betere oplossing beschikbaar zijn (dnscrypt-proxy, AdguardHome, named, dnsmasq (native), etc..) voor mensen die niet perse een webbased UI nodig hebben. Dat is dan ook zo'n beetje de (/mijn) conclusie...

Heb je een goed voorbeeld van zo'n script om de gravity lijst te verkorten? Heb een machine hiervoor draaien die wat meer vermogen heeft en toch uit z'n neus staat te eten.

Heb ze in een ver verleden getest, maar verwijderd, geen voorbeeld bij de hand Zou je trouwens weinig helpen, v5 final is niet veraf meer, geen van die scripts zal nog werken. Ik quote hier nog eens de verklaring van de developer waarom de extra entries in de gravity list helemaal geen probleem zijn:

I’ll only shortly explain why, you can ask if something remains unclear.
Gravity domains are now stored in a fully constructed B-tree. The lookup time in this tree model is O(log_2(N)). Without going too much into the technical details, let me just give some numbers:
1000 gravity domains = 10 tree lookups
10,000 domains = 14 tree lookups
100,000 domains = 17 tree lookups
1,000,000 domains = 20 tree lookups
10,000,000 domains = 24 tree lookups
100,000,000 domains = 27 tree lookups
The tree has efficient pointers to its branches so one lookup is also roughly one I/O activity. Given this, the performance impact on having a gravity list which is 1000x larger is almost negligible given the amount of overhead that is necessarily anyway present in the tree lookup process.

Dit geld uiteraard niet voor REGEX regels.

REGEX regels

Het vervolg van de statement van de developer als volgt:

quote
Now let’s go back to regex: Yes, regex is also quite performant in FTL. However, even a single regex is likely more expensive than having 100 times the number of domains in gravity. And since we’re not holding any gravity domain (but only the root of the tree) in memory, there is also not really a difference in memory usage here (in fact, Pi-hole v5.0 should use less memory for everyone!).
So with a few regex, it comes down to: It doesn’t really matter - or - doing with more gravity domains is still faster given the v5.0 reality and the tree.
However, on the contrary, I expect the gravity process to be massively delayed if each and every of your million+ domains needs to get passed through all these regex, I expect this to be really slow. I wouldn’t like to see our speed improvements we’ve just arrived at being killed by something I expect to have no notable effect at all during runtime.
/quote

TL;DR Overdrijf niet met regex regels, DNS resolving word er trager door (a single regex is likely more expensive than having 100 times the number of domains in gravity)

Precies dit. dnsmasq is een relatief trage tool voor dit soort blacklisting. Zeker in iets drukkere omgevingen kan je er tegen aanlopen. (Voor de meeste thuisnetwerken met maximaal 8 simultane gebruikers loopt dat in de praktijk wel los)
Ik gebruik zelf als tijden dnscrypt-proxy2 als adblocker geïnstalleerd op m'n Unifi router (dus geen getrut met een extra Pi enzo). Tegelijk heeft het out-of-the-box DoH en DoT voor m'n hele netwerk, waardoor DNS-spoofing aanzienlijk moeilijker wordt.

Het enige dat het niet heeft is een webinterface en dat KAN wel is handig zijn als je is een keer snel wat wil whitelisten ofzo, maar in de praktijk doe ik dat zelden.

Precies dit. dnsmasq is een relatief trage tool voor dit soort blacklisting. Zeker in iets drukkere omgevingen kan je er tegen aanlopen. (Voor de meeste thuisnetwerken met maximaal 8 simultane gebruikers loopt dat in de praktijk wel los)

Er zijn in het verleden op reddit artikels verschenen van gebruikers die pihole in een universiteits network en / of bedrijven hebben draaien. Ze doen dat waarschijnlijk niet op een raspberry pi, maar op een machine of VM met wat meer power. Het statement, maximaal 8 simultane gebruikers, is totaal uit de lucht gegrepen, het network verkeer, veroorzaakt door DNS request, is zo beperkt, dat alleen in heel extreme gevallen pihole een bottleneck zou kunnen zijn. Toegegeven, pihole is een 'poor man solution', er zijn andere oplossingen voor grotere omgevingen, ik betwijfel of dnscrypt-proxy de gekozen oplossing zal zijn, het is en blijft een 'one developer solution', je legt als bedrijf, je eieren niet in zo'n mand.

Met die 8 gebruikers doelde ik op "een gemiddeld thuisnetwerk". Niet dat dat het maximale aantal gebruikers is en dat het daarna instort.

Ik gaf alleen aan dat dnsmasq relatief traag is met het verwerken van statische DNS inschrijvingen en zoals Tomazo al aangaf is het werken met reguliere expressies al helemaal dramatisch. dnscrypt-proxy is hier 'sneller' mee (uiteraard ook niet de heilige graal voor grote omgevingen)

Uit nieuwsgierigheid. Hebben die universiteiten ergens beschreven hoe zij het gebruiken? Ging het daar om een afdeling van één faculteit, een hele faculteit of de hele uni? (zit nogal een verschil in ).

Ik werk zelf bij een internationale financiële organisatie en wij hebben best een aardig DNS-cluster nodig om de boel efficiënt draaiend te houden.

In versie 5 kan je ook met wildcards subdomains blokkeren.

pfSense heeft ook een ingebouwde Adblocking feature, maar het is maar net wat je het fijnst vindt werken...

Pi-Hole werkt gewoon heel fijn dankzij de ingebouwde WebGUI :
- Welke Client zit DNS Requests te spammen ?
- Welk adres wordt er verdacht vaak opgevraagd ?
- Alle DNS Request per Client of van alle Clients makkelijk opvragen met één click!
- enz...

Uiteraard kan je het meeste wel via de CLI doen, maar de WebGUI heeft echt een flinke meerwaarde en dat zeg ik niet gauw over een (Web)GUI

Of in een docker container op je NAS.

Nooit aan de praat gekregen op mijn Synology. Weet niet of het ligt aan mijn netwerk bond, maar draaien doet het niet dus toch maar een Pi ernaast. Welke guide heb jij gevolgd?

[Reactie gewijzigd door Raziel op 25 februari 2020 08:34]

Ik heb vorig jaar de onderstaande guide gebruikt. Deze werkte goed voor op de synology. Je synology moet natuurlijk wel docker ondersteunen. Ik geloof dat dit alleen zo is als je een Intel chip erin hebt zitten.
https://servicemax.com.au...y-in-docker-the-easy-way/

Die heb ik ook weleens geprobeerd. Het lijkt zo simpel ... Docker start, laatste regel is:
DNS resolution is currently unavailable

En na 120 seconden time-out stopt hij weer.

Docker-compose van @Bever werkt ook niet bij mij. Dat komt denk ik omdat ik de webserver al heb draaien op port 80.

Misschien de methode van @Waxyen eens proberen, maar dan moet ik load balancing uitzetten.

Dat kan kloppen, ik heb port 80 geport naar een andere (8080) in de docker-compose.yml

Ik gebruik geen Synology, maar gewoon Debian met de rest alles in Docker.

Ik weet dat het mogelijk is om meerder IP-addressen te hebben op je load-balancing/bond interface.

Ik heb mijn NAS een tweede IP adres gegeven en vervolgens Pi-hole op dat tweede IP adres laten draaien, de rest op het eerste IP adres.

Zo kan ik dubbele poorten gebruiken en draait Pi-hole zonder enige issues bij mij.

Laat maar weten of je interesse hebt, dan zoek ik mijn docker-compose op en deel ik die.

Yep, interesse hier
Ook hoe je je nas hebt ingesteld

[Reactie gewijzigd door Hulliee op 25 februari 2020 16:36]

@Hulliee Sorry voor de late reactie!

Ben je bekend met Docker? Ik weet niet of het kan, maar stuur me anders een persoonlijk bericht als je interesse hebt, dan kan ik meedenken met het opzetten van je NAS. Ik heb er ondertussen wel wat ervaring mee en misschien heb je wat aan mijn tips.

```
version: '3'
services:
pihole:
restart: always
container_name: pihole
image: pihole/pihole:latest
ports:
- "192.168.1.11:53:53/tcp"
- "192.168.1.11:53:53/udp"
- "192.168.1.11:67:67/udp"
- "192.168.1.11:80:80/tcp"
- "192.168.1.11:443:443/tcp"
environment:
TZ: 'Europe/Amsterdam'
volumes:
- './etc-pihole/:/etc/pihole/'
- './etc-dnsmasq.d/:/etc/dnsmasq.d/'
dns:
- 127.0.0.1
- 1.1.1.1
cap_add:
- NET_ADMIN
```

Dit is hoe mijn docker-compose.yml eruit ziet voor pihole. Het is belangrijk en vereist dat je voor elke andere container ook het IP adres erbij zet, anders draaien alle andere applicaties alsnog op meerdere IP-adressen, dat wil je nu juist voorkomen.

op dit moment heb ik de 5.0-amd64 beta draaien. het netwerk kies ik als 'host' network. via Environment zet ik een extra variabele WEB_PORT op 8090 en het ServerIP (vergeet de waarschuwing bij starten) op het lokale adres van je NAS (NAS=non-dhcp). thats it basically.

Dat was hem bijna voor mij! Ik moest alleen nog bij Interface listening behavior 'listen on all interfaces' aanvinken omdat ik een netwerk bond heb. Thanks!

Maar hoe update ik hem nu? Gisteren geinstalleerd en nu alweer verouderd. Pihole -up is geen optie in Docker (en heb er weinig ervaring mee).

edit: in ieder geval nog even etc/pihole gemapped naar een share op een NAS, voor het behoud van de instellingen bij een update.

[Reactie gewijzigd door Raziel op 26 februari 2020 12:44]

Ik heb deze docker-compose.yml gebruikt: https://github.com/pi-hol...ole/blob/master/README.md
Binnen 5 minuten aan de praat op mijn Synology NAS. Moet je wel via de terminal doen, niet via de webinterface van je NAS.

Heb 't hier gewoon in VMM draaien op een CentOS bak die nog wat andere zaken draait zoals Strongswan (IKEv2 VPN). Unbound erbij om het feest compleet te maken.

Welke PI kan ik het beste gebruiken voor een PI-hole? ZOnder dat ik teveel snelheid verlies.

Elke Pi is voldoende voor pihole, ik gebruik er een Pi Zero voor..

En door dat het maar een zero is, verlies ik geen snelheid??

In het beta5 traject zijn een aantal performance issues met een pi ZERO opgelost, blijkbaar (ik heb er zelf geen) tot volle tevredenheid van het beta 5 publiek, dat een ZERO gebruikt.
Zelf gebruik ik een 3B, het stroom verbruik (24/7 device) is nog steeds beperkt, een pi 4 zou volgens de tabellen wat meer verbruiken (dubbel zoveel - ).

Toch zou ik je aanraden, als de centjes het toelaten, niet voor een ZERO te gaan. Als ik een en ander goed gelezen heb (correct me if I'm wrong), heeft een ZERO alleen WIFI, en moet je, als je ethernet (wired) wil gebruiken, met een dongle werken. Ik zou persoonlijk nooit een critical device (DNS server) op WIFI laten werken, omdat je dan een extra point of failure introduceert in je network, nl. Het WIFI access point.

MAAR, het kan, v5 zal werken, en iedereen doet wat hij /zij wil!

[Reactie gewijzigd door jpgview op 25 februari 2020 11:55]

Ik heb geen Pi Zero W maar de non-WiFi variant met een ethernet adapter.
DNS requests vereisen niet zo veel cpu kracht dus een zero is meer dan voldoende, een “grote” Pi heeft wel als voordeel dat je geen ethernet adapter nodig hebt..

Maak zelf gebruik van een Ugreen Ethernet Adapter (die je ook voor een Chromecast kunt gebruiken), rond de 11 euro bij Ali. De (USB-)voeding komt vanuit mijn provider-modem en de ethernet verbinding is rock solid met de Pi-Hole 4-versies. Ben benieuwd of ik iets ga merken wanneer v5 live gaat.

Tenzij je miljoenmiljard dns requests per seconde doet. Maar voor gewoon normaal thuis tuin en keuken gebruik is een zero ruim voldoende.

De 2B en 3B zijn het gunstigst qua performance/verbruik ratio zeg maar volgens deze vergelijking : https://gathering.tweaker...message/54582789#54582789

De 3B+ en 4 worden een stuk warmer en zuipen ook meer stroom!

Ik heb hier een 2tal jaar probleemloos een pihole gebruikt, tot ik overschakelde naar Orange Tv (die uiteraard dan ook pihole als DNS gebruikt).
Sindsdien kan ik niet verder dan 2 dagen bladeren in de programmagids, en worden geplande opnames meer dan 2 dagen in de toekomst niet meer opgenomen.
Bij het nakijken van de netwerk instellingen krijg ik de melding dat er iets mis is met DNS...

Na de pihole tijdelijk uit het netwerk te halen werkt alles probleemloos, dus de combinatie pihole en Orange decoder werkt niet. Ik heb zelfs een herinstallatie van de pihole uitgevoerd, om zeker te zijn dat de standaard blocklists worden gebruikt maar helaas..

Iemand een idee hoe ik dit probleem kan oplossen? Rondstruinen op het net levert weinig tot geen antwoorden op, laat staan bij de supportdienst van Orange 😋

Bij het nakijken van de netwerk instellingen krijg ik de melding dat er iets mis is met DNS... .

geeft aan dat ze als test een of ander domain proberen op te lossen (de content ervan op te halen), lukt dat niet, dan zeggen ze dat er een DNS problem is. Microsoft gebruikt die techniek om achter de schermen het network icoon in de system tray te updaten, geen dns response -> geen internet verbinding, ook al is er slechts met dat ene domain een probleem.

In beta5 kan je een device met behulp van Group Management uitsluiten van bepaalde (of alle) regels / lijsten, de documentatie legt uit hoe, nieuwe groep, met daain de orange doos, waarschijnlijk opgelost.

Dan gebruikt men een bepaald DNS Record dat alleen bij Orange TV bekend is en dus in feite een Intern adres is!

Kan je oplossen door met meerdere VLAN's te werken en een extra Router, maar daar moet je maar net zin in hebben...

Toch blijf ik het jammer vinden dat die nog steeds YouTube advertenties door laat. Ik wou dat deze geblokkeerd werden.

Probeer dit eens:

In pi-hole versie 5 wordt dat nog makkelijker door support voor wildcards.

Bedoel je regex? zit er nu toch al in?

Er staat zelfs op het forum hoe je die bij dit specifieke voorbeeld kunt gebruiken : https://gathering.tweaker...message/58730500#58730500

(^r[[:digit:]]+(\.|\-+)[[:alnum:]]+\-+[[:alnum:]]+\.)(googlevideo|gvt1)\.com$
en
r[0-9]*([-]{1,3}|.)sn-[a-z0-9]{4,}\.googlevideo.com

[Reactie gewijzigd door Raven op 25 februari 2020 18:50]

Hé Raven, heb jij dit werkend op je pihole?
Bij mij starten de youtube filmpjes niet meer.

Ik gebruik Pi-hole (nog) niet, al draait het al wel ergens binnen mijn netwerk.
Geen idee of die regex goed werkt / uptodate is.

Die eerste regex zorgt er tevens voor dat downloads vanuit de Google Play Store niet meer werken. Kwam daar achter toen ik een app wilde installeren en deze maar op 'starting download' bleef staan en via 4G wel wilde.

Even de log bekeken en de 'gvt1' deel is de schuldige, dus ipv '(googlevideo|gvt1)' is het beter om gewoon 'googlevideo' aan te houden. Tenzij de hele regex zelf problemen geeft met Youtube oid. Dat heb ik nog niet getest verder.

Geweldig! dankjewel er is nog hoop!

jammer dat als je pi-hole op dezelfde pi draait als waar de vpn tunnel op actief is en je een Experiabox hebt die nog ingewikkelde dhcp moet doen voor de tv-decoders, sites als Amazon niet werken omdat je DNS via ander pad gaan dan http.

niet werken omdat je DNS via ander pad gaan dan http.

Klinkt alsof je een (static) route mist.

Klopt, op de experia kan ik geen extra/andere route toevoegen, behalve dan de dhcp geheel uitzetten waardoor onderwater ook de tv boxen geen ip meer krijgen op vlan3/4 . De default-gateway in de dhcp settings van de experia bepaald ook direct het ip van de experia zelf.
Als ik alles via de pi laat lopen werkt het wel. Dus zodra telfort echt kpn wordt gaat de analoge lijn eruit en de experia erachteraan en komt er een Mikrotik Hex-S voor in de plaats.

Is er al een manier om telefonie werkend te krijgen? Tv heb ik hier toch niet.
Ben er eens ingedoken, maar probleem was destijds de sip codes geloof ik. Enkel daarvoor zou de EB nog aangesloten moeten blijven, wat een waanzin.

Met een experia box v8 en Wireshark moet het mogelijk zijn om die gegevens te achterhalen omdat ze daar niet versleutelt zijn. (zelf geen ervaring mee)

Experiaboxen moeten ook gewoon structureel kapot. Die KPN-rotzooi ook. Niks dan ellende die troep... ook zakelijk echt alléén maar gezeik met die rommel.