Software-update: Pi-hole Core 6.4 / Web 6.4.1 / FTL 6.5

Versie 6.4 van Pi-hole Core is uitgekomen. Ook zijn Pi-hole Web 6.4.1 en Pi-hole FTL 6.5 verschenen. 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 hoeven te 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, deze handleiding van tweaker jpgview, of dit topic op ons forum. De releasenotes voor deze uitgave kunnen hieronder worden gevonden.

Pi-hole FTL v6.5, Web v6.4.1 and Core v6.4 Released!

As always, please read through the changelogs before updating with pihole -up

Don’t forget, you can use Teleporter to export your configuration. It can be found under the settings menu of the web interface or on the command line with pihole-FTL --teleporter

This release has also been tagged on Docker as 2026.02.0

Security fixes

Two security vulnerabilities in the web interface have been patched in this release.

• Stored HTML Injection in Pi-hole Web Interface via Local DNS Records (CNAME/Hosts) in data-tag Attribute: fixed with d328f14
• Stored HTML Injection in Pi-hole Web Interface via X-Forwarded-For Header in Active Sessions Table: fixed with 1a0c6f4

Performance improvements

Faster startup (FTL #2725): FTL now imports historical queries from the database asynchronously on startup. Previously, DNS resolution was blocked until the entire query history had been loaded into memory. Now, FTL begins accepting DNS queries immediately and imports history in a dedicated background thread. The garbage collector is held off until the import is complete to ensure data consistency.

Low-memory hardware optimizations (FTL #2757): A new database.forceDisk configuration option forces FTL’s in-memory SQLite3 database to live on disk instead of in RAM. This can notably reduce FTL’s memory footprint, which is beneficial on resource-constrained hardware such as older Raspberry Pi models. On NVMe-backed systems no measurable performance difference was observed, though some slowdown may be seen on slower storage.

Faster gravity updates (FTL #2710): Several cumulative efficiency gains have been applied to the main domain validation loop that runs during pihole -g. While each individual improvement is modest, they add up across every entry in your blocklists and allowlists:

• A lookup table now validates domain characters using a single comparison per character, replacing multiple branching comparisons
• IP address testing is short-circuited: IPv4 tests only run if the token starts with a digit, and IPv6 tests only run if a colon is present within the first 5 characters
• The unicode BOM check is now performed once per file rather than once per line

In testing with ~5 million domains across several lists, gravity update time dropped from ~27s to ~23s (roughly a 16% reduction in real time, and ~22% reduction in CPU time).

Versienummer	6.4 / 6.4.1 / 6.5
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Pi-hole
Download	https://github.com/pi-hole/pi-hole/#one-step-automated-install
Licentietype	GPL

Reacties (54)

[kuurtjes]

Als je op je privacy gesteld bent is het is ook een leuk idee om Unbound te hosten en als upstream DNS in te stellen. Deze DNS server contacteerd de nameservers rechtstreeks. Samen met Pi-hole (of in mijn geval Adguard Home) zit je dan wel goed.

[Reactie gewijzigd door kuurtjes op 19 februari 2026 01:49]

[Machlah]

Ik heb unbound en pi-hole maar merk toch af en toe wat rare dingen tijdens het browsen. Bepaalde sites die niet goed meer werken of bijvoorbeeld plaatjes in e-mails die niet laden. Heb je hier met adguard ook last van of draait alles soepel?

[curkey]

Als eerste zou ik eens in de block logfile kijken van PiHole om te zien of de url geblokkeerd wordt. Veel commerciële emails bevatten media dat gelinkt wordt via een tracker URL die dan een redirect doet naar de echte content. Dus dan lijkt het me terecht dat die plaatjes dan geblokkeerd worden (aka works as designed).

Evt kun je zelf alsnog besluiten om die specifieke domeinen dan op je whitelist te zetten, dat is aan jou.

Als dat het niet is: als je op de pihole inlogt met ssh, kun je eens een DNS lookup of een dig-commando uitproberen direct op de unbound poort (om zo te bepalen of het issue in Unbound zit of in Pi Hole). Als unbound 'm resolved, dan zit er toch echt een filter in Pihole.

[bytemaster460]

Ik heb unbound ook al jaren draaien maar herken dat probleem niet. Ik zou ook niet kunnen bedenken waarom dat door unbound zou komen.

[PaulHelper]

Ik heb unbound Al vaak gehoord maar nog nooit gebruikt. Ik heb een kleine vos met nog ongeveer 1GB RAM over die ik nog kan gebruiken. Zou ik unbound daarop kunnen draaien of neem het veel meer ram en opslag in beslag? Verder wat zijn de voor en nadelen van eigen upstream draaien?

[jcbvm]

Unbound zelf gebruikt maar iets van 40mb ram en de grootte van de cache (het opslaan van de dns queries) kun je zelf regelen, maar met 50/100 mb zit je heel ruim. Dus 1 gb lijkt me meer dan genoeg

[curkey]

Werkt prima bij mij op mijn oude Pi 3B met 1GB RAM. Deze guide werkt prima, ik had de boel up & running in no-time. Inmiddels ben ik van Pi-hole overgestapt op Adguard Home, maar de unbound config kon ik 1:1 daarin gebruiken.

https://docs.pi-hole.net/guides/dns/unbound/

[PaulHelper]

Gebruik zelf ook adguard home haha, maar ik nam inderdaad aan dat dat niet veel zou uitmaken
Dan ga ik eens kijken of het was is

[Reactie gewijzigd door PaulHelper op 19 februari 2026 10:52]

[curkey]

In feite doe je niet veel meer dan unbound als resolver laten draaien op je lokale Pi, maar zet je deze poort niet open naar buiten, bv lokale poort 5353.

Als dat werkt, dan pas je de Adguard / Pi-hole config aan en laat je diens upstream DNS voortaan wijzen naar 127.0.0.1:5353. Voila. Voor de clients verandert er niets, die kletsen nog steeds tegen AGH/PH.

[jb044]

Zit nog wel een loophole: plain dns is unecrypted verkeer vanaf jouw ip. Dus standaard sta je voor deze keuze:

- een dns over tls of https proxy gebruiken, cloudflared kan dit. Had in eerste instantie een variant gemaakt voor docker die dit OOTB kan: jb044/pihole-doh - Docker Image Je neemt dan voor lief dat cloudflare of google of wie dan ook de service biedt al jouw dns verkeer kan traceren.

- wel bijvoorbeeld unbound gebruiken, maar je verkeer routeren via een vpn zodat je dns verkeer veel moeilijker zo niet onmogelijk naar jou terug te leiden is.

Ik ben persoonlijk voor 2 gegaan, maar wil dus wel opmerken dat unbound gebruiken icm pihole niet per definitie privacy verhogend is.

[asing]

Cloudflared is ook een optie.


Het nadeel van unbound is dat deze bij de root server begint en dan doorvraagt tot hij bij de dns server is die weet waar de host staat. Al dat verkeer gaat over poort 53. Onversleuteld.

Cloudflared is iets sneller, maakt gebruik van encryptie en is niet in te zien door je provider. Wel weet cloudflare wat je hebt aangevraagd.

[xxs]

Je kan ook Unbound DNS over TLS laten doen en Mullvad beweerd geen logging bij te houden en draaien alles in RAM dus ook geen opslag op media.


include-toplevel: "/etc/unbound/unbound.conf.d/*.conf"

server:
       tls-cert-bundle: "/etc/ssl/certs/ca-certificates.crt"

forward-zone:
       name: "."
       forward-tls-upstream: yes        # use DNS-over-TLS forwarder
       forward-first: no                       # do NOT send direct
       forward-addr: 194.242.2.2@853#dns.mullvad.net


Bij mij loopt al mijn verkeer ook nog eens via een (niet Mullvad) VPN naar buiten dus dat gaat een lastige worden om DNS verkeer aan mij te linken.

[Reactie gewijzigd door xxs op 19 februari 2026 14:12]

[squareware]

Weet iemand hoe het kan dat ik wel de piratebay kan bezoeken via pi-hole, aangezien deze geblokkeerd is door de isp.
Zit er een of andere proxy in die het verkeer omleid of een andere dns?

Heb het draaien om de hoeveelheid ads in android games voor de kindere te minimaliseren, maar me nooit echt goed in verdiept naar de mogelijkheden. Met toeval dat ik er achter kwam dat ik op die site kon komen.

[Prince]

Hangt ervan af wat je als upstream dns hebt ingesteld in pihole. Gezien je het niet weet, zal het vast geen custom dns zijn.
Kan google, cloudflare, opendns, level3, comodo, Quad9 zijn.

[squareware]

Net even gekeken, inderdaad Google (ECS, DNSSEC).


Dus google resolved de dns, maar waarom werkt het? Als ik 8.8.8.8 instel als dns zonder gebruik van pi-hole dan is de blokade er.

[Prince]

Dan gebruik je niet de 8.8.8.8.
Stel je hem in je OS in, of in de router?
Indien in de router, dan moet je een ipconfig /renew doen om via DHCP de nieuwe instellingen te krijgen (in Windows). (of even herstarten als je niet weet hoe dat moet)
Als je een "nslookup www.google.be" doet in de terminal, dan zie je ook welke dns je gebruikt op dat moment. Met een ipconfig /all kreeg je ook je ingestelde dns te zien dacht ik (kan even niet controleren, zit nu op mijn Kubuntu machine...

[squareware]

Ja router en ook een keer lokaal, beide heb ik geprobeerd, dan wordt die site dus gewoon geblokkeerd.

Ipconfig /all geeft uiteraard het juiste dns aan(google), niet die van de isp.

[Prince]

Wat ook kan is dat je in je browser de "use secure DNS" optie aan hebt staan. Die gebruikt DNS over HTTPS/SSL. Die negeert dan die "gewone DNS" (over poort 53) en doet een secure variant. Mogelijks blokkeert die wél jouw boot-avonturen.

[squareware]

Ah, dat zou kunnen, ik zie niet zo snel waar ik dat kan wijzigen / vinden. (Samsung internet :-))


Maakt ook verder niet uit, was wel benieuwd.
Nu ik er toch in zet meteen maar updaten.

[CH4OS]

En ipconfig /flushdns niet vergeten om de DNS cache te legen.

[Toet3r]

Misschien dat je isp de piratebay heeft geblokkeerd op hun dns servers. Als je die niet gebruikt maar via pi-hole een andere dns server dan resolved die site gewoon.
Deze manier van blokkeren is dan ook echt wel een half bakken manier van een blokkade opzetten.

[RobertMe]

Er is, zeker tegenwoordig, geen goede generieke manier om een blokkade op te zetten. IP blokkades werken immers vaak niet (of nouja, veel te goed) doordat het halve internet achter Cloudflare, Akamai, cloud load balancers (AWS, Azure, GCP) zit. 1 IP adres blokkeren en er zijn honderden / duizenden / ... websites onbereikbaar.
En door TLS (/HTTPS) kan de ISP het bezoek ook niet afvangen op basis van de hostname in het HTTP verkeer. En op basis van nieuwe standaarden is zelfs SNI, waarbij de handshake en communicatie omtrent het te bezoeken domein wel nog plain text is, ook niet meer nodig.

Een DNS blokkade is dus zeker niet effectief, maar wel de enige zonder neveneffecten die toch een invulling van blokkade geeft. En uiteindelijk is natuurlijk alles te omzeilen. Want als een DNS blokkade niet goed genoeg is (om te voldoen aan de juridische verplichting) omdat je andere DNS server kunt instellen. Waar ligt dan de grens? Waarom zou een ISP dan, bv, niet hoeven op te treden als de klant een VPN gebruikt? (Of zou de ISP dan ook daar tegenop moeten treden en voorkomen dat klanten via een VPN TPB bezoeken?)

[Reactie gewijzigd door RobertMe op 18 februari 2026 22:50]

[HakanX]

Het idee is het merendeel blokkeren, zodat het niet te makkelijk wordt en genoeg mensen bv streaming abonnementen nemen. De moeite om de laatste 1% hardcore gebruikers ook te blokkeren is het niet waard. Die gaan én sowieso geen abonnement nemen én ze vinden altijd wel een weg om het toch te kunnen. Gaan we weer terug in de tijd FXP'en.

[curkey]

Als de ISP alleen hun eigen DNS lookups blokkeert, dan kun je er gewoon prima bij zodra je een IP adres hebt gevonden ja. Ik kom ook gewoon op de site als ik wil, ik heb mijn eigen DNS resolver draaien op de Pi.

[PaulHelper]

Ik denk dat ik snap wat jij wil zeggen maar met een ip kom je er dus niet. Heel veel sites zijn niet beschikbaar door direct ip omdat ze alleen via hostnames beschikbaar zijn.

[curkey]

Maar je browser geeft de hostnaam in het get-request, maar de connectie zelf is op basis van IP adres.
Dus als je het juiste IP-adres weet, zou je zelfs gewoon je hosts file kunnen aanpassen, en je systeem zal die gebruiken.

[TheCeet]

ISP DNS: block

3rd party zoals Google, Cloudfkare niet.

Kijk even bij je upstream DNS welke provider daar staat. Je kan wel nog steeds bij settings in pi-hole de DNS opgeven van je ISP als je dit wenst.

[Jay-v]

Omdat je ISP het verkeer niet echt blokkeert. Ze halen de domeinnaam gewoon weg in DNS (eg het telefoonboek waar domeinnamen worden doorverwezen naar een IP)

Pi-hole wijst standaard naar Google’s telefoonboek, en daar staat het IP wel in.

Dit is overigens ook precies hoe Pi-hole werkt, het haalt de domeinen van advertentie domeinen weg waardoor je computer de advertenties niet meer kan laden.

[Omega]

Ze blokkeren de site op netwerkniveau. Dus nee, dat zal niet werken. Ook als je het adres kent zullen ze je simpeleweg niet doorlaten.

[edwin2021]

Android heeft dns hardcoded in OS zitten, negeert dus router/isp dns.
Enige optie is om op de router een dns rerout te zetten naar de pihole.

[curkey]

Niet alle apps negeren je home DNS overigens.
Sowieso kun je Firefox mobile ook aanpassen (setting in de config) dat hij je DNS gebruikt en niet zijn eigen resolving oplossing.

[rvdv12773]

Ik gebruik pi-hole al een tijdje (op een raspberry 3B), maar ik merk dat sommige sites af en toe traag laden (en het zijn sites die ik vaak bezoek, dus pi-hole hoeft alleen maar even in de database te kijken). Als ik in de query-log kijk, dan zie ik ook niets bijzonders...

[HakanX]

Sommige sites vinden het niet zo leuk als hun advertenties of spytools geblokkeerd worden. De ene probeert meerdere wegen om toch te verbinden, de andere vertraagd de boel met opzet. YouTube vertraagt bv. Soms moet ik een paar seconden wachten, soms duurt het zelfs tot 10 sec tot een stream alsnog begint af te spelen. Alles beter dan om de haverklap 30 seconden reclame te kijken.

Het komt iig niet doordat je raspberry te traag is.

[edwin2021]

Hoe heb je YT reclame geblocked? Lukt mij niet anders als door brave Browser te gebruiken.

[Toet3r]

Ublock Origin browser plugin

[Geim]

Adblock voor Youtube als plugin voor Chrome.

[HakanX]

en @DrFurioux
Mijn voorbeeld was algemeen dat adressen blokkeren soms ook voor vertraging kan veroorzaken op verschillende webdiensten.

Op de pc gebruik ik YouTube op Firefox met Enhancer for Youtube . Doet veel meer dan reclame blokkeren, je kan YouTube tot in perfectie aanpassen naar je smaak. Daarnaast ook Ublock Origin, maar weet niet of dat nodig is voor YouTube.

Voor Android TV heb je een alternatieve client dat heel erg op het orgineel lijkt. SmartTube.

[rvdv12773]

Op de TV is het inderdaad lastig in YouTube, daarom gebruikt ik SmartTube op mijn TV (je moet de APK wel handmatig installeren, en de TV moet uiteraard een Android OS hebben). Anders is een Chromecast-stick altijd nog een optie...

In de browser op mijn computer gebruik ik Ublock Origin, blocktube (en unhook om vervelende blokken in YouTube uit te schakelen, zoals shorts, trending etc.) Dit houdt zo'n beetje alles tegen behalve hetgeen je wil zien.

[Reactie gewijzigd door rvdv12773 op 19 februari 2026 21:41]

[DrFurioux]

Ik ben ook wel benieuwd hoe je YT adds blocked. Brave werkt fantastisch op mobiel en pc, maar op de TV krijg ik ze uiteraard nog steeds. Ook met AdGuard helaas.

[curkey]

Je kunt in de browser eens F-12 gebruiken om de Developer tools op te roepen. Daar zit normaliter wel een tab waar je de laadtijden van alle elementen kunt volgen.

Ik vermoed dat je zult tegenkomen wat anderen al zeiden: juist omdat je advertenties niet ophaalt, zullen er door de eigenaar van de site expres vertragingen ingebouwd worden om je te narren. Zeker als je in je Pihole logs ziet dat de DNS lookup gewoon snel verloopt, dan blijft er weinig anders over.

[fre0n]

Als je iets meer features nodig hebt kun je ook https://technitium.com/dns/ gebruiken. Deze is wat minder geschikt om out of the box te draaien maar meer dam 3 kliks extra om de adblocker aan te zetten is ook niet nodig.


Werkt ook prima in een docker container

[renrom]

Helemaal eens! toevallig een paar weken ook overgestapt van Pi-Hole naar Technitium. Strakke gui en uitgebreide mogelijkheden.

[rbr320]

Welke mogelijkheden heeft Technitium wel die jij en @fre0n missen in Pi-Hole?

[renrom]

Er is veel overlap hoor, maar ik had wat aparte issues met PI-Hole, met name na updates. Ik heb meerdere VLAN's actief en daar reageerde PI-Hole na updates weer standaard op dat deze geen resolving toe liet.

Daarnaast het maken van een local zone, kan wel in pi-hole, maar in Technitium is dit in mijn ogen iets makkelijker en uitgebreider.

[Lennyz]

Ik houd van zelf hosten, alleen voor DNS vind ik nextdns.io toch wel echt veel makkelijker. Dan kan ik het tenminste simpel op mn telefoons gebruiken zonder vpn oid.

[Hann1BaL]

Ik kende NextDNS.io niet, maar dat is inderdaad vrij simpel. Echter kies je er dan wel bewust voor dat Nextdns.io alles van je mag weten ipv je ISP in alles wat je zoekt.

Maar het is wel simpel en doeltreffend.
Zelf draai ik een split tunnel wireguard (of full tunnel ) naar huis om altijd verbinding naar mn pihole te hebben.

[Lennyz]

Ja klopt dat is een nadeel. Hoewel hun privacy policy zegt dat ze de data niet doorverkopen. Misschien kun je zelfs stellen dat het risico lager is dan de DNS van Google. 8.8.8.8.

[JSBach]

Een pijnloos en goed verlopen sudo pihole -up en de security vulnerabilities kunnen geen kwaad meer. Goede ondersteuning.

[StGermain]

Ik hoop maar dat het optioneel blijft om de database niet in het geheugen te hebben anders staat mijn NAS heel de tijd te rammelen.

[Maksor70]

voor YT gebruik ik nog gewoon Ublock maakt het niet trager

[eovermeer]

Ik heb Pi-hole pas enkele weken draaien op een Pi Zero 2 W en dit draait onverwacht soepel op deze dreumes.

Is het nog aan te bevelen om de standaard Steven Blacklist te vervangen of aan te vullen?

[GeeBee]

Ik krijg met de update (via PuTTY) de foutmelding:

[i] SELinux not detected
[✗] Update local cache of available packages
Error: Unable to update package cache. Please try "sudo apt update"
Unable to complete update, please contact Pi-hole Support

Dus ook een sudo apt update gedaan, en voor de zekerheid ook een sudo apt full-upgrade. Dat gaat allemaal goed, maar de update blijft daarna dezelfde foutmelding geven.

[GeeBee]

Complete upgrade uitgevoerd van buster naar bullseye (met dank aan Lumo AI) en alles werkt weer.