Home   2026-10-22 19:56:51

←

Software-update - Pi-hole Core 6.5 / Web 6.6.1 / FTL 6.8

Original article

Pi-hole logo (Über)Versie 6.5 van Pi-hole Core is uitgekomen. Ook zijn Pi-hole Web 6.6.1 en Pi-hole FTL 6.8 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.8, Web v6.6.1 and Core v6.5 released

This release fixes a number of security advisories across FTL, Web and Core. Thank you to everyone who reported them. Before updating, please read the changelogs below. Update with pihole -up. If you want a safety net, take a backup of your configuration first with Teleporter (Settings -> Teleporter in the web interface, or pihole-FTL --teleporter).

The Docker image is tagged 2026.10.0.

Security fixes

High

  • Core: command execution via a crafted PID (GHSA-cf36-4hhc-8398, CVSS 7.8): getFTLPID() now only accepts a PID naming a running pihole-FTL, and logrotate uses it.
  • Core: root writing to config-supplied paths (GHSA-mff6-cjc4-5wq9, CVSS 7.3): gravity.sh re-executes as pihole, and the log flush writes as pihole.
  • Core: root following a symlink when writing the version file (GHSA-xcb-4qxw-g5vj, CVSS 7.8): the update checker and FTL prestart script no longer create or chmod files in the pihole-owned /etc/pihole as root.
  • Core: /opt/pihole hardening (GHSA-j8vh-6fp9-cjcx, CVSS 7.8): read-only for the FTL service.
  • FTL: document root relocation via Teleporter import / symlink (GHSA-2h7g-g549-hf74, CVSS 7.7): an authenticated session could move the document root to / and, with webserver.serve_all, serve files unauthenticated.

Medium

  • FTL: local file contents echoed when parsing a file:// adlist (GHSA-667h-gpmh-7gxc, CVSS 6.5): an authenticated user could read files the pihole user can open. Needs the matching Core change (#6706).
  • FTL: app sessions could read password hashes and the TOTP secret (GHSA-v53r-4564-3449, CVSS 6.5; duplicate GHSA-846w-3j3v-2hx8): read-only app sessions could read both via /api/config and /api/teleporter.
  • FTL: out-of-bounds write in the API TXT buffer (GHSA-8fc6-q9x4-892v, CVSS 5.9): needs a long upstream server list, no authentication.
  • FTL: EDNS(0) data leaking between clients’ queries (GHSA-xj4x-gf2g-r6m7, CVSS 4.2): data from one packet could be applied to another client’s query.

Low

  • Core: file:// adlist read check and curl could resolve different files (GHSA-g63w-24cr-p3w6, CVSS 2.2): a bypass of the read check that the FTL file:// fix relies on, needing an admin who can add adlists plus a symlink and decoy on the filesystem. Local lists are now read with cat as the user whose access was checked.
  • FTL: cross-site requests and DNS rebinding against a passwordless install (GHSA-322h-f873-hp54): with no password set, any website opened on the network could reach the API through the visitor’s browser. FTL now refuses cross-site browser requests and unrecognised Host names when no password is set.
  • FTL: race when deleting a DHCP lease (GHSA-v8mj-cqgw-63rj, CVSS 2.2): needs an authenticated client and the DHCP server enabled.
  • FTL: crash when searching domains during a list reload (GHSA-9828-2f2q-2c8v, CVSS 2.2): needs a valid session.
  • FTL: crash on a malformed POSTed regex array (GHSA-mqr7-j2p5-5495, CVSS 2.7): needs a valid session.
  • Web: stored XSS on three settings pages (GHSA-rmr4-hqc8-825f, GHSA-3vhj-5284-xrmm, GHSA-qfpp-28mj-pj6p, CVSS 3.5 / 3.1 / 3.1): Settings > All settings, Local DNS Records and DNS.
FTL v6.8

This is a minor release rather than v6.7.2: there are enough visible behaviour changes that a patch version would undersell it. It backports the bug fixes that landed on development since v6.7.1 and updates the embedded dnsmasq (v2.93+30) and SQLite (v3.53.3).

Improvements

  • The live log is now stored as a ring buffer instead of moving the whole buffer for every new line, which costs far less CPU per cached answer.
  • Internationalised domain names on lists are converted to punycode with libidn2 and block, instead of being rejected as invalid.
  • Long-term statistics are grouped before joining the name tables (faster), and two unused in-memory indexes are gone, saving about 22 MB per million queries.

Notable fixes

  • Flushing the logs deleted the whole long-term history, not only the last 24 hours, and moved the graph a day into the future.
  • Crashes with 257+ alias-clients, with a no-longer-forced FTLCONF_ array, and with database.DBinterval = 0.
  • Group and list changes not reaching a client until the next reload, stale forced replies, and missing EDE on the first block.
  • A file path containing + (or any other printable ASCII) was reset to its default on start-up.
  • An open redirect in the .lp compatibility redirect, and / ignoring webserver.serve_all.
  • Pi-hole’s own certificate for a custom webserver.domain was never renewed, and a domain longer than 64 characters ended up as an oversized CN.
  • The empty-DS DNSSEC loop, via dnsmasq, plus its double-free and information disclosure fixes.
  • An API session could enable misc.readOnly through a Teleporter archive, and pihole.toml.lock failed on NFS.
  • Any LAN client could make FTL add a new PTR record for every spelling of its own address until a restart.
  • The CLI password file and pihole-tmp.db were briefly or permanently readable by everyone.
  • On ARM and RISC-V the MAC address of a new device was never looked up at query time, so its MAC-based groups only applied later.
  • Raising misc.privacylevel at runtime did not cover domains and clients already seen, and an ntp.sync.interval above about 24.8 days made the NTP client sync back to back.
  • DNS stalls on list reloads and rate limiting, GC double processing, lost queries at shutdown, and wrong long-term statistics.
  • Old queries were never deleted from pihole-FTL.db on a host that restarts FTL at least once a day.
  • dhcp-discover printed the DNSSL labels of Router Advertisements unescaped.
  • Clients without a MAC address (e.g. a WireGuard peer) stayed in the default group until the next list reload, because the groups of a new client were resolved before its interface was known.
  • The load check counted only the CPUs a container was limited to, while /proc/loadavg shows the host’s load, so the long-term load warning fired spuriously and /api/info/system inflated the load percentage in LXC/Docker with fewer cores. FTL now counts all present host CPUs.
  • Assorted API fixes: CORS headers on 204 and error responses, the reply shape of /api/queries at privacy level 3, /api/history/clients at every privacy level, 64-bit swap figures in /api/info/system, and a rejected POST /api/teleporter upload whose import field does not parse.
  • FTLCONF_files_log_ftl was not used for log lines on early startup.

Behaviour changes to be aware of

  • Invalid values found in pihole.toml are rejected and reset to the default: database.DBinterval of 0, a webserver.tls.cert below the webroot, a non-base32 webserver.api.totp_secret, relative paths for files FTL writes, and a files.tmp_db that names another file Pi-hole keeps (e.g. pihole-FTL.db). A webserver.api.maxHistory above 86400 is reduced to 86400. A list (e.g. dns.hosts) now loses only its invalid entries instead of being reset as a whole.
  • With webserver.serve_all = false, / under a host other than webserver.domain now returns a 404, so a custom index.html in the webroot no longer shows up at http://<ip>/. Behind a proxy that does not strip webserver.paths.prefix, the prefixed path returns a 404 as well.
  • A renewed self-signed certificate comes with a new CA, so an imported tls_ca.crt has to be imported again.
  • FTL no longer hands a symbolic link (e.g. pihole-FTL.db or FTL.log linked to another disk) to the pihole user, and warns about it on every start. Such a target has to be owned by pihole already.
  • When FTL runs as root it only changes ownership or permissions of regular files directly in /etc/pihole and /var/log/pihole, and refuses a symbolic link as log file (including files.log.dnsmasq). Started as pihole, a linked log file keeps working.
  • A blocking timer on an unchanged status now switches to the opposite mode when it expires.
  • The host’s own interfaces show up in the network table, and shutdown may wait up to 30 seconds for a busy database thread.
  • dnsmasq adds the option4: syntax and DHCPv6 vendor classes.
  • Changing ntp.sync.interval restarts FTL, ntp.sync.count = 0 is rejected, and POST /api/action/gravity answers 409 while a run is in progress.
  • Queries older than database.maxDBdays are deleted in the first night after a start, 10000 at a time. A database that kept growing will lose its whole backlog in the first night after the update.
  • A v5 Teleporter import replaces the upstreams, reverse servers and excluded domains/clients instead of adding to them.
Web v6.6.1

A patch release for the stable line while development is mid-rework (AdminLTE 4 / Bootstrap 5).

  • Query Log: show the actual API error (e.g. “The item is already present”) instead of a generic network error.
  • Conditional Forwarding: reject CIDR and otherwise invalid server IPs.
  • Static DHCP leases: fix the tag: validation regex and allow internal underscores in hostnames.
  • hexEncode() now handles code points above U+FFFF.
  • Login no longer blames the password for a refusal that is not about it.
  • Query Log: the API URL is no longer encoded twice.
  • Bundled Moment.js bumped to 2.31.0.
  • DNS settings: clearer “local requests” wording, and an emptyTable typo fixed.
Core v6.5
  • Stop double-rotating logs now that pihole is in /etc/logrotate.d.
  • Remove the deprecated arpflush command in favour of networkflush.
  • Improve gravity error handling.
  • Fix unquoted variable expansion in rm paths.
  • Send USR2 after logrotate.
  • Keep /etc/pihole/versions readable by all users.
  • Remove Debian 11 from the CI distro matrix.
  • Fix URL parsing in gravity.sh.
  • Improve the gravity database schema for performance: WITHOUT ROWID junction tables, new indexes for group lookups and cheaper triggers. Existing databases are migrated to schema version 21 on update.
  • Store the listsCache directory next to gravity.db instead of always in /etc/pihole.
  • Run the update checker and the FTL prestart file fix-ups as the pihole user, and only trust git repositories the pihole user cannot modify.
  • Read local file:// adlists as the user whose access was checked, instead of via curl.
  • Parse local file:// adlist URIs with parameter expansion and path canonicalisation (RFC 8089)
  • Pass the adlist source URL to FTL’s parseList (needed by the FTL v6.8 file:// adlist fix).
  • Flush the last 24 hours of queries through the FTL API instead of touching the database directly.
  • Stop granting CAP_CHOWN to everything pihole-FTL executes (kept in the ambient set of the FTL service).

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

Reacties (51)

Ik gebruik alleen die van OISD.

Ik heb niet het idee dat er in de praktijk veel doorheen komt.
Oisd is niet meer zo heel uitgebreid als het ooit was. Hagezi erbij is zeker wel een aanrader.
Die kende ik niet. Wat is jouw persoonlijke ervaring met ‘gedoe’ met die lijst? Zijn er dingen die het stuk maakt? En hoevaak loop je daar tegen aan?

Met oisd heb ik echt nooit problemen. Ik heb ook niet het idee dat er dingen doorheen gaan.
Hagezi heeft meerdere lijsten, het ligt eraan wat en hoeveel je blokkeren wilt. Er zijn meer reacties hier over Hagezi. Met de lijsten die ik in mijn Technitium heb, heb ik nu zo'n 8M domeinen geblokkeerd. Het vreet daardoor wel veel RAM... Zie ook Erulezz in 'Pi-hole Core 6.5 / Web 6.6.1 / FTL 6.8'

[Reactie gewijzigd door CH4OS op 17 oktober 2026 23:53]

Maar wat is jouw persoonlijke ervaring?

Die OISD-lijst focust op ‘niks gaat stuk’. Wat ik zo lees over die Hagezi is dat ze zelf bij de ‘aanbevolen lijst’ al aangeven dat je problemen gaat krijgen. Maar dat kan ‘in de praktijk’ heel erg meevallen of juist heel erg tegenvallen.

Het totaal aantal geblokkeerde domeinen vind ik persoonlijk niet zo interessant (dat is statistiek). Waar het mij om gaat is hoe effectief het is. (Dus zie je geen advertenties meer, maar blijft wel alles het doen.)
Met de lijsten die ik gebruik (en ik heb zelfs meer dan kiss en hagezi) gaat het goed met de domeinen die ik blokkeer, maar het is dus wel afhankelijk van wat je zoal blokkeert. Mijn ervaring is N=1, maar zegt dus weinig over jouw ervaring of die van een ander.
Voor mij is een ervaring uit iemand van hetzelfde taalgebied zinvoller dan een algemene statistiek. Als de problemen zich voornamelijk voordoen op sites die zich richten op Venezuela en Finland, dan kan dat de statistieken vertroebelen.

Maar als jij aangeeft dat je geen problemen hebt, dan ga ik het wel een keer proberen en kijken of ik het verschil merk. En als het toch gedoe wordt ga ik gewoon weer terug naar oisd. 😊
Je hoeft ook niet of oisd of hagezi te gebruiken, je kunt beiden tegelijkertijd gebruiken, dat doen vele anderen en ik ook. Oisd richt zich op NL/BE dacht ik, waar Hagezi diverse categorieën blokkeert, dus de opzet van de lijsten is anders.

[Reactie gewijzigd door CH4OS op 18 oktober 2026 07:59]

Ik heb er is een AI model tegenaan gegooid om de lijsten inhoudelijk te vergelijken en hoe ze verschillen. Er zit verbazingwekkend weinig overlap in.

OISD focust op phishing/scam, hazegi pro focust op tracking (ze hebben maar ongeveer 23% overlap). Dus die vullen elkaar inderdaad goed aan.

De TIF-lijst van HaZeGi bevat vooral heel veel ‘wegwerpdomeinen’ (bijna 50% .xyz-domeinen) en dat soort zaken. Dus voor ‘actuele scams’.

OISD heeft veel (18k, ten opzichte van TIF), unieke subdomeinen van gratis hosting providers. (Pro en TIF bij elkaar hebben maar 2% van die lijst gratis hosting subdomeinen)

Pro en TIF bevatten samen bijna 80% van wat er in OISD staat. (OISD heeft ingeveer 40k domeinen die niet in Pro en TIF samen staan)

Het kan dus inderdaad een meerwaarde hebben ze alle drie te hebben.
Dus welke raad je dan aan te gebruiken aub?

Ik gebruik via Adguard Home:

Oisd blocklist big

Phishing Army

HaGeZi’s Threat Intelligence
Ik gebruik zelf eigenlijk alleen OISD, en dat lijkt z’n ding te doen. Het apparaat waar ik (in mijn geval) Technitium op draai, is al ‘vol’ qua geheugengebruik, dus voor nu houd ik het daar op.

Je zou dus naast OISD ook die andere twee kunnen doen, maar het ligt er net aan waar je focus ligt. Als het je echt primair om de advertenties gaat, is het om het even welke van de twee je gebruikt.
Blocklists van HaGeZi zijn erg goed en veelgebruikt;

https://github.com/hagezi/dns-blocklists

Veel opties en mogelijkheden dus even goed doorlezen welke je wil.
HaGeZi inderdaad.

Met de 'Multi Pro' en de 'Threat Intelligence Feeds' kom je al heel ver.
Kan je verder nog aanvullen met andere lijsten die je wil.

Voor Pi-hole heb je het Adblock formaat van de lijst nodig.
Je kan die van AdGuard Home eventueel toevoegen.

https://adguardteam.github.io/HostlistsRegistry/assets/filter_1.txt

[Reactie gewijzigd door En-Cryption op 17 oktober 2026 20:23]

Ik wil je deze niet onthouden:

https://blocklistproject.github.io/Lists/smart-tv.txt

De naam zegt genoeg ;-)

Maar hier staan een aantal leuke lijsten in meerdere formaten w.o. Pihole en ADG

https://blocklistproject.github.io/Lists/

[Reactie gewijzigd door xxs op 18 oktober 2026 11:36]

Ik gebruik de Firebog collection https://firebog.net/, enkel de groene. Je kan het makkelijk toevoegen via de AIO (all-in-one) https://github.com/KnightmareVIIVIIXC/AIO-Firebog-Blocklists/raw/main/lists/aiofireboggreen.txt
Ik gebruik deze voor mijn Hosts File en ook als lijst in mijn pi-hole voor mobiele apparaten. Blijft goed up to date.
Ik gebruik de Adguard DNS en hoef hierdoor zelf niets te draaien, alleen DNS aan te passen.

Is PiHole echt veel beter dan dit? Kan het ook de advertenties binnen YouTube tegen houden bijvoorbeeld?
pihole/AdGuard home/Technitium/blocky/enz zijn op het stuk adblocking DNS Sinkholes. Ze kunnen geen van allen YouTube advertenties blokkeren.

Het voordeel van een externe dienst is, is dat je niets hoeft te doen qua beheer. Je DHCP-server die dns-servers laten opsturen of eventueel je router zelf die laten gebruiken en klaar.

Dit kan prima werken voor veel (de meeste?) mensen. Als je echter een complexer netwerk hebt en daar je eisen hebt voor, bijvoorbeeld, lokale DNS-records per vlan, of andere zaken, heb je al snel wat anders nodig.

Ook is een lokale DNS theoretisch sneller, maar of je dat in de praktijk zal merken durf ik te betwijfelen.

Dus als jij alles doet wat je wil doen met AdGuard DNS, en je geen zin hebt om het lokaal te toen (geen oordeel. Niet iedereen vindt het leuk om met die soort dingen bezig te zijn), dan heb je voor jezelf een perfecte dienst in gebruik.
pihole/AdGuard home/Technitium/blocky/enz zijn op het stuk adblocking DNS Sinkholes
Ik ga wellicht even muggenziften, want de tools hebben overlap, maar zijn niet hetzelfde.

Blocky en Technitium zijn in de eerste plaats meer DNS servers met ad blocking functionaliteiten. Pi-Hole en AdGuard Home zijn meer specifiek ad blocking sinkholes met daarnaast wat basale DNS functionaliteiten, zodat je beperkt een eigen DNS kan beheren. Dat geeft deze tools wel wat overlap, maar maakt ze niet hetzelfde. Zo gauw het DNS beheren wat specifieker wordt, ben je beter af met Technitium of Blocky, dan met Pi-Hole of AdGuard Home.

[Reactie gewijzigd door CH4OS op 18 oktober 2026 12:34]

Klopt helemaal. Maar daarom schreef ik ook op het stuk adblocking in het DNS sinkholes en daarom kunnen ze geen YouTube advertenties blokkeren.
adguard heeft ook een systeem wide echte ad blocker app op windows en android. die blokkeerd youtube, twitch en zo :)
Klopt. Die gebruik ik zelf ook. Ik had het specifiek over AdGuard Home (de DNS sinkhole). Dat is dus een ander product van hetzelfde bedrijf.
Ben benieuwd welke lijst je gebruikt voor de blokkade op YouTube advertenties, wanneer ik dat doe, stoppen de videos ook met werken.
Het is een DNS service en die blokkeert helaas geen YouTube ads, daar deze door hetzelfde domein worden geserveerd. Allleen een alternatieve YouTube client of brave browser bijvoorbeeld doet dit.
Ah, dat vermoedde ik al. Gelukkig gebruik ik zoveel als mogelijk ook Unlock (Origin) en Firefox als browser, maar er zijn genoeg YouTube specifieke browser extensies.
Het werkt precies het zelfde, maar dan in eigen beheer.
Nee, advertenties binnen Youtube en andere videos kan geen enkele DNS Ad-blocker verwijderen, omdat ze onderdeel zijn van de stream die je bekijkt.
Er zijn wel andere manieren om YouTube ads te verbergen middels browser plugins.
Wat maakt PiHole beter dan AdGuard?
Volgens mij is het in z’n totaal wat lichter. Maar AGH heeft native DoH-ondersteuning (aan de voorkant en achterkant)

Het is dus net wat je belangrijk vindt.

Ik gebruik zelf Technitium. Dat is een wat completere DNS-server waar je met gedetailleerd low level zaken in kunt regelen, maar als je dat niet nodig hebt, heb je er niets aan.
Komt in pi-hole ook :) Versie 7 die nog in ontwikkeling is heeft native DoH en DoT.
Heb de nightly docker container al geprobeerd met DoT en dat werkte prima.
Kijk. Dat is goed nieuws.

Eigenlijk is het jammer dat dat er nog niet in zit, maar als ze er mee bezig zijn is dat altijd goed. Eigenlijk is het raar dat iets fundamenteels als DNS niet al lang en breed standaard bij alles versleuteld is in de breedste zin. (Dus geen sneer naar de makers van pihole, maar gewoon in het algemeen)
Pihole zelf misschien niet direct, maar je kunt pihole in container (bijv Proxmox) samen met Unbound installeren.

Je krijgt dan je eigen upstream recursive dns server, zodat je niet de grote upstreams van Google , cloudflare etc gebruikt.
Maar datzelfde trucje kun je met iedere DNS-server doen, dus dat zegt niets over pihole?
Bij PiHole heb je niet het risico dat het een subscription service gaat worden in te toekomst.
Dan ben ik sowieso weg bij Adguard. Hou ik het bij open source.
Waarom niet?

Ieder stuk software kan toch wissen omgebouwd naar een betaald abonnement?
Ik heb pihole draaien op mijn rpi, en probeer de dns in dhcp van mijn Hollandse nieuwe (ziggo) modem in te voeren, maar dat lijkt niet te kunnen, en vanuit pihole krijg ik alleen ipv4, en ipv6 loopt dan alsnog via ziggo, en zijn er nog adds.

Iemand ervaring mee of tips?
IPv6 voor je lokale netwerk uitschakelen? Hier draait het icm Unifi

[Reactie gewijzigd door AvWijk op 18 oktober 2026 10:37]

Ik heb alleen ipv6 nodig voor mijn matter / thread netwerk volgens mij
Ik heb thuis ook matter en gebruik geen ipv6.
Ik had een soortgelijk probleem met de meegeleverde modem van KPN. Uiteindelijk heb ik een Fritzbox aangeschaft want ik kwam gewoon niet verder met de adviezen online. Nu doet de Pihole het prima.
Ik heb idee dat dit soort filtering steeds minder zinvol is. Zowel Android als Apple gebruiken out-of-the-box the default DNS servers die door DHCP worden uitgegeven niet. Werk laptops hebben vaak ook al een vaste DNS. Wat overblijft zijn een restje van "smart" devices.
Bor Coördinator Frontpage Admins / FP Powermod @MarcieMars • 19 oktober 2026 07:37
Steeds meer apparaten gebruiken DNS-over-HTTPS of hebben een eigen DNS-configuratie. Werkapparatuur loopt vaak via een VPN of heeft policies die je thuisnetwerk negeren. Dan blijft inderdaad vooral een verzameling IoT-apparaten, smart-tv's en wat privéapparaten over.

Aan de andere kant zou ik DNS-filtering niet helemaal afschrijven. Voor veel huishoudens blokkeert het nog steeds een hoop advertenties, trackers en bekende malafide domeinen zonder dat je iets op de eindpunten hoeft te installeren.

Als securitymaatregel op zichzelf stelt het niet veel voor. Als extra laagje in een defence-in-depth strategie kan het nog steeds nuttig zijn. Zeker voor die "smart" apparaten waar je vaak helemaal geen agent of beveiligingssoftware op kunt zetten.
Ik zit niet in deze materie, maar hoe verhoudt een Pi-hole zich tot de no-ads versie van DNS4.EU?

Ik snap dat een Pi-hole meer controle, vrijheid en privacy kan bieden, maar is het extra (eigen) beheer de moeite waard t.o.v. de set-and-forget van DNS4EU?
Ik heb bij wijze van test een tijdje PiHole, Adguard, Technitium en PiHole+Unbound gedraaid op dezelfde machine met dezelfde lijsten.

Dit dan weer gebenchmarked met Yet Another DNS Benchmark en GRC DNS Benchmark. De twee Piholes waren altijd het snelste, die met Unbound er bovenop won altijd. Adguard verloor altijd.

Als het je puur om Adblocking gaat: PiHole+Unbound.

Ik gebruik alleen OISD big en hoor zelfs geen klachten van de gamende tiktokkers hier in huis. Toch eens kijken of ik er stiekem eentje bij kan fietsen.
Dus toch best Pihole met unbound?

Ik was een tijdje geleden overgestapt naar Adguard home…
Ik gebruik zelf AdGuard Home en dat bevalt zover even goed. Niet vergeten je upstream DNS in te stellen, dat verhelpt veel vage timeout problemen. Zowel AG Home als Pi-hole draaien op een aardappel

*knip*

[Reactie gewijzigd door Dirk op 18 oktober 2026 11:42]

o wow, thanx a bunch! Ik ga hier even goed voor zitten. Wil niet te veel dubbele adressen blokkeren maar heb altijd het gevoel gehad niet het optimale uit m'n pihole te halen. Unbound gebruik ik wel als DNS server en die combinatie werkt heel mooi al.

Om te kunnen reageren moet je ingelogd zijn