Software-update: Pi-hole Core 6.0.1

Versie 6.0 van Pi-hole Core is eerder deze week uitgekomen en inmiddels is er ook alweer een kleine update 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 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 changelog voor deze uitgave kan hieronder worden gevonden.

Changes in Pi-hole Core 6.0.1

• Fix i386 fallback download in #5903

Changes in Pi-hole Core 6.0.0

• Remove option to set static IP address if DHCPCD is installed in #5111
• Do not remove -all|exact when not surrounded by space in query.sh in #5300
• Add code to remove old lighttpd config files left over from v5. in #5314
• Switch to new branch name for FTL v6 development in #5319
• Set new gravity database version to 16 in #5328
• Add /var/log/pihole/webserver.log to the logrotate scripts in #5329
• If ${USER} variable is blank, then populate it with whoami in #5341
• Remove webpage.sh in #5357
• Remove fake user agent when downloading adlist in #5367
• Ignore ABP style entries in debug log dig test in #5382
• Ensure pihole-FTL can write to all files in /etc/pihole, /run/pihole and /var/log/pihole in #5356
• Add antigravity support to gravity in #5330
• Some verbiage change to outputs (plus a couple of comments) in #5406
• Disable checkout function for (official) docker containers in #5416
• Allow pihole to access subdirs in /etc/pihole in #5427
• Remove Chronometer in #5423
• Set owner of gravity output files to pihole in #5419
• Update query.sh to use FTL's API instead of directly interacting with the database in #5361
• Add a final message to gravity in #5441
• Avoid printing getFTLConfigValue return in statusFunc() in #5442
• Logrotate config file needs to be owned by root in #5444
• Remove temp dir created when downloading FTL in #5429
• BREAKING Drop support for ancient ARMv4 and ARMv5 in #5445
• Fix gravity swapping in #5455
• Fix and simplify binary download in #5451
• Use suffixed temp file in #5457
• Tweak Pi-hole's debug facility for v6 in #5461
• Remove idn2 as punycode conversion is handled by FTL in #5468
• Start counting at postion 1 in #5470
• Check for valid OS via IPv4 and IPv6 in #5305
• When setting a blank password, use webserver.api.password instead of webserver.api.pwhash in #5465
• Tweak help text of pihole setpassword in #5476
• pihole -d: Include pihole.toml only once in #5478
• Move custom.list to /hosts/custom.list in #5488
• Improve v6 debug log and remove leftovers in #5481
• Support special webserver.port ports ending in "s" (secure) and "r" (redirect) in #5499
• Use files.gravity_tmp as temporary directory for the intermediate lists in #5504
• Treat FTL return data as strings in #5509
• Bash completion in #5516
• Remove obsolete sudo file in #5514
• Simplify pihole -v in #5517
• Add "-ni" to all sqlite3 invocations in #5518
• pihole -d: Fix gateway ping if it is a LL address in #5527
• Fix failing tests in development-v6 branch in #5542
• Do not store remote version in versions file if on custom branch in #5549
• Use 204 return code for deleted sessions in #5541
• Drop Fedora 36 and add Fedora 39 to the test suite in #5482
• Test ftl.pi-hole.net availability in #5563
• Make IDs of anti-/gravity lists available in vw_(anti)gravity in #5526
• Remove local.list and openVPN traces in #5480
• Fix gravity in #5573
• Allow adlist duplicates in #5572
• Highlight "### CHANGED" strings in the debug log of pihole.toml in #5601
• Verify remote FTL checksum in #5603
• Fix edge-case where an adlist domain is blocked in #5571
• Improve changed binary message during update process in #5621
• Only use local files (file://) when they have explicit permissions a+r in #5622
• Add Ubuntu 24.04 and Fedora 40, remove Fedora 38 in #5657
• Also check for IPv6 address for configured DNS servers in #5560
• Migrate dnsmasq config files in #5479
• Fix version check for release Docker images in #5667
• Add CAP_SYS_TIME to FTL's ambient capabilities in #5676
• Remove CentOS8 from test suite in #5682
• Add pytest-clarity to test environment to improve error log output in #5692
• Add protocol validation when downloading blocklist from URL in #5698
• Fix minor spelling mistake in #5704
• Finish core v6 implementation in #5689
• Remove obsolet getFTLPIDFile() in #5710
• Remove obsolet files and log file symlink code in #5711
• Merge development > development-v6 in #5725
• [fix] [v6] typo in bash-completion allow-regex option in #5729
• Fix setting query logging and privacy level in #5724
• Add missing creation of table antigravity in migration script 16 to 17 in #5737
• Add pihole api [endpoint] callback suitable for local API requests in #5736
• Make the help text of "pihole checkout [what] [branch]" more colorful in #5734
• Update existing logrotate files to inlcude webserver.log in #5738
• Disable SELINUX on CentOS 9 test dockerfile in #5743
• Fix pihole status on not-ready states in #5747
• Disable SELINUX on CentOS 9 test dockerfile v5 in #5744
• Resolve merge conflicts (again) in #5745
• Remove obsolet Debian 10 in #5707
• Wait after restarting FTL before trying to check version in #5613
• Tweak/gravity dns in #5752
• Fix risk of popd without a pushd in #5701
• Account for renaming of devel branch on web repo in #5753
• Fix wrong message being displayed while waiting for the DNS in #5757
• Add /etc/pihole/dnsmasq.conf to debug log (stripped-down version) in #5740
• Return early during v6 migration if migration dir exists in #5766
• Revert "Return early during v6 migration if migration dir exists" in #5768
• Add fallback option for OS check without hard-coded nameserver in #5751
• Remove lines containing Adguard JavaScript rules from adlists in #5754
• Add database optimization and gravity timing in #5773
• Grouped common dependencies of distros in #5762
• Fix removing old man page in #5789
• Show version information after a web update in #5788
• Remove the restartdns functionality and promote the reloaddns functions in #5780
• Remove restartdns: Redux in #5791
• Add color in #5798
• Use pihole.toml to decide if installer runs on an update in #5790
• Fix gavity version 19 in #5801
• Do not print FTL update check details on pihole -up in #5800
• Exit 1 on failure in #5803
• Improved error message for invalid protocol in adlist download in #5806
• Fix errors on fresh installations while setting privacy levels and query logging due to absence of pihole.toml in #5799
• Add Fedora 41 and remove Fedora 39 from tests in #5813
• Remove remaining traces of audit log in #5817
• Fix possible gravity permissions issue in #5819
• Fix empty adlists in #5821
• Remove Ubuntu 23 tests, it is EOL in #5822
• Fix ARP flush command in #5823
• move the sourcing of utils.sh outside of installPihole in #5825
• Remove no-longer-needed utils in #5826
• Install dependencies by creating a meta package on-the-fly in #5785
• Fix rare case when apt and rpm package managers are found in #5827
• Improve v6 user output in #5829
• Improve dependency package output in #5828
• Fix v5 -> v6 update in #5832
• Speedup api response handling in #5833
• Exit early when neither service nor systemctl commands are available in #5834
• Disable lighttpd if found in #5835
• Remove now unused function test_dpkg_lock() in #5848
• Improve lighttpd disabling in #5849
• Explicitly migrate from v5 to v6 in #5830
• Remove unused code from debug log and skip some tests inside containers in #5854
• Gravity database resilience in #5818
• Use a different method to identify if a gravity restore succeeded in #5868
• Fix counting of domains in the gravity summary in #5881
• Gravity: Use ETags in #5867
• Move gravity list cache into dedicated directory in #5869
• Show only enabled domains/regex in the final gravity message in #5884
• Remove outdated dns-servers.conf in #5883
• Add call to os_check in the update script in #5845
• Decide if the content was changed before passing over to FTL in #5872
• installer: use a drop-in to disable systemd-resolved stub listener in #5885
• Amend warning on gravity tree build failure in #5888
• Fix database integrity check in debug log in #5889
• Pi-hole core v6.0.0 in #5842

Versienummer	6.0.1
Releasestatus	Final
Besturingssystemen	Scripttaal
Website	Pi-hole
Download	https://github.com/pi-hole/pi-hole/releases/tag/v6.0.1
Licentietype	GPL

Reacties (97)

[Moby]

Voor de mensen die Pi-hole draaien in een docker container op een Synology NAS: bij mij is de poort veranderd van :8000 naar :8080

En uiteraard is er op het forum al veel meer info bekend over versie 6 vanaf hier: https://gathering.tweaker...message/81686158#81686158

[Reactie gewijzigd door Moby op 20 februari 2025 21:38]

[r03n_d]

Dat klopt, sinds v6 wordt lighttpd niet meer gebruikt, maar wordt een geïntegreerde webserver gebruikt. Tijdens een CLI upgrade kan je aangeven of je lighttpd (en dus port 8080) wil blijven gebruiken of niet.

Heb zelf pihole in proxmox draaien, dus geen last van "gedoe" zoals hierboven en in andere comments beschreven.

[Reactie gewijzigd door r03n_d op 20 februari 2025 22:49]

[BestevaerNL]

Hoe heb je je PiHole draaien in proxmox? Ik heb ze in een lxc draaien. Maar ik ben nu nog huiverig om up te daten omdat ik bang ben dat er iets kapot gaat.

[Hann1BaL]

De NTP settings gingen stuk na de update in mijn LXC maar daar is een simpel command voor.

Voor de rest geen problemen met de update in mijn container

[BestevaerNL]

Verwijderd. Gereageerd op de verkeerde

[Reactie gewijzigd door BestevaerNL op 21 februari 2025 12:59]

[r03n_d]

In zijn eigen lxc. Maar als je bang bent om wat kapot te maken maak je toch gewoon even een backup voordat je upgrade? 30 seconden werk

[BestevaerNL]

Thnx.

Ik heb ook dagelijkse backups draaien. Maar toch..... Als het niet nodig is, liever niet

[lenwar]

Dat mag toch niet de reden zijn dat de standaardport veranderd? Die interne webserver kan ook op 8080 luisteren.

[Pietervs]

Tijdens een CLI upgrade kan je aangeven of je lighttpd (en dus port 8080) wil blijven gebruiken of niet.
ik heb vanaf de commandline (Raspberry Pi) het commando "pihole -up" gegeven, maar ik kreeg helaas niet de vraag of ik lighttpd wilde blijven gebruiken.
Dus die heb ik na installatie handmatig uitgeschakeld, want ik kon niet meer inloggen na de upgrade.

[r03n_d]

Oh dat is raar. Ik kreeg hem wel, en bij mij draait ie ook onder debian..

[Teejoow]

Same here. Nietsvermoedend een upgrade gedaan en vervolgens een uur lopen zoeken voordat ik de webui weer gaande had. Gaat ie lekker op poort 80 draaien. Nee briljant plan...

Maar goed eindresultaat is wel een externe dependency minder dus winst!

Oh en mn custom DNS settings waren weg. Bepaald geen vlekkeloze upgrade dus.

[Reactie gewijzigd door Teejoow op 23 februari 2025 08:11]

[arjan1995]

Bij mijn docker setup werkte de dns niet meer (ik heb een dagelijks auto-update script, dus gisterochtend was ik ineens verrast met v6)

Er moest een extra environment variabele bij:

FTLCONF_dns_listeningMode: 'all'

Ook is de password variabele gewijzigd, deze is nu:

FTLCONF_webserver_api_password: 'SuperGeheimHaha'

Verder werkt alles nog prima.

[GieltjE]

Er zijn nog veel meer variabelen geupdate, het is de moeite waard deze even door te lopen: https://docs.pi-hole.net/docker/upgrading/v5-v6/

[MuizUnattended]

- FTLCONF_webserver_port=8383 Of welke jij maar wil.

[AS_Spaargaren]

Mijn bevindingen (403 Forbidden en geen DNS na update) zijn:
- Interface settings: staat terug op Allow only local requests (dus onbereikbaar vanuit een ander VLAN)
- Gui is verplaatst van http://<ip>/admin naar https://<ip>/admin
- Het wachtwoord van de Gui is aangepast
- Upstream DNS servers is leeg.
- Unbound op 127.0.0.1#5335 en ::1%5335 werkt niet.
- 06-activedirectory.conf in de dnsmasq folder werkt nog wel.

Dit wetende wacht ik ditmaal nog even met het updaten van de productie omgeving.
(restore van productie gedaan en test-opstelling gemaakt nadat het in productie dus mis ging)

[WigaDan]

Unbound op 127.0.0.1#5335 kun je toevoegen en dan moet het weer werken. Ik heb dit zojuist zelf net geconstateerd op twee piholes.

[AS_Spaargaren]

Helaas is unbound na de pihole update toch echt stuk:

> tweakers.net
;; Got SERVFAIL reply from 127.0.0.1
Server: 127.0.0.1
Address: 127.0.0.1#5335

** server can't find tweakers.net: SERVFAIL

[Llopigat]

Net geupgrade maar ik zie in de settings nergens instellingen voor de HTTPS certificaten voor de admin interface. Vreemd. Sowieso hoop ik dat het automatisch aanvragen van de certificaten ook DNS-01 ondersteunt, anders heb ik er niks aan (er staat niks naar buiten open hier uiteraard).

Ook moest ik de bookmark veranderen van /admin/index.php naar /admin/login . Waarschijnlijk vanwege de nieuwe ingebouwde webserver.

Verder lijkt alles goed te werken.

[Reactie gewijzigd door Llopigat op 20 februari 2025 22:40]

[rbr320]

Net geupgrade maar ik zie in de settings nergens instellingen voor de HTTPS certificaten voor de admin interface.

Ze hebben het inderdaad goed verstopt. Om te beginnen moet je op een van de pagina's onder Settings de switch in de rechterbovenhoek omzetten van Basic naar Expert. Daarna moet je naar de onderste pagina onder Settings genaamd All settings. Daar vind je op het tabblad Webserver and API de instelling webserver.tls.cert, waar je het pad naar het PEM bestand met daarin een certificaat en de bijbehorende private key kan wijzigen.

Sowieso hoop ik dat het automatisch aanvragen van de certificaten ook DNS-01 ondersteunt, anders heb ik er niks aan.

Dan heb je verkeerd begrepen wat deze mogelijkheid van Pi-Hole precies inhoudt. Je kunt slechts het pad naar een PEM file met daarin een certificaat+key wijzigen naar een file die je zelf op het systeem hebt gezet waar Pi-Hole op draait. Het standaard pad is een door Pi-Hole 6 zelf gegenereerd certificaat, dat opnieuw gegeneerd wordt op het moment dat Pi-Hole start en het bestand niet bestaat. Als je automatisch certificaten wilt aanvragen, bijvoorbeeld bij Let's Encrypt, zal je dit zelf moeten inregelen met behulp van certbot of acme.sh.

[Llopigat]

Oh er stond dat hij automatisch certificaten aanvraagt. Ik nam aan dat met Let's Encrypt ging. Aan self-signed heb ik niet zoveel. Jammer.

Maargoed zo vaak zit ik niet in die admin interface.

[rbr320]

Waar heb je dat gelezen dan? Ik kom het nergens tegen. Ik zie alleen in de blog post over de release van versie 6 staan dat je zelf een certificaat kunt aanleveren.

5. HTTPS Support

Pi-hole v6 includes native HTTPS support, with options to provide your own certificates or use auto-generated ones.

Met acme.sh kan je eenvoudig Let's Encrypt certificaten aanvragen vanaf het systeem waar je Pi-Hole op draait via een DNS-01 challenge en dan in de configuratie naar dat certificaat wijzen. Volgens mij is dat precies wat je wilt.

[Reactie gewijzigd door rbr320 op 21 februari 2025 00:42]

[Llopigat]

Ja klopt ik heb het verkeerd begrepen. In die blogpost staat "auto-generated" en ik dacht dat die gegenereerd werden door Letsencrypt.

En ja de diverse tools ken ik. Maar het is best een gedoe om het aan de praat te krijgen. Ik heb het in Traefik en Caddy aan de praat op andere systemen maar DNS-01 is altijd een drama. Je moet vaak de hele boel hercompileren met extra plugins en elke provider heeft weer zijn eigen rariteiten met DNS-01.

[rbr320]

acme.sh heeft ondersteuning voor de DNS API's van enorm veel registrars en DNS providers. Als de jouwe er tussen staat kan het echt niet moeilijk zijn om certificaten aan te vragen via DNS-01. Ik heb in ieder geval positieve ervaringen met acme.sh. Het is ook de ACME client die in Proxmox is ingebouwd.

[luke22]

Let op met de home assistant integratie van pi-hole , die gaat kapot van de update

[Verwijderd]

Home Assistant, Domoticz, Munin, LibreNMS, NGINX ....

In principe is alles om zeep als je upgrade naar 6.0 en via externe meuk graphs/stats wilt bijhouden.

In mijn ogen is Pi-Hole 6.x junk ... hier inmiddels op de planning staan om te gaan downgraden aangezien het toch wel aanzienlijk beter (duidelijker) werkte dan voor versie 6.0. Ik heb trouwens ook niet echt grote verbeterpunten gevonden.

[Reactie gewijzigd door Verwijderd op 20 februari 2025 22:52]

[rbr320]

Overdrijven is ook een vak. Dit heeft niets te maken met het zijn van "junk software". Voor versie 6 van Pi-Hole is de volledige API herschreven. De oude API was zeer beperkt en eigenlijk veel meer de noemer "junk" waardig, de Pi-Hole v6 API is een volwaardige API.

Pi-Hole 6 is meerdere jaren in alle openheid in ontwikkeling geweest. De makers van alle genoemde software waarmee Pi-Hole integreert hebben dus ruim de tijd gehad om hun code om te schrijven om van de nieuwe API gebruik te maken, maar hebben dat niet gedaan. Sorry, maar dan is het niet Pi-Hole wat "junk" is.

[Verwijderd]

Overdrijven is ook een vak.

Het gaat mij om het geheel, het geen ik aanhaalde is maar een klein deel van hoe ik het ervaar.

Dit heeft niets te maken met het zijn van "junk software".

Junk is in mijn ogen software die veel te veel bevat, die DHCP server was eigenlijk al onnodig aangezien menigeen gewoon gebruik maakt van de DHCP van die van het modem, router, PFSense, OPNSense etc.

Nu met de komst van een timeserver, begint het gewoon op routersoftware te lijken hoewel de router (NAT) functionaliteit alleen nog ontbreekt. Voor al die meuk kan je net zo goed meteen PFSense of OPNSense installeren.

Pi-Hole 6 is meerdere jaren in alle openheid in ontwikkeling geweest.

Moet je nagaan, meerdere jaren ontwikkelen en dan nog DoH en DoT die ontbreekt maar wel een timeserver erin bakken. Daarom draaide veel mensen het ook juist onder NGINX, zodat ze zelf konden zorgdragen voor die ondersteuning.

Of te wel... "Junk".
Maar... 'my opinion'.

[GHorsie]

Niet helemaal mee eens. Ik gebruik die DHCP server juist omdat je dan zeker weet dat alle clients pi-hole gebruiken als DNS.
En mijn ISP-modem ondersteunt geen aanpassing van de DNS server waardoor dit niet daar geconfigureerd kan worden.

Alternatief zou zijn om weer een ander pakket te moeten gebruiken als DHCP server.

[D43m0n]

OpenWRT met daarop AdGuardHome werkt als een tierelier. Voorheen op een Netgear R7800 (ja die was krachtig genoeg daarvoor) achter een Ziggo modem in bridge modus. Tegenwoordig al een paar jaar een fanless x86 mini-pc met OpenWRT en AdGuardHome in gebruik rechtstreeks op de ONT van m’n glasvezelaansluiting. Gemiddeld zo’n 6W in verbruik.

[pennywiser]

Slim aangepakt inderdaad, ik weet dat sommige ISP modems bijna niets aan settings toelaten.

[lenwar]

Grappig dat je dat zo ziet.
Als we het puristisch gaan bekijken heeft een DHCP-server juist niets te zoeken een router. Een router is tenslotte een netwerkverdeler (het routeert verkeer over meerdere netwerken/subnets.)

Het feit dat we het gewend zijn dat een iedere router een DHCP-server heeft, is omdat je anders nog een apparaat/stuk software in huis moet halen om een werkende internetverbinding te krijgen. (Versimpeld gezegd natuurlijk.)

Maar goed. De DHCP-server in een DNS-sinkhole als pi-hole of AdGuard Home is juist een hele logische. Als het product iedere client kent (als in heeft gezien) in het netwerk, dan kun je die data veel makkelijker toepassen voor allerlei zaken.
Met een externe DHCP-server is er een afhankelijkheid naar reverse lookups e.d. Wat weer lastiger kan zijn als iemand thuis z’n netwerk heeft gesegmenteerd. (Niet onmogelijk, maar lastiger).

Die NTP-server snap ik om eerlijk te zijn ook niet echt.

N.B. Als je geïnteresseerd bent in DoH/DoT, dan kun je denk ik het beste overstappen naar AdGuard Home. Die heeft native ondersteuning voor DoH/DoT. (Zowel van binnen als van buiten. Zo kun je dus ook DoH binnen je LAN gebruiken).

[pennywiser]

Er zit toch ook geen NTP in Pihole, hooguit als dependency mee geïnstalleerd, maar zelfs dat niet volgens mij. En daarbij, dit is wel zo'n minimaal iets wat je ook echt nodig hebt.

DOT/DOH zijn nmm zeer ongewenste technieken, bv Tiktok is niet meer te blokkeren, die heeft namelijk zijn eigen DOH. Waarom zou je dit lokaal beschikbaar willen hebben dan? Oprechte vraag.

[Reactie gewijzigd door pennywiser op 21 februari 2025 10:35]

[lenwar]

Ik zou niet weten waarom TikTok niet te blokkeren is?
AGH heeft het als standaardfunctie om bepaalde services te blokkeren. (er zijn een 60-70 services (die orde van grote) die je met 'schuifjes' kunt blokkeren/deblokkeren, waaronder TikTok en andere (a)sociale media, gaming diensten, enz.)

Of bedoel je dat TikTok z'n eigen DNS-instellingen gebruikt en daarmee (dus?) DoH.

Waarom zou je dit lokaal beschikbaar willen hebben dan? Oprechte vraag.

Ik ben van mening dat al het verkeer dat een apparaat verlaat versleuteld zou moeten zijn, of nog beter. Al het verkeer dat een applicatie verlaat zou versleuteld moeten zijn (ofwel eind-tot-eind versleuteling (van DoH-client naar DoH-server). Het besturingssysteem of andere componenten hebben dan geen invloed meer op het DNS-verzoek, net zoals dat het besturingssysteem ook geen invloed heeft op https-verkeer. Het wordt versleuteld in de browser en pas ontsleuteld in de webserver.

Moderne browsers kunnen bijvoorbeeld tegenwoordig zelf ook DoH 'praten'. Dit betekent dus dat de rest van het besturingssysteem de DNS-verzoeken niet kan zien/manipuleren. Dus stel dat je een stuk malware op je computer of op je router (of nog een ander netwerkcomponent) hebt draaien, dan kan die je DNS-verzoek dan dus niet langer kan manipuleren/inzien, wat met onversleutelde DNS wel kan.
Je kunt natuurlijk denken van "Het is mijn afgeschermde netwerk, en ik verklaar mijn netwerk 'veilig' is", maar ik ben van mening dat ik mijn eigen netwerk helemaal niet als 'veilig' bestempel. Ik ga ervan uit dat er in mijn eigen netwerk ook dingen mis kunnen zijn. Al is het maar omdat ik meerdere componenten in mijn netwerk heb, waar ik geen invloed op heb. (Allerlei slimme apparaten e.d.)

Maar een wedervraag:
Waarom zou je 'niet' DNS-verkeer in je eigen netwerk willen versleutelen? Het is niet zo dat het in de weg zit ergens voor?

[pennywiser]

Maar werkt die AGH block functie ook goed dan? En hoe dan precies? Want zodra de Tiktok app geen verbinding heeft gooit ie zijn eigen hardcoded in-app DOH open. Blokkeer dat meer eens. Lastig, want poort 443. Misschien met een WAF met regelmatig bijgewerkte rules/definities dat het wel lukt, maar volgens mij is het inmiddels niet meer mogelijk Tiktok lokaal op DNS niveau te blokkeren. Als het wel kan is deze vader zeer geïnteresseerd.

https://www.reddit.com/r/..._tiktok_use_dnsoverhttps/

Dit is al wat ouder, dus mogelijk is alweer nog lastiger te blokkeren.

https://www.reddit.com/r/...cant_be_blocked_with_dns/

Wat betrreft DNS encrypted, zeker wil je dat, maar dan wel native, idealiter niet gebruik makende van een heel ander protocol (https).

Verder complimenten voor je altijd technisch zeer onderbouwde reacties.

[Reactie gewijzigd door pennywiser op 21 februari 2025 11:22]

[lenwar]

Ik gebruik zelf geen TikTok, maar als ik in mijn browser tiktok open dan gebeurt er niks. Die schuifjes zijn effectief 'shortcuts' naar een hele vracht DNS-entries. (veel van die zaken hebben allerlei cloud-services en daarmee dus heel veel verschillende domeinnamen enzo. Die schuifjes voorkomen dus dat je 30 entries moet invullen om bijvoorbeeld alles van Facebook te blokkeren of zo. (ik noem maar wat) Maar ook om makkelijk 'tijdelijk' YouTube/Netflix te blokkeren voor de kinderen na 21:00 )

Volgens dat Reddit artikel gebruikt TikTok dus de Google DNS-servers met DoH, wat op zich geen rare gedachte is. Je zou in een firewall overigens 'al het verkeer' naar de Google DNS-servers kunnen blokkeren, tenzij je die zelf als upstream gebruikt natuurlijk. Dan zou je zelf die kunnen openzetten voor de DNS-sinkhole, of een andere upstream gebruiken.)

Maar goed. Als TikTok zelf een DNS-verzoek doet (wat los staat van DoH of niet) op basis van wat anders dan je in je netwerk wilt, dan wordt het lastig. De port heeft er niet zo veel mee te maken. TikTok kan ook een onversleuteld DNS-verzoek doen op dns.tiktok.nl op port 80. Die blokkeer je ook niet makkelijk .

DoH is 'native' versleuteld. Https is een bewezen protocol. Het is stabiel en efficiënt. Maar "https is niet hetzelfde als port 443"

Ik denk dat je doelt op dat je 'moeilijk' DoH kunt omleiden op je router. Ik zie tegenwoordig veel mensen die port 53 richting internet omleiden naar hun eigen pi-hole/AGH/Blocky-server, zodat het altijd langs de adblocking gaan.
Dat 'trucje' is in de praktijk een heel makkelijk en doeltreffende methode dat voor elkaar te krijgen. (ik doe het zelf ook. ). Dit trucje werkt (logischerwijs) niet met poort 443. (in de praktijk)

Veel DoH-servers maken 'juist' gebruik van port 443 omdat het bijna nergens geblokkeerd is. Dus puur om te zorgen dat het toegankelijk is. Er zijn echter ook DoH servers die port 3000 draaien. (veelal zodat de DoH-service als niet-beheergebruiker kan draaien, zonder andere trucjes).

Verder complimenten voor je altijd technisch zeer onderbouwde reacties.

Bedankt! Wordt zeer op prijs gesteld!!


N.B. Ik heb naar aanleiding van je opmerking over TikTok even de app geïnstalleerd en zie wat interessants:
Hij doet nu z'n DoH-verzoeken naar: pitaya-ttp2.tiktokv.eu.ttdns3.com, dus de Google DNS-server blokkeren gaat niet voldoende zijn. De ttdnsX.com-adressen zitten op dit moment blijkbaar niet in de blocklist van AGH voor TikTok. (dus die heb ik maar even als regex toegevoegd aan AGH )

[pennywiser]

Ik snap inderdaad wat je uiteenzet. Maar in het kort waar het op neer komt bij Tiktok is dat ze actief zoeken naar steeds nieuwe manieren om lokale blokkades tegen te gaan. Die Google DNS deden ze inderdaad 5 jaar geleden, ik denk dat ze allang weer wat trickiers bedacht hebben, en volgend jaar weer wat anders. Mogelijk rouleren ze dagelijks DoH URLs. Ze misbruiken daarmee allerlei protocollen die daar niet voor bedoeld zijn imo.

Thanks voor de URL, ik gooi hem er eens in (Pihole v6), kijken hoe lang het werkt. Hoe check jij trouwens dat verkeer wat je ziet?

[lenwar]

Ik heb zelf deze regex in AGH gezet:

/.*\.ttdns([0-9].*)?\.com/

Niet heel netjes, maar hij lijkt z’n ding te doen, en de kans op valspositieve lijkt me klein. 😊

DoH-servers hebben (mits ze zich aan de standaard houden) een hostname. Al is het maar omdat je een certificaat nodig hebt.
Ik heb dus gekeken welke DNS-verzoeken er langs kwamen in m’n AGH. Toen ik die zag was het verder eigenlijk op ‘verstand’ (ttdns - tiktokdns).

Als TikTok echter hostnames als blabla.microsoft.com gaat gebruiken wordt dat moeilijker. 😊(dus als ze hun DoH in een publieke externe cloud gaan hosten).

Ik heb er ook wel een mening over hoor, dat ze het heel moeilijk maken om ze te laten blokkeren.
Ik snap dat ze hun advertentienetwerk altijd actief willen hebben, maar het is wel zo netjes dat je meewerkt om je te laten blokkeren, zoals bijvoorbeeld menig pornosite die in de HTTP-headers vlaggetjes meesturen dat ze porno zijn.

Misschien moet Europa daar iets mee. Dus dat een webdienst zich blokkeerbaar moet maken.

[pennywiser]

Thanks. Ik heb je regexje gelijk even geleend. Ben heeel benieuwd hoe lang het duurt voor er hier mensen gaan piepen. Zeg maar de ultieme check of het ook echt werkt

[lenwar]

Het alombekende knijp-en-piep-systeem

Edit: Als hij voor jou niet werkt, moet je het even zeggen. Mogelijk dat AGH en pi-hole beide andere regex-engines gebruiken. (al zou deze regex volgens mij wel generiek moeten zijn.)

[Reactie gewijzigd door lenwar op 21 februari 2025 13:42]

[pennywiser]

Zal ik doen, de uitkomst kan niet lang op zich laten wachten.

[pennywiser]

@lenwar Er kan nog gewoon getiktokt worden. Ik om het domein ook niet tegen in top blocked domains. Ik zal eens de logging nalopen, heb deze weer aangezet, hij stond op full privacy mode bij mij.

[lenwar]

Raakt hij die regex wel? (want bij mij werkte hij wel)
Kijk anders of je iets van een relatie kan vinden in de tiktok-domeinen.

Dus dat je iets van .*tiktok.*\..* blokkeert.

[pennywiser]

Is de app dan ook onbruikbaar bij jou?

[lenwar]

Ja, bij mij deed hij niet.
Ik heb het 'TikTok schuifje' bij AGH uit staan in combinatie met die ttdns-string.
Ik zag overigens nog wel een paar andere domeinen voorbij komen die nog tiktokkig waren hoor, maar de app deed het in elk geval niet meer. Dus dat schuifje is niet 'compleet' op het moment.

[smv]

Jou eisen liggen dus niet bij Pi-Hole ;-)

[Verwijderd]

Jou eisen liggen dus niet bij Pi-Hole ;-)

v6.x Niet echt nee.
v5.x Juist wel, en een downgrade doet gelukkig wonderen. Scheelt ook - hoe minimaal ook - meteen wat extra resources vanwege de webserver die ze nu lijken af te dwingen.

[lenwar]

Maar was de nieuwe API dan al eerder beschikbaar? Het is veelal good practice om de de API’s (tijdelijk) naast elkaar te laten bestaan (v1 / v2) en de oude uit te faseren na een deprecation-periode.

Een product als pi-hole moet natuurlijk ook z’n plek kennen. Het is ‘maar’ een DNS-sinkhole, en er zijn een paar volwaardige alternatieven in de vorm van AdGuard Home en Blocky. (Al moet je voor die laatste zelf een webinterface regelen, maar de API’s laten dat prima toe.)

Ik wil zeker niet zeggen dat het geen goed product is natuurlijk! Het doet wat het zegt te doen, en het doet het goed.
Maar zo’n grote wijziging doen, zonder een overgangsperiode is wel een beetje summier.

N.B. de opmerking ‘junk’ van @Verwijderd vind ik dan ook erg vreemd.

Edit: ik lees net diens opmerking over hen bedoelt met Junk. Dat maakt het wel wat duidelijker. 😊

[Reactie gewijzigd door lenwar op 21 februari 2025 08:19]

[rbr320]

Maar was de nieuwe API dan al eerder beschikbaar?

De nieuwe API was bij mijn weten tijdens de gehele ontwikkelperiode in alpha en beta beschikbaar. Al in oktober 2023 stond er een bericht op Tweakers dat er beta-testers werden gezocht voor Pi-hole 6, dat is bijna anderhalf jaar geleden. De wijziging heeft dus zeker niet van de ene op de andere dag plaatsgevonden.

[GeleKoplamp]

Domoticz idem dito

[Ruuddie]

Ik ben eigenlijk overgestapt op Adguard Home omdat ik deze mooier eruit vond zien (ja oppervlakkig hahah) maar ben prima tevreden. Iemand ervaring met allebei en pros en cons?

[prutser001]

Waar ik voornamelijk last van had in het verleden was dat de SD kaartjes->later USB sticks sneuvelde met Pi-Hole, dit gebeurde meestal na een update/herstart/stroom uitval.. Nee ik gebruikte niet goedkope meuk Samsung/SanDisk en dan de duurdere/snellere modellen. Kan gewoon pech zijn maar was het zat dat ineens hele netwerk plat lag, ook VPN want die liep ook via PiHole, eerst OpenVPN en nu Wireguard.

Ben nu ook al een tijdje overgestapt naar Adguard home maar dan op een Linux bak met nog veel meer dingen erop. Nu gecombineerd met Pfsense-Wireguard waar Adguard als DNS staat en dat werkt prima.

Heb PiHole al sinds Pi1 draaiende gehad tot de Pi3 ondanks dat het op een USB stikje stond ook ellende. Later Adguard en dat heeft zonder omkijken gewerkt en de Pi nu aan de kant gelegd en gewoon een Linux bak gemaakt met wat ik wilde.

[Webgnome]

Ben nu ook al een tijdje overgestapt naar Adguard home maar dan op een Linux bak met nog veel meer dingen erop.

Dus je hebt het eerst over dat je last hebt van sd kaartjes die stuk gingen etc en dan ga je vervolgens naar een linux bak (zonder sd card ga ik van uit). Dat is toch iets zeggen dat je altijd spruitjes smerig hebt gevonden maar nu je friet eet daar geen last meer van hebt?

[pennywiser]

Sinds ik Endurance SD kaartjes gebruik heb ik nooit meer een corrupte SD kaart gehad. Rpi 5 met ook VPN, Pihole, Domoticz, SSLH en weet ik wat er op. Sandisk MAX Endurance (je hebt ook HIGH Endurance ook goed, maar die moet je niet hebben). Samsung heeft ze ook.

[lenwar]

Technisch gezien is pi-hole een aangepaste dnsmasq server, een complete PHP-installatie en nog wat andere componenten en dat aan elkaar gescript.
AGH is een vanaf de grond af opgebouwd als DNS-sinkhole.

Maar goed. Dat is techniek.

Het grootste verschil is dat AGH ingebouwde ondersteuning heeft voor DoH en DoT. Je kunt zowel binnen je netwerk als richting het internet versleutelde DNS-verzoeken regelen.

Edit: vanaf V6 is er geen php-installatie meer nodig.
@pennywiser bedankt voor de correctie!

[Reactie gewijzigd door lenwar op 21 februari 2025 10:16]

[pennywiser]

Lighttpd en PHP zijn er nu in v6 onder weg gesloopt dacht ik. Ik weet even niet hoe de admin site nu opgebouwd is.

[Toet3r]

Web gedeelte wordt nu met lua gedaan.

[Magic Power]

Het leuke van PiHole is dat het naast reclame filteren ook andere zaken kan filteren. Zo filter ik er naast Advertising Sites ook Suspicious Sites, Malicious Sites en Tracking And Telemetry Sites. Allemaal van online lijsten die nog steeds bijgehouden en ge-update worden.

[DaRk PoIsOn]

Klopt, ik heb een hele rits van die lijsten er in staan, ik block in totaal 2,9m domains op dit moment en dan gaat mijn DNS eerst nog door AdGuard Home die ook nog een lading tegenhoud.

[xhal3]

Ik heb sinds kort ook TLD's toegevoegd

https://www.spamhaus.org/...tatistics/cctlds/domains/
https://unit42.paloaltone...level-domains-cybercrime/

Middels regex deny, tot heden nog geen "last" van gehad, maar wel een veiliger gevoel.

[Anoniem: 1004743]

Een drama deze update, Helaas.
Ik ben een Pi-hole gebruiker van het eerste uur.
Maar deze update heeft veel gesloopt.
De server heeft geen access meer tot het internet.
Slechte zaak dat deze update Ubuntu omzeep kan helpen.
Het was een goed progamma zolang het duurde.

[Llopigat]

Ik zou het sowieso altijd in docker draaien. Makkelijker te updaten en het doet nooit wat raars op je systeem. Zo draait de mijne ook.

[oef!]

Of op een raspberry pi natuurlijk, het ding ligt hier gewoon headless in de meterkast aan een switch. Zo kan ik mijn server rebooten zonder de rest te beïnvloeden.

[Llopigat]

Ja dat kan ook idd. Ik heb toch al een zwaardere server en enkele VPS'en draaien dus dan is een raspberry alleen extra beheer.

[Fishbeast]

dat is zeker een goed alternatief! Ik moet alijd even goed timen als ik m'n server wil herstarten, om te voorkomen dat de rest in het huishouden last heeft van een dns-server die niet bereikbaar is

[Pietervs]

Daarom draai ik 2 DNS servers: Pihole als primaire, en AdGuard als secondaire (als onderdeel van HomeAssistant ).
Wil ik wat omzetten of verbouwen op mijn Raspberry Pi waar Pihole op draait, zet ik eerst de DNS om naar de andere en doe ik even een refresh.

[Freee!!]

Ik draai vier Pi-Holes als DNS-servers, allemaal in Docker containers verdeeld over twee RPi's. Op elke RPi één, die automatisch bijgewerkt wordt, en één die op een vaste versie staat totdat ik die handmatig bijwerk. Nooit problemen met onbereikbare DNS-servers.

[Fishbeast]

jups. Ik heb ook alles in containers draaien; scheelt zoveel gedoe rondom OS-integratie.
OS upgrades zijn hiermee ook (zga) zonder impact te doen.

[Yzord]

[code]2025-02-21 07:25:13.950 WARNING API: Bad request (The API is hosted at pi.hole/api, not pi.hole/admin/api)[/code]

Ik heb ineens deze warning in mijn log staan. Iemand enig idee waar ik dit aan kan passen?

En werd v6 niet een betaalde versie?

[lenwar]

In pi-hole 6 hebben ze de API compleet omgegooid (zonder overgangsperiode blijkbaar). Dus er probeert iets naar de oude API te praten.

Althans. Zo lijkt het.

[Yzord]

Ben er al achter dat het Home Assistent is. En degene die de integratie heeft gemaakt is niet te bereiken ofzo. Lost zich vanzelf wel op hoop ik.

[lenwar]

Het had wel zo chique geweest als de makers van pihole de oude en de nieuwe API tijdelijk naast elkaar beschikbaar hadden gehouden zodat derden fatsoenlijk de tijd hadden om over te stappen.

Dit is overigens een van de redenen dat HA nu AGH als addon aanbiedt ipv pi-hole.
AGH gedraagt zich wat professioneler op dit vlak.

[bertware]

pihole 6 is enorm lang in ontwikkeling geweest en best wel wat over gecommuniceerd in het afgelopen jaar. In de Homey plugin heb ik bijvoorbeeld tijdens de zomer al een pull-request gestuurd met ondersteuning voor v6. Op zich wel normaal dat ze de oude API niet langer ondersteunen. De nieuwe API heeft overigens wel enkele endpoints die veel gelijkenis vertonen met de oude, en is niet moeilijk om te implementeren, dus Home assistant en dergelijke zullen ook wel snel een update hebben.

Een update van v5 naar v6 hadden ze misschien wel beter laten bevestigen door de gebruiker, zodat men zich bewust is van de breaking changes en gebruikers de update indien nodig enkele dagen kunnen uitstellen.

[Reactie gewijzigd door bertware op 21 februari 2025 10:26]

[Yzord]

AGH? Vertel

[lenwar]

Adguard Home. Die wordt als Add-on beschikbaar gesteld in de 'Home Assistant Community Add-ons'.

[SVMartin]

Ik heb een pihile draaien (in docker op truenaa, maar dat doet er eigenlijk even niet toe). Ik volg de ontwikkeling een beetje van de zijlijn en het lijkt erop alsof er heel lang aan versie 6 is ontwikkeld en dit echt een major versie is.

En in dat geval is het bij elke software handig om te wachten op de .1 versie, en de tijd te nemen om de documentatie goed te lezen en de upgrade te testen.

Kortom: ik wacht nog wel een paar weken/maanden voordat ik ga knutselen

[rbr320]

Ik ben het op zich met je eens, maar als de Pi-Hole web interface zegt dat er een update beschikbaar is (en daarbij niet verteld welke versie) wil ik nog wel eens blind "pihole -up" op de command line uitvoeren. Tot mijn grote verbazing leidde dat eergisteren zomaar tot een automatische update naar versie 6, die net een paar uur daarvoor live gegaan was.

Overigens is de update prima verlopen, geen centje pijn. Ik heb naderhand nog wel wat configuratie opties gewijzigd, maar niets wereldschokkends. Ik herken me dan ook niet in de problemen die bijvoorbeeld @Anoniem: 1004743 beschrijft.

[Kliko]

Het is best een tijdje rustig geweest met het aantal updates voor pihole. Ik begon te vermoeden dat het project abandoned begon te worden (was mijn gevoel/aanname, zonder verder er iets erover op te zoeken). Maar nu lees ik dat er toch een grote update is waar waarschijnlijk lang aan gewerkt is.

Fijn dat er nog steeds actief gewerkt wordt aan PiHole! Ik gebruik het al jaren met veel plezier!

[Toet3r]

Dat kam omdat ze alle aandacht aan versie 6 hebben besteed
Voor versie 5 kwamen alleen security updates uit. Laatste inderdaad een aantal maanden geleden.

[Reactie gewijzigd door Toet3r op 21 februari 2025 11:05]