Software-update: Pi-hole Core 5.7 / Web 5.9 / FTL 5.12

Pi-hole logo (75 pix) Versie 5.7 van Pi-hole Core is verschenen. Ook zijn Pi-hole Web 5.9 en FTL 5.12 uitgekomen. 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. De changelogs voor de drie afzonderlijke modules kunnen hieronder worden gevonden.

Pi-hole v5.7
  • Fix documentation; add some missing zones (#4417)
  • Recommend apt instead of apt-get if updating the package cache failed (#4421)
  • Allow users to skip setting static IP adress (#4419)
  • unit test for umask problems (#3177 and #2730 (#3191)
  • Update the tests (#4427)
  • Remove unused code from webpage.sh (#4420)
  • Use a fixed list height for network interface selection (#4434)
  • Clean up bash script formatting (#4085)
  • Fix generated /etc/os-release file in OS check test (#4443)
  • Some shellchecks in basic-install.sh (#4088)
  • Fix pihole -v output if WebAdmin not installed (#4370)
  • Fix number of invalid domains (#4445)
  • Use exec to run gravity script (#4449)
  • Gravity database handling improvements (#4478)
  • Add new interface listening option "bind" (#4476)
  • Companion to pi-hole/adminlte #1996 (#4461)
  • Add custom.list (Local DNS Records) to debug log (#4414)
  • Replace Contributing Guide by link to docs.pi-hole.net (#4433)
  • Unblock adlist domain during gravity run in NODATA mode (#4450)
  • Add comment help text to list function (#4455)
  • Check for updates on master based on tags not commits (#4475)
Pi-hole web v5.9
  • Fix date ranges in datarangepicker in long-term data (#1940)
  • Fix dashboard icon animations in Safari (#1939)
  • Set stateDuration to 0 for all saved datatables to store the state indefinitely (#1944)
  • Tweak to datatables column rendering (#1948)
  • Add missing blocked boolean in queries.js (#1950)
  • Add Star Trek LCARS theme (#1936)
  • Queryads single DIV and responsive CSS (fixed) (#1952)
  • Add missing rel="noopener" attributes (#1956)
  • Sidebar and nav-tab-custom: additional CSS for focus state (#1955)
  • Allowing data loading after selecting/deselecting options - Long-term data > Query Log (#1957)
  • fix: exclude status checkboxes from being treated as iCheck elements (#1910)
  • Long-term graph changes (#1969)
  • small typo in IP_ADDPRESS_OF_YOUR_PI_HOLE; two minor copy tweaks (#1972)
  • Add pretty-printing for message type DNSMASQ_WARN (#1973)
  • Fix the icon position (login password field) (#1974)
  • Revert "Remove duplicated code as it is already part of utils.stateLoadCallback" (#1975)
  • Improving the display of some graphics (#1976)
  • Remove traces of leftover API_PRIVACY_MODE (#1943)
  • Use theme gridColor and ticksColor in long time graph (#1977)
  • Swaping bar colors on "db_lists.js". (#1981)
  • Redo of Fixes background of the dark-midnight theme #1961 (#1966)
  • Fix PHP 8 incompatibility on settings page (#1970)
  • Fix DHCP tables button column (#1982)
  • Add note to message table how to generate debug log (#1962)
  • Remove obsolete code from network.php (#1979)
  • Add message types LOAD, SHMEM and DISK to Pi-hole diagnosis system (#1989)
  • Add bounce animation to Pi-hole diagnosis warning triangle (#1990)
  • Applying the same colors (CSS colors) used on the dashboard, for consistency. (#1992)
  • Number of domains on adlist is total number not valid number (#1995)
  • Select PHP version for phpstan (#2007)
  • Change default theme to auto light/dark theme (#2006)
  • Show ignored items when adding new adlists (#1997)
  • Improving code readability for lists (index.js and db_lists.js) (#1994)
  • Improve interface settings (#2011)
  • Add absent tags (#1991)
  • Avoid window.open and add more visible eye icon (#1996)
  • Add padding to apple fav icon and set background to black (#2003)
  • Reduce eye size (#2015)
  • Better output for "prettier" test (#2014)
  • Pi-hole web v5.9 (#2016)
Pi-hole FTL v5.12
  • Extend pihole -vv (#1229)
  • Print FTL version when calling the built in sqlite function only in interactive mode (#1226)
  • Compute reply time also for queries which failed upstream (#1234)
  • sync master -> development (#1236)
  • Tweak to determination of fastest upstream (#1235)
  • Analyze error report origins (#1237)
  • Improve virtual interface analysis (#1241)
  • Add dnsmasq warnings to message table (#1243)
  • Ensure dbclose () is not called multiple times (#1244)
  • Add support for conditional domain suffixes in HOSTNAMEFQDN mode (#1250)
  • Warn about resource shortages (#1249)
  • Update SQLite engine from 3.36.0 to 3.37.0 (#1251)
  • Test for dnsmasq warning messages in source code (#1246)
  • Do not catch SIGABRT (#1252)
  • Update embedded dnsmasq to v2.87test4-6 (#1230)

Versienummer 5.7 / 5.9 / 5.12
Releasestatus Final
Besturingssystemen Scripttaal
Website Pi-hole
Download https://github.com/pi-hole/pi-hole/releases/tag/v5.6
Licentietype GPL

Reacties (91)

91
90
60
0
0
2
Wijzig sortering
Als ik de systeemvereisten zo bekijk moet dit ook prima draaien op een originele Raspberry Pi B-model? Op PC stoor ik mij niet zo aan de reclames op websites (al zijn er uitzonderingen), maar op mobiel en iPad soms ook zijn sommige sites compleet onbedienbaar en dat allemaal door de reclames die in beeld schuiven en de boel doen verspringen, daarna weer dichtklappen etc.

Toch maar 's een SD kaart opzoeken en een van mijn Raspberry Pi's gaan inzetten.
Een PI-B zou best kunnen op een niet zo'n druk netwerk.
Kijk ook even naar de video van Craft Computing
Deze legt uit hoe je PIHole samen met Unbound DNS combineerd,
Link ook de github adblock lists van UBlock direct van de github pagina.

Best Practice:
- verwijs je routers WAN DNS naar het IP adres van je PIHole.
- Zorg dat de DHCP server PIHole als dns uitgeeft aan je clients.
- Op je firewall block all traffic over poort 53 (udp/tcp en als het kan HTTP(S) ) voor allle clients, met Unbound is je in/uitgaande poort 5335.

Maak een bash script welke je scripts update met pihole:
#/bin/sh
pihole -g

en voeg deze toe aan de scedule tasks, om deze eens per dag te laten draaien.

[Reactie gewijzigd door Bart_Smith op 24 juli 2024 00:06]

Wat voegt dat Unbound dan toe?
https://www.nlnetlabs.nl/projects/unbound/about/

Dit verteld je meer dan ik hier kan typen :)
Daar staat wat het doet, niet wat het toevoegt aan Pihole, dat was mijn vraag.
Heel simpel gezegd haalt Unbound zijn info van top-level DNS en skipt de subs, zoals jouw provider DNS, Google, Cloudfire etc.
Voor privacy dan? Gezien bij bijna iedereen DNS unencrypted is oftwewel zonder moeite door je ISP uit jouw traffic is uit te lezen schiet je daar weinig mee op, en vertraag je je eigen requests alleen maar. Ik deed (en doe) dit met Bind, maar met 1111 loopt het eigenlijk veel vlotter nu.

Zorg dat je deze up to date hebt iig: ftp://ftp.internic.net/domain/db.cache

[Reactie gewijzigd door pennywiser op 24 juli 2024 00:06]

Met unbound haal je die 1.1.1.1 er ook tussen uit.
Dat wil ik dus niet omdat rechtstreeks requesten vertragend werkt.
Dat was eerlijk gezegd ook wat ik dacht, maar ervaring was anders. Heb dan een dns-benchmark gedraaid en daaruit bleek dat unbound pakken sneller is 1.1.1.1 of gelijk welke andere dns.

En om even het privacy aspect te belichten: 1.1.1.1/cloudflare is een amper gereguleerde amerikaanse dienst. Ik bedoel daarmee dat je data/dns-queries in handen komen van iemand die vrij is ermee te doen wat hij wil. In europa behoud je dan beter de dns van je provider aangezien die, in europa, stukken beter gereguleerd is.

Ook stuurt unbound geen volledige query. Die stuurt voor tweakers eerst een query voor .net, dan naar de name-server van .net de vraag om tweakers te krijgen. Dat heet recursieve dns en lijkt mij beter voor privacy aangezien je geen 1 maar verschillende queries stuurt die je dan helemaal moet analyseren vooraleer je beetje werkbare data hebt.
Initieel zal dat wat trager zijn totdat Unbound zijn cache opgebouwd heeft. Dan zou het in theorie altijd sneller moeten zijn dan externe DNS servers als 1.1.1.1 of 8.8.8.8.
Pfoe, moet je altijd dezelfde sites blijven bezoeken thuis en daarbij zorgen dat de TTL niet verloopt anders kan je weer opnieuw beginnen. Dat wordt elke dag f5en :)
Ik heb Adguard Home nu een dag draaien, en die heeft nu het volgende: Average processing time
31 ms. Daar zitten de langere responses bij voor niet eerder bezochte sites, maar ook de response vanuit de cache. Vanuit de cache zit de response tijd op gemiddeld 0,5 ms.
Nice. Welke hardware gebruik je? Meet je dit op localhost of op een client?

Nogmaals, ik denk dat voor privacy weinig zin heeft om rechtstreeks op dns rootservers te requesten, daar moet je aanvullende maatregelen voor nemen. Dus gebruik ik 1.1.1.1 welke de caching logistiek overneemt en ook een level van privacy biedt.
Adguardhome heeft een nieuwe functie (lazy) optimistic DNS cache.
Deze geeft toch de verlopen resultaat, waarbij hij direct een nieuwe querie doet. Is het toch niet juist, dan is het nieuwe resultaat er toch al snel.

Samen met unbound werkte dit vrij veilloos.
Gevaarlijke oplossing. Daarmee kan je dus theoretisch op een verkeerd IP terecht komen. Soort van DNS hijacking. Wordt er inhoudelijk gecheckt of de getoonde website klopt? Of is zodra er ook maar een site wordt getoond op het oude ip het request afgehandeld? Maw, wat is niet juist.

Kwestie van tijd dat dit mechanisme misbruikt gaat worden.
Dit is exact hetzelfde als de optie 'serve-expired' die al jaren in Unbound zit...
unbound heeft dit al veel langer. het noemt cache DB modules, maakt gebruik van een redis database. Zie ook de discussie van oktober 2019, hier.
Ik heb het ook met Unbound ingesteld en je merkt er in de praktijk helemaal niets van dat het trager is.
Maar waarom heb je het dan zo ingesteld?
Wat bedoel je met dit laatste?
- Op je firewall block all traffic over poort 53 (udp/tcp en als het kan HTTP(S) ) voor allle clients, met Unbound is je in/uitgaande poort 5335.

Persoonlijk heb ik pfsense draaien, alles naar 53 wordt redirect naar mijn lokale DNS server binnen pfsense. Alles wat extern een aanvraag doet wordt geblokkeerd. Maar http(s) kunnen we nooit blokkeren, want anders kun je geen websites meer bezoeken...
Er kunnen apparaten in je netwerk, die hun eigen dns gegevens gebruiken om bv. pihole te skippen en reclame te kunnen laten zien.
Ik heb eens een stuk gelezen over smart TV's die dat doen.

Http is inderdaad moeilijker zonder dat je packet inspection toevoegd, wat te zwaar is voor een PI.
Vergeet poort 853 dan niet ;-).
Ik heb 15 clients en werk van thuis, die worden perfect en met minimale belasting bediend door een Pi Zero (Pi-Hole én Unbound), waarom zou je zwaarder nodig hebben voor huis-, tuin- en keukennetwerken?

Unbound is inderdaad een waardevolle aanvuling.

Ik zie wel niet in waarom je dagelijks zou moeten gravity update draaien?
Pi-Hole doet dat zelf al wekelijks, lijkt me frequent genoeg...
Ben ruim een halfjaar geleden overgestapt op AdGuard, een Pi-hole alternatief, en is een stuk beter in gebruik, en wordt ook veel actiever ontwikkeld, werkt prima standalone toen ik het uit teste op een R-Pi3, en draaid nu als een Add-On in Home Assistant, en HA heeft Pi-Hole zelfs geheel laten valen voor het betere AdGuard.
Home Assistant Community Add-on: AdGuard Home

downloads: AdGuard Home 0.107.0 - 2 dagen geleden gepost in ''Software-Update''

AdGuard Home vs. Pi-hole (2020) – Two ad and internet tracker blockers compared
Which is better? AdGuard Home or Pi-hole?
Ever since spinning up my first AdGuard Home container, I’ve been convinced that it is the better application. It didn’t take long for me to reach the decision to switch from Pi-hole. While comparing the Pi-hole and AdGuard Home for this article, it became all the more obvious that AdGuard Home is better in every way.

[Reactie gewijzigd door player-x op 24 juli 2024 00:06]

't Is maar hoe je beter definieert...
Ik denk niet dat er een absolute waarheid is in termen van welke beter is, het gaat eerder over voorkeur.
Adguard heeft een uitgebreidere UI en wat meer zaken 'out of the box', Pi-Hole is zeer tweakable en heeft een actieve community met de devs.
Ik zal het zo zeggen Home Assitant dev's zijn best wel een stel geeks, en die hebben Pi-Hole vast niet, niet voor niets laten vallen voor Adguard, en ik moet zeggen vanuit hoe ik het zie was het ook geen slechte keuze.
3x zeg je of citeer je dat het beter is, en niet 1x wordt dat ergens onderbouwd.
Dat Adguard actiever ontwikkeld wordt is vrij twijfelachtig. Ik vraag me af waar je dat op baseert?
En die vergelijking? Ja, er zitten wel degelijk terechte opmerkingen in, maar het hele stuk is toch wel erg geschreven om Adguard er zo goed mogelijk uit te laten komen. Sommige dingen zijn echt gezocht of gewoon niet waar:
"HTTPS can be configured for the Admin interface." => kan al sinds 2017
"Access settings can be adjusted." => kan ook op Pihole

De schrijver heeft een duidelijke voorkeur voor Adguard, en dat is prima. Mensen moeten de programma’s gebruiken die hen het beste bevallen. Maar "objectieve" vergelijkingen" schrijven die puur bedoeld zijn om het programma van voorkeur aan te prijzen vind ik wel een beetje jammer.
Prima dat het jou beter bevalt. Fijn voor je!

Dat devs kiezen voor x of voor y wil niks zeggen. Als je kijkt naar professionele firewalls zie je het ene top-10 bedrijf kiezen voor merk X, de ander voor merk Y. Is daarmee de een absoluut beter dan de ander of past X gewoon beter bij het ene bedrijf en Y beter bij het andere?
Je kunt heel mooi zien of je Unbound goed ingesteld staat als jouw eigen IP-adres als DNS server naar boven komt op de volgende pagina: https://ipleak.net/
ik heb mijn Pi-Hole nu een tijdje draaien op mijn Pi B en dit draait prima. De bedoeling was het om het te gaan draaien na een tijdje naast Home Assistant op de Pi 4 8GB, maar eigenlijk bevalt het draaien van Pi-Hole op de oude Pi prima zodat ik dit zo laat.
Heb hem ook draaien op een oude Pi B model, geen enkel probleem, voelt snappy en de load blijft zeer laag.
Ik heb pi hole jaren gedraaid op een rpi zero. Geen enkel probleem. Toevallig 2 weken terug ingeruild voor een zero 2 zodat het updaten en herstarten wat sneller gaat. Maar het draait heel ligt.
Ik draai Pi-hole al jaren op een Pi-Zero met een LAN adapter en dat werkt meer dan prima!

Nou heeft die wel een 1Ghz CPU tov de 700Mhz van de originele Pi maar zou denk wel moeten werken.
Pihole draait prima op een Raspberry Pi B-model. Ik heb het thuis (vanwege redundancy) draaien op twee raspberry's - een model 4 en een redelijk oude, een Raspberry Pi 2 Model B Rev 1.1.

Geheugengebruik volgens Pihole zelf is 19%, CPU load nagenoeg niks.

Ik zou het gewoon doen als ik jou was :)
Draai hier pihole + dhcp op een pi zero wireless met ethernet dongle. Nu wordt er niet super veel geblokkeerd maar hij doet het zonder moeite.
DNS queries stellen echt heel weinig voor, een Pi Zero zou ook prima kunnen voldoen. Alleen heeft ethernet natuurlijk wel de voorkeur boven WiFi.

Wel altijd even een paar dagen wachten als er een nieuwe versie uitkomt van PiHole; heel erg vaak zijn er met nieuwe versies in eerste instantie flink wat problemen!

[Reactie gewijzigd door zordaz op 24 juli 2024 00:06]

Draait hier probleemloos zonder merkbare latency op een eerste generatie pi zero met wifi.
Ik zou dan eerder richting AdGuardHome denken, als het simpele Ad blocking is met blocklists. Ik hoop dat het beter is, maar ik heb PiHole toch altijd als redelijk log en zwaar ervaren. Het was beter als het in een container draaide. Iets gemakkelijker om al de packages te isoleren van de host. Maar weer iets zwaarder.

Edit: de link, voor wie het niet kent:
https://github.com/AdguardTeam/AdGuardHome

[Reactie gewijzigd door G0ddy op 24 juli 2024 00:06]

Hoe bedoel je zwaar en log?
Ik had Pi-Hole op 2 Raspberry Pi Zero's draaien (barebone, zie niet in waarom het in docker zou moeten als je niks anders hebt draaien) en die hadden nog meer dan genoeg capaciteit over, werkte erg vlot.
Gelieve zo'n statements kracht bij te zetten met facts and figures...
Graag, maar facts en figures heb ik niet, die zijn ook niet nodig als ik mijn mening zo zwak formuleer ("log ervaren", puur subjectief).
Ik heb er niets bij gezet omdat het zo lang geleden is dat ik ben overgeschakeld.

Een poging ter verduidelijking van mijn aanvoelen (en nu duik ik ver in mijn geheugen):
Ik heb enkele keren het probleem gehad dat de pihole niet deftig kon geüpdatet worden. Soms werden bepaalde componenten wel geüpdatet, andere niet. En dan werkte het niet meer. Toen ik het uiteindelijk beu was, ben ik gaan kijken naar Docker, omdat het onderliggende probleem de prereq packages waren die pihole nodig had. Isoleren die boel dus, dan hoefde ik alleen maar de Docker image versie te verhogen en klaar. Maar Docker en de rpi, dat verliep ook niet altijd vlot. Dus uiteindelijk overgestapt naar AdGuard. Nooit problemen gehad met updaten of losse componenten of dependency conflicten.
Dus het logge verwijst eerder naar het software pakket dan naar de prestaties. Met de prestaties heb ik denk ik nooit problemen gehad.

Zoals gezegd kan dit wel al gewijzigd zijn intussen, ik wil gerust nog eens piepen ;) Hoe dan ook heb ik liever container like software dan appliances die het hele systeem kapen. Opnieuw, subjectief.

Ik weet niet of dit je honger stilt, want het blijft een ervaring.

[Reactie gewijzigd door G0ddy op 24 juli 2024 00:06]

Zoals @Church of Noise al aangeeft, hoe is Pihole zwaar/log? Heb hier een pihole zero draaien en zelfs als ik er een DNS tester tegenaan gooi dan is de load nog steeds erg laag. We hebben het hier over DNS resolving he niet een of andere ingewikkelde website die moet worden geparsed en served.
Ik zie dat Pi-hole ook een Docker image heeft. Jammer dat ik nu net een NAS heb die geen Docker kan draaien :-(. Maar ik zal AdGuardHome ook 's bekijken.

[Reactie gewijzigd door Htbaa op 24 juli 2024 00:06]

Ik vind die 2.4% blocked uit het screenshot nogal optimistisch. Mijn block-percentage ligt doorgaans ruimschoots boven de 20% (momenteel 23.4%), met 275.000+ domeinen in de blocklist. Wat ik overigens best schokkend vind, maar dat terzijde.
Hij draait hier op een Pi 3 B+ moeiteloos. Al jaren. Binnenkort is de SD-kaart aan vervanging toe en moet ie even down, helaas.
Bor Coördinator Frontpage Admins / FP Powermod @Bas_f23 december 2021 09:52
20% vind ik echt vrij fors moet ik zeggen. Ik zit op dit moment op 4.7% met meer dan 111.000 domeinen op de blocklist. Het hangt er denk ik ook wel behoorlijk vanaf wat je op het internet doet, welke websites je bezoekt etc.
Ik haal makkelijk 35%. Vooral de Hue Bridge en ShieldTV staan erg hoog. Kennelijk kunnen ze er niet goed tegen dat ze geblokt worden op bepaalde domeinen. 35 Devices in m'n netwerk.
Bor Coördinator Frontpage Admins / FP Powermod @Hulliee23 december 2021 11:58
Kijk je dan ook waarom deze devices zo hoog staan en waar ze naar toe willen? Diverse devices blijven het gewoon continu proberen wat een hoog percentage als dit kan verklaren.
Zeker, ik weet precies waar ze naar toe willen. En dat wil ik niet ;-) Dus ja dan gaan ze maar uit hun dak helaas.
fors? Dat is toch helemaal afhankelijk van
  • Hoeveel devices er gebruik van maken
  • Welke applicaties er per device worden gebruikt
  • Hoeveel domeinen je op de blocklist hebt staan?
Hier, klein netwerk met 13 devices, zit ik op ~ 30% met 3,2 miljoen domeinen op de blocklist. Het aantal domeinen op je blocklist zegt overigens helemaal niks over die 30%.
Bor Coördinator Frontpage Admins / FP Powermod @Webgnome23 december 2021 10:53
Waarom zou het aantal domeinen op de blocklist niets zeggen? Hoe meer domeinen je opneemt hoe groter de kans dat een bezocht domein op de lijst staat. Je voegt niet voor niets extra domeinen toe. Het aantal devices lijkt mij op zich weer weinig uit te maken. Het gebruik hiervan des te meer.

[Reactie gewijzigd door Bor op 24 juli 2024 00:06]

De meeste geblokkeerde requests komen van onze Android telefoons; ook wanneer deze "uit" staan.
Ja, en of je in je browser nog een adblocker gebruikt of niet. Die heb ik sowieso ook aan voor alle elementen die ik ook wil blokkeren (zoals ads op Youtube).
De osid lijkt eens proberen staan 270.000 vermeldingen in en is een verzameling van alle andere lijsten. Alleen ip adressen die functionaliteit breken worden er uit gelaten.
Ik had eens 79% omdat ik een tijdje een Samsung Smart TV in gebruik had.
Toen die terug plaats maakte voor een nieuwe Sony OLED daalde het meteen naar 15-20% blocked.

Alles hangt af van type devices + surfgedrag.
Zijn je blocklists enkel voor ads heb je ook al minder dan dat je ook telemetry zou blocken.
Voor wie het installeren, configureren en bijhouden van Pi-Hole een issue is, kan ik NextDNS.io aanraden. Gratis tot 300k DNS queries per maand.

Werkt ook prima op telefoons en tablets, geen in-app reclamemeuk meer en alle websites keurig zonder opdringerige advertenties. Enige wat je moet configureren is je DNS server op je device of modem en klaar ben je.

Op een gegeven moment werd mijn huis bijna een datacenter, daarom gekozen voor NextDNS.
Hoe moeilijk is het installeren / configuren van pihole precies? Als je het met de standaard blocklist doet ben je toch binnen no-time klaar? En het enige lastige wat er dan nog te doen is, is je dns configureren maar he dat moet je bij NextDNS dus ook. Een van de redenen om een pihole te draaien is toch juist dat je niet afhankelijk bent van wat andere DNS services je te bieden hebben? Ligt er een dns uit dan heb jij daar geen last van.
Een van de redenen om een pihole te draaien is toch juist dat je niet afhankelijk bent van wat andere DNS services je te bieden hebben? Ligt er een dns uit dan heb jij daar geen last van.
Met PiHole ben je nog steeds afhankelijk van externe DNS servers, waar denk je dat PiHole de DNS-gegevens vandaan haalt? Mijn PiHole gebruikt als upstream momenteel OpenDNS, als OpenDNS eruit ligt dan kan PiHole nergens DNS-gegevens vandaan halen en hooguit terugvallen op wat er in de PiHole cache staat.

Tenzij je dus een eigen DNS gaat draaien zoals Unbound. Net een beetje zitten inlezen en ik denk dat ik dat ook maar eens ga proberen. Draai hier toch een Raspberry Pi 4 met een SSDtje als opslag, moet prima kunnen. :P

[Reactie gewijzigd door Wildfire op 24 juli 2024 00:06]

waar denk je dat PiHole de DNS-gegevens vandaan haalt?
Bij de bron :)
Upstream > pfsense > unbound
Of direct unbound op de pihole zelf.

[Reactie gewijzigd door toxicunderGroov op 24 juli 2024 00:06]

Ja, maar ik bedoelde in het geval dat je niet zelf een DNS draait. Dan komt het dus bij een externe DNS vandaan, buiten wat in de cache zit dan.
[...]

Tenzij je dus een eigen DNS gaat draaien zoals Unbound. Net een beetje zitten inlezen en ik denk dat ik dat ook maar eens ga proberen. Draai hier toch een Raspberry Pi 4 met een SSDtje als opslag, moet prima kunnen. :P
Nou dit, dus. Heb twee pi holes met unbound geconfigureerd.

[Reactie gewijzigd door Webgnome op 24 juli 2024 00:06]

Klopt, heb je ook helemaal gelijk in. Ik heb de kennis in huis om het uit te voeren, Pi-Hole samen met unbound en een VPN voor mijn mobiele devices. Daarbij had ik ook allerlei apparatuur van Ubiquity met firewall regels om DNS verkeer te verplichten over de Pi-Hole (zodoende de Google Home's te forceren niet over 8.8.x.x te laten gaan). Werkt prima tot Pi of Ubi weer een update had, zat je weer hele avonden te puzzelen om het werkend te krijgen, VLAN's in te stellen voor management, prive, IoT en gasten. Daar was ik helemaal klaar mee. Alles de deur uit, NextDNS, 3 minuten later: ... totale rust en alles werkt gewoon. Geen gezeur meer. Draai het nu ongeveer 1,5 jaar.

Met NextDNS (of andere Pi-as-a-service diensten) kies je voor gemak. Dat is alles wat ik wilde aanstippen. Blijft bijzonder dat dit ongewenst of off-topic gedownmod wordt overigens.
Het is juist De moeite, het bijhouden, apparatuur en energieverbruik en tijd die iemand er in moet steken, hoe leuk en goed PiHole ook is.
Dat slaan wij met nextdns over, en als grote voordeel werkt het overal waar ik met mijn devices naar toe ga. De meeste handgebruikte devices doen doh direct naar nextdns, zijn als je wilt apart te herkennen en te configureren.
Een belangrijke afweging om zelf pihole + unbound te draaien is dat mijn DNS queries prive blijven. NextDNS is een mooie service, maar je geeft een gedeelte van je privacy op om er gebruik van te kunnen maken.

Bert Hubert (oa. de bouwer van PowerDNS) heeft hier vorig jaar op Tweakers een goede talk over gegeven. https://www.youtube.com/watch?v=ZWabMpBGgUU
Hangt van de externe dns provider af, die houden ook logs bij van wie wat opvraagd.
Als je zoals @Muncher suggereert Unbound gebruikt naast PiHole dan is dat dus je "externe" DNS provider, die dan intern in je netwerk draait. Deze gaat DNS queries zelf nalopen vanaf de DNS root servers. Deze servers loggen niets of in ieder geval minimaal.

[Reactie gewijzigd door rbr320 op 24 juli 2024 00:06]

Je hebt wel gedeeltelijk gelijk hoor, je zult altijd een derde partij (met minimale regelmaat) moeten vragen om informatie (al waren het maar de root DNS servers). Echter, Pihole icm Unbound staat je toe om technieken als qname minimization toe te passen, waarbij de je DNS query als het ware in kleine stukjes word opgeknipt en verstuurd naar verschillende servers. Niet 100% waterdicht, maar wel meer prive dan zonder.

Hier kan je meer info vinden:

https://www.isc.org/blogs/qname-minimization-and-privacy/
300k DNS? Daar heb ik niets aan, ik haal 60k per dag.
En ik houd dit soort zaken liever in m'n eigen netwerk ipv er buiten (privacy)
Ik heb even gekeken en ik had gisteren 52k DNS queries. Zodra je een paar apparaten in je netwerk hebt hangen gaat het hard met de DNS queries.

Zelfs mijn ouders, die zeker geen powerusers zijn, zaten gisteren al op 12k queries.

NextDNS zal dan, als ik het zo zie, voor veel mensen dus betaald gaan zijn. :P
Je moet wel naar het aantal uitgaande queries kijken, en niet naar degene die door de lokale cache worden opgevangen. Dat doet nextdns ook niet.

Met een stuk of vijftien apparaten zijn het hier 30.000 stuks per dag die door nextdns worden afgehandeld. Ongeveer 15-20% wordt geblokkeerd.
Cached eruit gehaald, dan zit ik op ruim 29k queries. Na 10 dagen de limiet van NextDNS bereikt dus :P
Dat klopt, daarom hier ook een abbo ;)
Ik ben alleen thuis, het is nog maar middag en ik heb vooral huishoudelijke taken gedaan, en toch zit ik nu al op 10.500 queries. 300.000 lijkt veel, maar is dus duidelijk enkel een proevertje.
Ik gebruik dit al jaren. De laatste tijd i.c.m.wireguard VPN, zodat je heel erg gemakkelijk de pihole bescherming aan en uit kunt zetten op je mobiele telefoon. Overigens gebruik ik een raspberry pi 3b+. Het kan ook op een 1b trouwens...

Edit: bedoel inderdaad Wireguard VPN

[Reactie gewijzigd door kabelbreuk op 24 juli 2024 00:06]

Bedoel je wireguard vpn? Ik heb hetzelfde gedaan, voorheen openvpn. In beide gevallen prima te combineren op een enkele pi. Ben erg blij met het resultaat op mijn telefoon!
Ik draai het op 2 prehistorische Banana Pro's met dual core A20 processor op 1 GHz: die hebben er geen enkele moeite mee en ik heb zo'n 3 miljoen domeinen in de blocklists staan. Ze hebben wel een echte GB NIC overigens. Maar ik denk niet dat dat de flessenhals is voor Pi-Hole op een oude RPi.
Het gaat denk ik niet zozeer over hoeveel domeinen je in de blocklist hebt staan maar over hoeveel requests je pi's te behandelen krijgen.
Bor Coördinator Frontpage Admins / FP Powermod @Webgnome23 december 2021 11:26
Aan de andere kant; voor elke request moet de hele blocklist gequeried worden. Zowel het aantal requests als het aantal domeinen hebben invloed.
Ja, het is een combinatie van. Maar in een gemiddeld thuisnetwerk draait een pi zero rondjes terwijl hij dns requests aan het doen is.
Eens, excuus. Mijn situatie is een typische gezinssituatie en dan heeft een Banana Pro nog veel reserves, gezien lage cpu belasting.
Al jaren tevreden gebruiker hier, draait op een orangepi one H3 met dietpi. De orangepi draait naast pihole ook tautulli, nextcloud en een sambaserver. Werkt prima!
Orange Pi Zero Plus hier :)
Ik kan niet meer zonder mijn Pi-Hole, vriendin daar tegen moet soms beter zoeken op internet, anders krijgt ze te zien dat de pagina niet geladen kan worden O-)
Om dat te voorkomen heb ik diverse advertentiesites ge-whitelist.Hierdoor zijn de advertenties in Google weer klikbaar
Of een extensie draaien die ads uit de zoekresultaten filtert en omzet naar de echte URL in plaats van de referral
Heb dit een tijdje gedraaid naast de unify controller maar om 1 of andere reden werkt dat niet lekker samen en klapt hij er constant uit en moet ik de controller weer opnieuw installeren. Nu de controller alleen draait en ik Cloudflare gebruik ipv de pi-hole geen problemen meer.
Ik draai de Unifi controller en pi-hole naast elkaar en dat werkt gewoon naast elkaar. Heb niet echt een volgorde aangehouden qua wat er eerst geïnstalleerd moest worden. Maar eerst de pi-hole en daarna unifi controller zou je probleem moeten doen verdwijnen.
Ja ik heb elke volgorde (2) al geprobeerd. Welk OS draai jij op je pi en is dat een core of met gui?
Raspberry pi os core of hoe dat tegenwoordig ook heet. Niks spannends. En ik gebruik het script wat hier te vinden is: https://community.ui.com/...82ec-22b17f027776?page=89

[Reactie gewijzigd door peppi_078 op 24 juli 2024 00:06]

zelfde hier, Pi-Hole and Unifi controller op dezelfde server draaien, al draai ik het zelf vanuit een Ubuntu 20.04 omgeving.

Op dit item kan niet meer gereageerd worden.