Software-update: Pi-hole Core 5.14.1 / Web 5.17 / FTL 5.19.1

Versie 5.14 van Pi-hole Core is uitgekomen. Ook zijn Pi-hole Web 5.17 en Pi-hole FTL 5.19 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 releasenotes voor deze uitgave kunnen hieronder worden gevonden.

Highlights

We update the embedded dnsmasq to the next tagged version of dnsmasq. Highlights compared to the most recent version of dnsmasq (v2.87) released in FTL v5.18 are:

• Allow domain names as well is IP addresses in server options – this will be especially helpful in situations where upstream destinations are primarily reachable by hostname (think of DHCP networks and docker compose, etc.) (Pi-hole patch)
• use-stale-cache – when set, if a DNS name exists in the cache, but its time-to-live has expired, dnsmasq will return the data anyway and attempts itself to refresh the data with an upstream query after returning the stale data. This can improve speed as we can always reply immediately to known queries, even when cached content has expired, instead of having to wait for upstream replies to arrive. However, in certain edge-cases, these out-of-data replies can lead to (intermittent) incorrect behavior on websites as there is no way to inform a downstream client that an answer we provided before was wrong. The client may cache wrong data for a long time until it re-sends a query to get the updated information.
  It comes at the expense of sometimes returning out-of-date replies and less efficient cache utilization, since old data cannot be flushed when its TTL expires. The cache becomes strictly least-recently-used.
• New fast-dns-retry option – gives dnsmasq the ability to originate retries for upstream DNS queries itself, rather than relying on the downstream client. This is most useful when doing DNSSEC over unreliable upstream network. Retries are generated when no reply was received for 1 second. Retries are repeated with exponential backoff until we give up after 10 seconds. Both values are configurable with millisecond accuracy.
• New port-limit=<#ports> option – by default, when sending a query via random ports to multiple upstream servers or retrying a query dnsmasq will use a single random port for all the tries/retries.
• New no-round-robin option – suppresses round-robin ordering of DNS records and ensures answers are always served in the same order.
• Enhance hostsdir to remove outdated entries on changes. Before, this required a full dnsmasq restart (Pi-hole patch)
• Improve hostsdir logging to log the HOSTS file used for generating a local reply (Pi-hole patch)

This release also includes a number of smaller improvements and bug fixes in all components.

Versienummer	5.14.1 / Web 5.17 / FTL 5.19.1
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Pi-hole
Download	https://github.com/pi-hole/pi-hole/releases/tag/v5.14
Licentietype	GPL

Reacties (35)

[mediumdry]

Jammer dat dit soort initiatieven niet met een DNS server komen, maar met een forwarder als dnsmasq. Het is best zoeken naar een aantal van de blocklists die pihole en adguard gebruiken in RPZ formaat, dat door de meeste DNS servers gebruikt kan worden.

Ik snap de doelgroep ook niet... mensen die wel meer privacy willen, maar het niet erg vinden de DNS dan door te sturen naar google/cloudflare/ISP. Of misschien mensen die alleen een paar advertenties niet willen zien, maar privacy niet van belang vinden?

[sircampalot]

"mensen die alleen een paar advertenties niet willen zien, maar privacy niet van belang vinden"

Die mensen zijn er inderdaad. En door het gescheiden aan te bieden heeft iedereen een keuze.
Op de PiHole site wordt uitgelegd hoe een eigen dns resolver (unbound) erbij geinstalleerd wordt.

[lenwar]

mensen die wel meer privacy willen, maar het niet erg vinden de DNS dan door te sturen naar google/cloudflare/ISP.

Met privacy op het internet kies je in principe je duivel. Uiteindelijk moet je altijd iemand vertrouwen met jouw data. Gebruik je een Android toestel, een Chromecast, Gmail, enz, enz, dan vertrouw je waarschijnlijk Google eigenlijk al impliciet, dus dan kan je prima de Google upstream servers gebruiken (met een DoH proxy ertussen).

Als je bijvoorbeeld lokaal een recursive nameserver gebruikt als unbound of bind om tegen de DNS-root-servers aan te praten, vertrouw je impliciet je ISP, de organisaties die die root-servers beheren en alle DNS-servers waar je tegen praat.

Ik denk dat je uiteindelijk het meeste privacy hebt als je gebruik maakt van ODoH. Dan ziet niemand wat jij opzoekt. De één ziet dat jij 'iets' opzoekt, en de ander ziet dat 'iemand' iets specifieks zoekt.

[Mijzelf]

Jammer dat dit soort initiatieven niet met een DNS server komen, maar met een forwarder als dnsmasq.

Wat is het verschil tussen een DNS server en een DNS forwarder, en waarom zou dat beter zijn voor de privacy?

[Church of Noise]

In principe forward Pi-Hole je DNS requests nadat ze 'gefilterd' zijn naar de DNS server die je instelde, bvb Google, Cloudflare, Quad9, de DNS server van je eigen ISP, ...

Zoals @jpgview hoger aangaf, kan je ook naast Pi-Hole een DNS server draaien zoals Unbound. In plaats van je DNS queries na Pi-Hole naar een '3rd party' door te spelen, ga je ze zelf 'resolven' met behulp van de 'authoritative servers', zeg maar de 'oer DNS servers' waar uiteindelijk de Googles etc ook gebruik van maken. Je slaat m.a.w. een tussenstap over als je dat zelf doet.

En om nog een aantal andere gebruikers bij te treden (niet meer gerelateerd aan de vraag van @Mijzelf ): ik ben al jaren een tevreden Pi-Hole en Unbound gebruiker, en apprecieer de 'tweakability' van beiden, en het feit dat de development teams van beiden erg bereikbaar zijn.
De hele resem getuigen van 'Adguard home is beter' vind ik ook niet bepaald nodig telkens als Pi-Hole ergens wordt vernoemd. Ten eerste omdat dat omgekeerd m.i. niet gebeurt, omdat het niks bijdraagt en omdat de argumenten in sommige gevallen onjuist zijn. Ik heb zelf m'n huiswerk gedaan en zonder een IT achtergrond is het erg makkelijk om beiden op te zetten, met de functionaliteit die ik wil. Heeft iemand daar een andere opinie over? Fijn, en mag best, maar om die bij elke gelegenheid door te strot te willen duwen is écht niet nodig.

[jpgview]

gebruik zelf ook RPZ files, maar het is moeilijker om een domain te whitelisten. Als de SOA info (in de RPZ) aangeeft dat er regelmatig geupdate word, zal je wijziging ongedaan gemaakt worden.

Ook jammer dat, als er een fout in de rpz file staat, de hele zone niet meer werkt, recent meegemaakt met de urlhaus rpz file.

Je moet dan op een of andere manier een 'rpz-passthru.' aanmaken, kan niet in diezelfde file, want die word opnieuw gedownload van source.

Nog niet geprobeerd of dit ook kan in een aparte, self-maintained, file (whitelist.rpz)...

voor wie geintereseerd zou zijn, doc (voor unbound) hier.

[chocopasta]

Jammer dat DNS over HTTPs van Firefox en Google Chrome Browsers zorgt dat de DNS server in het netwerk standaard wordt genegeerd. Hierdoor zal je eerst DNS over HTTPs op alle apparaten uit moeten schakelen voordat je echt goed gebruik van Pi-hole kunt maken.

[The Third Man]

Je kan met cloudflared ook HTTPS support aan de pihole toevoegen https://docs.pi-hole.net/guides/dns/cloudflared/

[lenwar]

Dat gaat niks voor hem oplossen.
De browser stuurt z'n verzoeken versleuteld naar een DoH server ipv de Pi-Hole.

Als je graag DoH wilt praten aan de achterkant van je DNS-sinkhole kan overigens denk ik beter AdGuard Home gebruiken. Die heeft dit native ingebakken zitten. (scheelt weer nog een stukje software wat je moet installeren)

[The Third Man]

Ik bedoel daarbij natuurlijk wel dat je dan ook in de browser het DoH endpoint op de Pi-hole instelt...

[lenwar]

Maar dan passeer je dus alsnog je DNS sinkhole met je browser.

cloudflared is een DoH-proxy. Die vertaald DNS naar DoH. Niks meer of minder dan dat.

dnsmasq (en dus Pi-Hole FTL) ondersteund geen DoH. Op geen enkele manier.
Wat je dan dus hebt, is dat je dnsmasq instance DNS praat tegen de cloudflared instance, die vervolgens DoH praat naar (bijvoorbeeld) Cloudflare.

Je hebt dan dus een extra stuk software in gebruik waarmee onversleutelde communicatie plaatsvindt (ook al is het naar localhost. Het is onversleuteld). AdGuard Home ondersteund wèl native DoH aan zowel de binnenkant (de 'browserkant') als de buitenkant ('richting het internet'). Ofwel: De browser praat DoH naar m'n AGH instance, die vervolgens met DoH richting Cloudflare praat.

Dit betekend dus dat de hele keten versleuteld is. Zelfs op de apparaten waar de AGH-installaties op draaien, kan een extern proces dus niets voorbij zien komen (anders dan versleutelde prut). Dit in tegenstelling tot Pi-Hole, die alle DNS-verzoeken onversleuteld ontvangt en onversleuteld doorstuurt naar iets anders (ook al is het lokaal naar een cloudflared-proces). (( uiteraard is de onversleutelde communicatie naar een proces op localhost niet zo'n ramp in de praktijk, maar mocht er dus een malafide proces meeluisteren, dan kan dat in theorie onderschept worden ))


Ter volledigheid, wat je dan creëert met Pi-hole en cloudflared:
Browser --_DNS--> OS --_DNS--> Pi-Hole --_DNS--> cloudflared --_DoH--> CloudFlare

Met AdGuard Home:
Browser --_DoH--> AGH --_DoH--> Cloudflare

[The Third Man]

Ah dat bedoel je, maar dat kan toch met dnscrypt? Zie https://github.com/DNSCrypt/dnscrypt-proxy/wiki/Local-DoH

Browser --DoH--> dnscrypt (op de Pi-Hole) --DoH--> CloudFlare

[lenwar]

Daar kan het 'deels' mee.

'De pi-hole' is geen hardware hè? Dat is een stuk software dat op (virtuele) hardware draait.


Als je dan alsnog de DNS-sinkhole wil gebruiken komt het hier op neer:

Browser --_DoH--> dnscrypt-proxy --_DNS-->Pi-Hole --_DNS--> cloudflared (of wederom dnscrypt-proxy) --[DoH]--> Cloudflare

Je hebt dan nog steeds twee keer onversleutelde communicatie (waarschijnlijk beide keren van en naar localhost, dus de impact is beperkt) en dus wederom ook weer een stuk extra software draaien, in plaats van gewoon één stuk software te pakken dat alles in één doet.

[Redstone]

Dan maar adguard

[youridv1]

Zonde, dan ben je nog steeds per apparaat aan het klooien. Dan installeer ik persoonlijk liever gewoon een adblocker op ieder apparaat.

Scheelt me ook een apparaatje in mijn netwerk dat kapot kan gaan of down kan zijn. Kans is natuurlijk erg klein, maar toch

[Reactie gewijzigd door youridv1 op 24 juli 2024 12:43]

[Amkiller]

in firefox blijft die bestaan in chrome gaat die verdwijnen.althans ze hebben problemen ermee.
nieuws: Chrome stopt medio 2023 met ondersteuning Manifest V2-extensies zoals...

[Reactie gewijzigd door Amkiller op 24 juli 2024 12:43]

[Snake]

Gebruik de canary domain: https://support.mozilla.o...in-use-application-dnsnet

[jpgview]

Lees hier (Block DNS over HTTPS (DoH), using pfsense).
DoH stoppen kan met IP lists, best aangevult met een Response Policy zone (RPZ) of Suricata.

[lenwar]

Of je gebruikt AdGuard Home als DNS sinkhole. Die kan je instellen als lokale DoH-server in je eigen LAN en dan heb je alsnog de voordelen van DoH vanuit je browser en je kan ook nog een DNS-sinkhole gebruiken.

DoH is onder aan de streep pas volledig zinvol als de applicatie het zelf doet en niet het OS. Je wilt met versleuteling namelijk dat, voordat het bij het OS komt, het al is versleuteld anders zou een malafide proces op je computer (in welke vorm dan ook) het DNS-verzoek kunnen afvangen.

[zaphod_b]

Leuk product dat piHole maar telkens als ik het probeer werkt het eerst helemaal top en gewoon snel. Na enkele weken worden websites ineens super traag of laden ze zelfs helemaal niet meer. Dit wordt langzaam erger en erger tot ik het zat ben en piHole eens uitzet om te checken…
En baf, alles ineens weer bloedje snel.
Ik kan niet achterhalen hoe dit kan en hoe dit op te lossen. Weerhoudt mij er ondertussen wel van het nog te gebruiken.

[bartje]

gebruik je je pi hole ook als gateway? of alleen als DNS?
ik heb vaker dit soort issues gelezen, en bijna altijd wordt de pihole dan ook gebruikt als gateway.

[r03n_d]

Ik gebruik al jaren Pi-Hole maar herken mij niet in je probleem. Misschien heb je te weinig opslag waardoor de logs vol lopen oid? Mijn raspberry wordt soms maanden niet gereboot of uit gezet.

[Ryen]

Als noodoplossing zou je een wekelijkse reboot kunnen schedulen op een stil tijdstip. Moet eigenlijk niet nodig zijn, maar helpt wel.

[TheCeet]

Ik had vroeger exact hetzelfde voor. En toen de overstap naar AdGuard Home gemaakt en dat loopt (tot nu toe) nog steeds vlot.

[cadsite]

Misschien eens AdGuardHome proberen?
Die doet quasi hetzelfde.

[davidoffm]

Doet dit zich ook voor wanneer je ad-guard gebruikt?

[DRaakje]

Ik ben hier een tijd geleden ook overgestapt naar adguard, in mijn ervaring stabieler. Wat betekend geen problemen.

[Kjoe_Ljan]

Ik word een beetje moe van alle "AdGuard Home is beter" comments

[jpgview]

om maar te zwijgen over de misleidende topics die gepost worden om mensen over te halen om te switchen, lees hier

blijf het herhalen, grootste voordeel van pihole is het feit dat het gebaseerd is op dnsmasq (pihole-FTL = dnsmasq + pihole functies, o.a. regex). Dingen die je op het eerste zicht niet kan verwezelijken met pihole (web interface) kunnen bijna altijd met bijkomende dnsmasq config files, lees de dnsmasq man page

[bartje]

Ik gebruik pi-hole al jaren naar grote tevredenheid, maar steeds vaker wordt er aan mij gevraagd waarom ik geen ad-guard gebruik.

wanneer ik online vergelijkingen lees is altijd de conclusie dat ad-guard beter is, maar als ik de details bekijk zie ik niet zo snel waarom, er zijn wat features die afwijken en het dashboard schijnt beter te zijn

een feature als "use-stale-cache" zag ik een paar maanden terug al voorbij komen bij AG, en vroeg met af of dit ook in pihole kan, nu dus wel.

Je noemt het grote voordeel dnsmasq, ik weet niet of AG niet dezelfde voordelen heeft.

en net als @Kjoe_Ljan wordt ik ook een beetje moe van de comments.

[jpgview]

ik vind niet zo direct een beschrijving van de "use-stale-cache" optie, maar kan me er wel iets bij voorstellen.

pihole gebruikt de dnsmasq cache, die ruimschoots voldoende groot geconfigureerd is (10000).

zelf heb ik, omdat ik ook unbound gebruik, die pihole cache op 0 (zero) gezet, en gebruik de unbound cache + redis (hier besproken).

Al met al word aan de cache optie teveel aandacht besteed, zelfs als je alleen de pihole cache gebruikt, duurt het gewoon even voor de cache voldoende hits bevat, om er effectief een heel klein beetje voordeel mee te bekomen. Dat voordeel verdwijnt weer (even) zodra je reboot (cache leeg).

Er zijn een paar uitzonderingen op dat "leeg na reboot"
- met redis kan je de cache op disk bewaren, restore na reboot
- met knot-resolver (vergelijkbaar met unbound) is het zelfs zo dat de cache altijd op disk word wegegeschreven, en gerestored na reboot.

Lijkt mij al bij al géén reden om over te schakelen, in de meeste gevallen twijfelachtig of de user experience er door beinvloed word....

je kan de status van de dnsmasq cache bekijken in de web interface (settings / tab system)

[lenwar]

offtopic:
Disclaimer: Onderstaande is bedoeld als grapje:
Ja, maar AdGuard Home is ook beter!! ;-)

Beide producten hebben gewoon veel overlap. AGH heeft een aantal aspecten die pi-hole niet heeft. Ik zou niet weten of Pi-hole iets wel kan en AGH niet. Er zijn vast wat zaken die, doordat Pi-hole effectief een dnsmasq-server is, die AGH denk ik niet kan? (ik zou oprecht niks kunnen bedenken, maar er zijn vast wel dingen te bedenken)

Maar onder aan de streep komt het er op neer dat als Pi-hole volledig aan je eisen voldoet en dat je het fijner vindt om een community-driven stuk software te gebruiken, of dat je de interface gewoon fijner vindt, dan moet je het gewoon gebruiken. (Een beetje zoals welke browser, of wel OS je fijner vindt. Als het voor iemand werkt, is alles prima toch?)

En inderdaad zoals @jpgview hieronder aangeeft, is er om een één of andere reden een soort vage vete van wat hardcore gebruikers van de producten met allerlei non/misinformatie. Degenen die de topics rondom Pi-hole en AGH volgen, weten ondertussen dat ik een groot voorstander ben van AGH, voornamelijk vanwege de native DoH-functionaliteit. Ook wat andere dingetjes stuwen mijn voorkeur naar AGH, maar ik heb ook echt jaren lang heel tevreden gewerkt met Pi-hole.

[sircampalot]

Prima software (icm unbound), heeft jaren stabiel gedraaid op een SD card tot deze corrupt raakte.
Daarna een backup gerestored op een ssd in een usb behuizing (totaal 25,-), en het draait weer vrolijk door.

Hier wordt de update trouwens nog niet getoond in de GUI.

[jpgview]

updatechecker draait maar één keer per dag.

run: pihole -up --check-only om een updatecheck te forceren.

[EmbarrassedBit]

Gebruik Pi-hole sinds een week en ben tot nu toe heel tevreden. Ik heb lange tijd de boot afgehouden omdat ik dacht dat het geen totaaloplossing is aangezien het in je lokale netwerk draait. Tot ik onlangs een Wireguard-server installeerde via een script dat toch al een viertal jaar actief ontwikkeld wordt en een Pi-hole installeerde op dezelfde server. Upstream DNS is de publieke DoH-server van het Zwitserse Digitale Gesellschaft (vergelijkbaar met de EFF) via cloudflared.

Vervolgens genereerde ik via het Wireguard-script een Wireguard config-file die ik aanpaste zodat het wg0-adres van de Pi-hole het enige AllowedIP en de DNS-server is. Op die manier wordt mijn niet-DNS-verkeer niet getunneld via het VPN en wordt mijn downstream-snelheid niet beperkt door de flessenhals van de upstream-snelheid van de residentiële internet-verbinding waarachter de VPN-server zich bevindt. Als ik anderen zou willen helpen met ad-blocking, zonder dat risico dat ze de config-file aanpassen om al hun verkeer te tunnelen, zou ik via iptables FORWARD-regels eerst alle verkeer van hun wg0-IP naar alle bestemmingen kunnen droppen, en vervolgens via een regel het kunnen toestaan naar het wg0-IP van de Pi-hole.

Iemand bedenkingen bij deze setup?

[Reactie gewijzigd door EmbarrassedBit op 24 juli 2024 12:43]