Software-update: Pi-hole Core 5.15.4 / Web 5.18.4 / FTL 5.21

Pi-hole logo (75 pix) Versie 5.15.4 van Pi-hole Core is uitgekomen. Ook zijn Pi-hole Web 5.18.4 en Pi-hole FTL 5.21 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.

Pi-hole FTL changes:
  • Extend regex extension ;querytype=...
  • Update embedded dnsmasq to v2.89
    • Fix bug which can break the invariants on the order of a hash chain.
    • Add no-ident option for enhanced privacy (a Pi-hole contributed feature)

Full Changelog: v5.20.1...v5.21

Pi-hole Web changes:
  • db_queries.php: use the same color scheme from Dashboard
  • Fix multiple restarts while importing with Teleporter
  • Use the setupVars.conf option TEMPERATUREUNIT, plus slight rearrangement of settings page

Full Changelog: v5.18.3...v5.18.4

Pi-hole Core changes:
  • Tweak old pihole lighttpd config warning message to better reflect it’s usage
  • Only source versions file if the file exits
  • Only search for “OVERWRITTEN BY PI-HOLE” when checking inside lighttpd.conf

Full Changelog: v5.15.3...v5.15.5

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

Reacties (81)

81
81
61
2
0
5
Wijzig sortering
Ja dit is toch wel een van de services die ik thuis heb draaien waar ik echt veel aan heb. Gewoon 0,0 ads in mijn interweb acties en tegelijkertijd het blokkeren van menige trackingtools.

Als ik een device tref die nog niet deze dns hosts heeft ingesteld, dan pas zie ik wat het daadwerkelijk doet. Wat een rotzooi bestaat er op de pagina’s zeg 😩
Welke adlists gebruik je?
Ik gebruik oisd.nl, die word volgens mij bijgehouden door een mede-tweaker hier. Koop dan gelijk een kop koffie voor 'm :)
Het nadeel van dit soort lijsten, zoals ook benoemd door Wally3k, is (en ik quote hem voor het gemak maar gelijk)
Avoid using mirrored consolidated lists, if possible; it deprives the original list maintainer of visits (meaning they may be less inclined to keep it up to date!)
Ik kan niet weten waar iets vandaan komt, ik ben oisd.nl toen een keer in de comments op tweakers hier tegen gekomen. Ik gebruik die omdat die er goed uitzag en dat er meerdere mensen hier positief er over waren. Daarbij als je bedoeld dat adlist oisd.nl gebaseerd is op Firebog dan blijf ik toch liever oisd.nl gebruiken omdat ik bij die maar een adlist hoef te te voegen aan mijn Pihole en als ik die van Firebog zou gebruiken een hele waslijst.
Die DNS wijziging doe je toch gewoon op je router (DHCP server)? Ik hoop niet dat je het overal handmatig instelt. Voor sommige eigenwijze devices (Google Chromecast bijvoorbeeld) die altijd hun eigen ingestelde DNS gebruiken heb ik een regel in de firewall. Die regel stuurt alle DNS requests die naar buiten gaan door naar mijn AdGuard Home.
Hmm ben wel benieuwd hoe dat precies ingesteld moet worden, naast de Chromecast heeft onze dochter een Kurio tablet. Die gebruikt ook een eigen dns, nog geen idee welke.
Hangt af van je router. Als je een beetje een volwaardige router hebt (dus niet een modemrouter van KPN/Ziggo) dan heb je vaak ook toegang tot de firewall. Daar stel je kort gezegd het volgende in: "Is er een uitgaande request op poort 53 UDP/TCP, en gaat die niet naar mijn eigen DNS server? Stuur hem dan alsnog door naar mijn eigen DNS server.".

Bij bekende routers is dit wel op internet te vinden.
Hangt af van je router. Als je een beetje een volwaardige router hebt (dus niet een modemrouter van KPN/Ziggo) dan heb je vaak ook toegang tot de firewall. Daar stel je kort gezegd het volgende in: "Is er een uitgaande request op poort 53 UDP/TCP, en gaat die niet naar mijn eigen DNS server? Stuur hem dan alsnog door naar mijn eigen DNS server.".
nternet te vinden.
Dan mis je nog dns over https (tcp/udp 443) en dns over tls (tcp/udp 853)
Als je dat gebruikt moet je daar hetzelfde truukje voor doen. Ik gebruik het niet omdat ik mijn eigen DNS resolver (Unbound) heb draaien.
Als je dat gebruikt moet je daar hetzelfde truukje voor doen. Ik gebruik het niet omdat ik mijn eigen DNS resolver (Unbound) heb draaien.
Het gaat niet om wat je zelf hebt draaien, maar om wat jouw clients gebruiken voor dns. Als je zegt dat je alle dns-requests van clients via tcp/udp poort 53 redirect, dan mis je dus het redirecten van alle dns-requests van clients die DoH of DoT gebruiken.
Algemeen:

1. Uitgaand gewoon DNS-verkeer op poort 53 destination-natten naar een gewenste server (in mijn geval naar de router zelf, die het op zijn beurt naar een lokale Pi-Hole doorstuurt).
2. Uitgaand verkeer op poort 853 TCP (DNS over TLS) en UDP (DNS over QUIC en DNS over DTLS) blokkeren.
3. Uitgaand verkeer op poort 443 TCP naar alle IP-addressen van bekende DoH-servers blokkeren (bestaan lijsten voor).
4. Uitzondering toevoegen op het bovenstaande voor verkeer afkomstig van je Pi-Hole.

Vb. RouterOS 7.7
[admin@router] /interface/pppoe-client> print
0 R name="pppoe-out1" max-mtu=auto max-mru=auto mrru=disabled interface=ether1 user="XXXXXXXXXXXXXX" password="XXXXXXXXXXXXXX" profile=default
keepalive-timeout=10 service-name="" ac-name="" add-default-route=yes default-route-distance=1 dial-on-demand=no use-peer-dns=no
allow=pap,chap,mschap1,mschap2
[admin@router] > /ip dns print
servers: [IP van m'n Pi-Hole]
dynamic-servers:
use-doh-server:
[admin@router] > /ip firewall nat print
2 chain=dstnat action=dst-nat to-addresses=[IP van m'n router] to-ports=53 protocol=udp src-address-list=!rpi1 in-interface-list=LAN dst-port=53 log=no
log-prefix=""
[admin@router] > /ip firewall filter print
13 chain=forward action=drop protocol=tcp src-address-list=!rpi1 dst-address-list=DoH servers port=443 log=no log-prefix=""

14 chain=forward action=drop protocol=tcp src-address-list=!rpi1 port=853 log=no log-prefix=""

15 chain=forward action=drop protocol=udp src-address-list=!rpi1 port=853 log=no log-prefix=""
[admin@router] > /ip firewall address-list print
(een lijst "rpi1" met het IP van m'n Pi-Hole)
(een lijst "DoH servers" met een 2000-tal IPs)

[Reactie gewijzigd door EmbarrassedBit op 24 juli 2024 18:36]

Waarom wil je QUIC blokkeren?
Gebruiken van QUIC scheelt zo'n 100ms tot 300ms per connectie..

Zonder QUIC (gaat over UDP) val je terug van HTTP/3 naar HTTP/2, heb je extra handshake verkeer (vertraging+extra network load) en mogelijk minder veilige cipher suites (afhankelijk van de server configuratie).

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

Hij wil toch alleen DoQ (DNS over QUIC) blokkeren en niet QUIC in het algemeen?
Eerlijk gezegd: ik ben geen expert in deze materie en weet niet wat QUIC is. DNS over QUIC op 853/udp lijkt me gewoon weer een zoveelste manier voor toestellen om hun moederschip te contacteren zonder mijn toestemming, vandaar dat ik het blokkeer.
QUIC is de nieuwe manier om een TLS verbinding op te bouwen, dat gaat niet meer over TCP/IP maar over UDP.

Het is onderdeel van HTTP/3 en zorgt dat de traditionele handshake overbodig is.
Plaatje: https://miro.medium.com/v...k5OZPL7gtUwqRLwaoGyFw.png

Ander plaatje:
https://devopedia.org/images/article/309/6504.1611487632.jpg

Zie ook uitleg:
https://devopedia.org/quic

Connecties worden hergebruikt en meerdere files kunnen tegelijk met een request worden opgevraagd en als een stream worden verstuurd. Ook dat scheelt heel veel chatter tussen cliënt en server. En scheelt veel in vertraging, zeker met server hints etc.

Grote bedrijven gebruiken QUIC al een aantal jaar. Ik heb sites die nu onder https in 70ms de homepage serveren en renderen incl. plaatjes o.a. dankzij http/3 QUIC.

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

Bedankt voor die uitleg, heb weer wat bijgeleerd. _/-\o_

QUIC gebruikt voor zover ik begrijp poort 80 en 443 om te verbinden met een website, dus als ik DoQ op poort 853/udp blokkeer voor de verbinden toestellen heb ik nog altijd de voordelen van HTTP/3?

M'n Pi-hole gebruikt zelf trouwens een lokale dnscrypt-proxy client die volgens de release notes sinds versie 2.1.3 verbeterde ondersteuning heeft voor DoQ, en verkeer naar poort 853 vanaf de Raspberry Pi waarop Pi-hole draait wordt niet geblokkeerd door m'n firewall. Tijd misschien om eens te kijken naar een publieke DNS resolver die DoQ ondersteunt... :)
HTTP/3 en QUIC accepteren geen onversleuteld verkeer, dus wordt poort 80 niet gebruikt voor HTTP/3 verkeer.

Sinds mei 2022 is DNS over QUIC de formele opvolger van DNS over TLS.
Vandaar dat je QUIC verbindingen nu ook ziet op je DNS poort.

Hiermee wordt versleuteld DNS verkeer nagenoeg even snel als onversleuteld DNS verkeer.

Zie ook https://www.sidn.nl/nieuw...uw-dns-over-quic-protocol

En voor websites die het DNS HTTPS-record (DNS SVCB-record) goed hebben geconfigureerd is de verbinding dus even snel tot stand gebracht als een onbeveiligde HTTP/1.1 verbinding.
En is de data uitwisseling juist sneller dan de onbeveiligde verbinding.

Dit is ontworpen in 2012 maar heeft dus jaren afstem werkt gekost om eindelijk bij de eindgebruiker aan te komen. Er is veel werk voor verzet, zo is de hele netwerk laag van Windows vervangen en de manier hoe deze applicaties toegang krijgen tot internet is totaal veranderd. Dat was nodig omdat QUIC op een lager niveau ingrijpt dan dat bijvoorbeeld Microsoft Internet Information Server toegang had.

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

Connecties worden hergebruikt en meerdere files kunnen tegelijk met een request worden opgevraagd en als een stream worden verstuurd.
Ik kan het mis hebben, maar dit stukje werd volgens mij ook al door http/2 ondersteund.
Lees het stukje https://www.sidn.nl/nieuw...uw-dns-over-quic-protocol

Het klopt dat http/2 dat doet met het daarvoor ontworpen SPDY (juli 2012), maar QUIC (oktober 2012) dat als aanvulling op SPDY is ontworpen is nodig om dit efficiënt te laten verlopen.

Ze zijn dus altijd al bedoeld om samen te gebruiken, alleen had het acceptatie process van QUIC wat meer tijd nodig.

Google heeft beide al sinds 2013 in gebruik in combinatie met de Chrome browser cliënt. Vandaar hun dominante positie op de advertentie markt, de advertenties laden 200ms tot 600ms sneller dan de snelste concurrenten. Facebook volgde in 2018.

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

Als apparaten/bedrijven per se op ingewikkelde manieren naar huis willen praten door allerlei vage obscure methoden te misbruiken, dan is regulier‘ DoH/DoQ/enz niet de meest praktische manier om dat te doen.

Een paar manieren die ik kan bedenken:
Stel dat het apparaat überhaupt al het internet op moet voor wat voor reden dan ook, dan zetten ze de servers die voor de functies van de apparaten zorgen op dezelfde plek als de ‘naar huis-praten’ dienst (die multiplexen ze dan zelf). Jouw netwerk ziet dan niet het verschil tussen regulier beetje een ‘spionage-verkeer’.

Maar stel dat ze iets met DNS (moeten) doen:
Ze gebruiken hun eigen DNS-dienst op een andere poort. (( nou zou je natuurlijk outbound alle noodzakelijke poorten kunnen whitelisten, maar niet veel mensen doen dat )).
Er is geen reden waarom een Google Chromecast niet naar 2.2.2.2 op poort 174 kan DNS-en, of een https-sessie opzet naar 3.3.3.3 op poort 37560. Succes met je detectie, zeker als hij gaat rouleren op basis van informatie die hij via regulier verkeer ontvangt.

Ze gebruiken een alternatief protocol voor DNS. (Iets zelf-ontworpen)

enz.

Bovenstaande zijn een paar voorbeelden van dingen die ik ter plekke uit m’n duim zuig. Ik durf er om te wedden dat er vele andere nog meer vermufte methoden te bedenken zijn voor organisaties die er echt op uit zijn.
Ongetwijfeld waar. Mijn eerstelijnsverdediging blijft: geen smart rotzooi in huis. Wat ik zelf creëer of implementeer op netsec-vlak is meer om een mooi technologisch artefact te hebben, dan iets waar ik actief of passief op vertrouw dat het een verschil maakt.
Behalve dat certificate pinning daar in de weg zit. Wat dat betreft mag dns over https een stille dood sterven.
Als je dat gebruikt moet je daar hetzelfde truukje voor doen.
Zal niet zomaar lukken:
  • DoH gebruikt zelfde poort als HTTPS. Filteren op poort zal dus niet lukken. Je zou moeten filteren op IP. Dat betekent dat je een lijst moet opbouwen van alle IP adressen die gebruikt kunnen worden voor DoH.
  • Clients zullen het TLS cert controleren van de DoH server. Hoe ga je ervoor zorgen dat jouw DoH server een geldig cert heeft voor alle mogelijke domains? Zelf fake certs dingen zou kunnen maar dan moet je eigen CA very wel vertrouwd worden door de clients. Lijkt mij sterk dat je dat voor elkaar krijgt op clients waarvan je de DNS server niet kan instellen.
443 en 853 kon ik nog niet, maar als ik tcp 443 block heb ik geen internet verbinding meer?
(Op een Fritzbox)

De Adguard server is uitgezonderd van de blokkade.

[Reactie gewijzigd door Meessen op 24 juli 2024 18:36]

443 en 853 kon ik nog niet, maar als ik tcp 443 block heb ik geen internet verbinding meer?
(Op een Fritzbox)
Vooropgesteld dat je wat mij betreft niets hoeft te blokkeren - en dat het internet meer is dan verkeer over 443 - is dns-over-https om die reden inderdaad lastiger mee te dealen dan klassiek dns of dns-over-tls.
ASUS routers met de Merlin firmware hebben dat (in de meest recente versie) onder de naam DNS Director. Je stelt gewoon in voor welk IP-adres de DNS-requests omgeleid moeten worden. :)
Ja dat is wel iets wat me al een tijdje stoorde, dat veel apps op de tablet, telefoon of android tv de dns gewoon negeren en zelf hun ads naar binnen trekken
Ziggo routers kunnen dat toch helemaal niet?
Is dat niet precies wat ik zeg?
sorry my bad. Had de 'niet' niet gezien
Check eens of op dat apparaat niet ook een IPv6 DNS actief is. Ik zag dat op mijn PC zowel de Pihole DNS alsook een IPv6 DNS liep, sommige apparaten pakken bij voorkeur onvermijdelijk de IPv6 server, en ontwijken de Pihole. Ik heb dan aan mijn provider gevraagd die voor mij uit te schakelen.
Kan je IPv6 niet in de router uit zetten?
Dat heb ik gedaan iig nadat ik een hoop problemen had toen kpn het had aangezet (op mijn eigen fritzbox notabene).
Was wellicht in mijn gateway (is een antenne van de provider), die kan ik zelf niet aanpassen, waarschijnlijk heeft mijn provider dat daar dan ook uitgeschakeld.

[Reactie gewijzigd door Honbrifcl op 24 juli 2024 18:36]

Hier is eventueel ook een goede handleiding voor de OpenWRT gebruikers die op versie 22 of hoger zitten waar firewall4 nu op zit.

https://jeff.vtkellers.co...ough-pihole-with-openwrt/

let er wel op dat je in het screenshot van de:
- General settings tcp/udp kiest (en niet any)
- advanced settings dus een ! voor het IPadres van je pihole zet.
daar heb ik dus een week naar zitten zoeken 8)7
Nee, die doe ik niet 'gewoon' in mijn router, want mijn geliefde wilt helaas wel op FB/Insta en al die meuk. Ik stel dus al mijn devices handmatig in.
Wellicht eens Adguard proberen dan? Dat is in principe hetzelfde als een pihole maar met een heel eenvoudige UI om per device services te blokkeren (of om voor bepaalde devices uitzonderingen te maken).

Uiteraard kan pihole dit ook maar is wat lastiger in te stellen. Daarnaast ondersteunt adguard dns-over-https en tls out of the box (bij pihole moet je geloof ik een extension installeren)
Pi-hole heeft daar geen extensie voor, voor zover ik weet. Je kan gewoon je upstream DNS voor Pi-hole instellen op 127.0.0.1#12345 en dan op die poort de DNS client-software die je wil draaien. Nadenken dan over waar in de ketting je eventueel DNS caches wil bijhouden.
Ik had t over dns-over-https of dns-over-tls. Dit is niet mogelijk met een ip adres.
Ik bedoelde dat je lokaal, op een bepaalde poort, DoH, DoT en DNSCrypt client software kan draaien, en de upstream DNS van de Pi-hole kan instellen op zichzelf en die poort.
Ah zo, dacht dat dit niet out of the box werkte. Heb pihole al jaren niet meer gebruikt, maar dit stond overal op internet zo

https://www.reddit.com/r/...&utm_content=share_button

Verder kan ik er geen uitspraken over doen gezien ik er te weinig ervaring mee heb. Maar goed het was dan ook (in tegenstelling wat sommigen misschien denken) niet de bedoeling om de thread the hijacken of om te zeggen dat een alternatief beter is, want beide programmas hebben hun voor en nadelen.
Ah zo, dacht dat dit niet out of the box werkte.
Het werkt ook niet out of the box. Het is een DNS client die je zelf moet installeren op hetzelfde systeem als, of een ander systeem dan, dat waar Pi-hole op draait. Pi-hole zendt dan gewoon onversleutelde DNS-verzoeken zoals ie dat anders naar 1.1.1.1 of 8.8.8.8 of whatever op poort 53 zou doen. Maar dan op poort 12345 naar een DNS client daemon op localhost of elders in je netwerk. Ingeval je localhost gebruikt, maakt het deel uit van het systeem waar Pi-hole op draait, maar niet van het "Pi-hole systeem" binnen dat systeem. Misschien verwarrend omdat wanneer men het over z'n Pi-hole heeft men doorgaans spreekt over het systeem waar de Pi-hole op draait in zijn geheel.

[Reactie gewijzigd door EmbarrassedBit op 24 juli 2024 18:36]

In de pihole admin console kun je ook heel eenvoudig, per list of zelfs per individueel domein (black alsook whitelists), instellen dat die voor bepaalde clients wel, of juist niet mag gelden.

Via Group Management wijs je de clients aan.

Vervolgens kies je per lijst, of black/whilelist, of die voor iedereen, of enkel voor bepaalde groepen moet gelden.

Static IP voor de clients in kwestie is dan wel handig.

Zo kan ik mijn apparaten (mobiel, laptops, desktop) meer lijsten laten gebruiken dan andere huisgenoten.

Eén keer instellen, en nooit meer naar omkijken.
Waarom Adguard aandragen als Pi-Hole dat ook gewoon kan?
Ik geef de redenen toch mee?
Mee eens! Zeer goed advies!
Je kan ook gewoon een exception voor je geliefde maken zodat de meuk wel te zien is. Dan kun je het alsnog 'gewoon' in je router doen.
In Pihole kun je groepen maken en die aan een lijst koppelen.
Met het osid filter blijft alles toch gewoon werken? Die gebruik ik hier met nextdns.
Je kunt in pihole gewoon groepen instellen. Bepaalde clients gaan dan wel langs het filter en andere niet. Zo hoef je maar één dns server te gebruiken voor iedereen.
Als ik de DNS in mijn router instel, dan geeft Pihole bij elke request weer dat het van mijn router afkomstig is. Ik kan dan niet meer achterhalen welk device daadwerkelijk de DNS request deed. Ik wil dat kunnen zien om bepaalde requests bij de bron te kunnen elimineren (door bijv. software te uninstallen).
Ik vermoed dat je Pihole niet hebt ingegeven bij de DHCP server instellingen en dat je toestellen momenteel hun DNS queries naar de router sturen en dat de router ze doorstuurt naar je Pihole.

Wanneer je het bij de DHCP server instellingen zet dan zal je op je pc het IP adres van je Pihole als DNS server zien staan en gaan alle queries wel rechtstreeks naar de Pihole (en kan je dit wel opvolgen in de logs). Als je nu op je PC kijkt naar de DNS server(s) zie je waarschijnlijk het adres van de router (gateway).
Ach natuurlijk. Niet bij stilgestaan dat ik alle devices een statisch IP gegeven heb. Dan moet je wel het directe IP van je PiHole opgeven.

Als mijn router een grotere DHCP tabel ondersteunde (>64), dan zou ik DHCP misschien overwegen.
Je kan de pihole ook als DHCP laten fungeren. Kun je zelf je subnet instellen.
Youtube reclames krijg je alleen niet er tussen uit me Pilhole.
Wel in combinatie met Brave. Ik kijk YT op 4K zonder reclame in Brave met Pi-hole
In Brave zit een gebouwde adblocker dus het is daar de adblocker die het tegen houd niet Pihole, want met Firefox heb ik er ook geen last van met Ublock Origin.
Surfen op het internet zonder een ad-blocker is echt een wereld van verschil. Hoe sommigen dat uithouden is me echt een raadsel.
Weet iemand of je de ad´s in youtube kan blokkeren met pi-hole. Ik heb dit een tijd geleden geprobeerd, maar na ettelijke pogingen opgegeven.
uBlock origin doet dat perfect op PC
nee, dat kan pihole niet.
Advertenties op Youtube worden namelijk geleverd vanaf het zelfde ip als de video's
Kleine correctie: ze komen van hetzelfde domein. De essentie van pihole is juist om domeinen om te leiden. Als de ads via verschillende domeinen maar hetzelfde IPadres zouden komen zou pihole de reclames alsnog kunnen tegenhouden.
YouTube adds kunnen niet geblokkeerd worden met pihole. Pihole werkt op dns basis.
YouTube stuurt filmpjes en adds via hetzelfde domein. Adds blokkeren op dns basis betekent dan ook geen filmpjes meer.
Adblock op de browser.
Ja, maar dat wordt lastig op een smarttv.
Tijd voor een andere app dan?

Ik gebruik zelf mijn tv als monitor en doe alles met een Apple TV. Ik heb als YouTube cliënt ‘Yattee’, wat effectief een Invidious-cliënt is.
Verre van ideaal/mooi maar geen reclames en een ingebouwde SponsorBlock.
Jaanee.. ;)

Elke oplossing die je tegenkomt om ads via pihole te blokkeren zal ook goede urls gaan blokkeren en daarnaast zal je nooit elke advertentie blokkeren. Helaas dus, effectief blokkeren lijkt gewoon voorbij te zijn. Daarvoor zijn alternatieven beter zoals blokkeren in de browser.
FTL change: Extend regex extension ;querytype=... - forum hier, github hier

Microsoft Edge veroorzaakt (een van de meer recente updates, zie hier - géén reacties) een groot aantal SVCB queries.

ik gebruik momenteel deze blacklist regex:
.*;querytype=ANY,HTTPS,SVCB;reply=nodata
omdat "whitelist always wins" worden, ondanks bovenstaande regex blacklist, ANY, HTTPS en SVCB queries toch toegelaten voor een domain met een whitelist entry. Om dit te voorkomen, waarschijnlijk alleen voor specifieke domains, kan je volgende whitelist regex gebruiken (voorbeeld voor specifiek domain):
www.sevenforums.com;querytype=!ANY,HTTPS,SVCB
De combinatie van deze regexes zorgt er voor dat de blacklist regex toch werkt voor het domain dat gewhitelist is. Alleen aan te raden voor domains waar je absoluut wil vermijden dat er (query)data beschikbaar zou zijn, die gebruikt kan worden voor alternatieve access tot een service.

[Reactie gewijzigd door jpgview op 24 juli 2024 18:36]

Meer informatie over DNS over HTTPS en SVCB:
https://www.domaintools.c...d-https-dns-record-types/

Het SVCB DNS record kan dus voordat er connectie is gemaakt met de server al aangeven dat HTTP/3 ondersteunt wordt. Dat kan zorgen voor een snellere handshake.
Ook kan het fungeren als een soort 'alias' voor de TLD.

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

Het SVCB DNS record kan dus voordat er connectie is gemaakt met de server al aangeven dat HTTP/3 ondersteunt wordt. Dat kan zorgen voor een snellere handshake.
Waarschijnlijk zal ik in de toekomst mijn regexes moeten herbekijken, vandaag is het echter zo dat ik, wanneer ik Edge gebruik, HTTPS queries (pi-hole dashboard -> 12%) zie. Wanneer ik Firefox gebruik, zie ik géén HTTPS queries. SVCB queries zie ik voorlopig niet, tenzij ze doelbewust gedaan worden (zie topic hier).
https://simpledns.plus/help/https-records

De HTTPS queries lijken bedoeld om je internet beleving en een aantal handshake requests te verminderen.

Dus waarom wil je ze blokkeren?

Als je zelf een website hebt zou ik adviseren om te kijken of je een HTTP record kunt aanmaken in je zone file, naast DNS CAA etc.

Het lijkt me dat FireFox ze binnenkort ook zal maken.

Zie je ze ook bij Chrome/ Chromium?

[Reactie gewijzigd door djwice op 24 juli 2024 18:36]

pihole is de mooiste tool die ik de laatste 40 jaar heb gezien
Draait hier al een paar jaar op een Raspberry Pi Zero W. Werkt perfect.
Die heb ik ook nog liggen. Maar waar is een andere computer goed voor? Een virtuele LAN-node is een beperking? Dat lukt mij al jaren met Qemu. De enige lag die ik daaraan merk is dat de host-computer soms even wakker moet worden omdat een VM met netwerk die de hele tijd niks doet overal de prioriteit verliest. Je zou met een scriptje de hele tijd het systeem kunnen poken met netwerkactiviteit, dan ben je daar waarschijnlijk ook vanaf.

[Reactie gewijzigd door blorf op 24 juli 2024 18:36]

Ik heb hier geen vaste computer staan, die altijd aan staat. De Raspberry Pi kan dat zonder al te veel overhead wel continu aan blijven staan. Thuis gebruik ik voornamelijk de telefoon en tablet en voor YouTube gebruik ik newpipe. Op de laptop kan ik gewoon een addblocker gebruiken in de browser (meestal ingelogd via vpn en kan ik mijn raspberry toch niet benaderen).
Mooi spul, gebruik het hier al jaren naar volle tevredenheid. Hoewel. Mijn jongens willen soms juist reclames kijken zodat ze weer extra speeltijd krijgen in sommige spellen 8-)

Verder draai ik hem in een docker container (met compose). Super makkelijk want dan krijg je automatische de udates binnen (bij mijn wekelijkse docker pull).
Ik heb voor precies dit doeleinden een open lan gemaakt. Wil je reclame of op sponsor resultaten klikken?FF daarmee verbinden, of wifi uitschakelen en via de mobiele weg mocht je actie niet veel data verbruiken.
Wat was het update commando ook alweer?
update -pihole is het niet en mijn pihole geeft geen statpagina weer...

Heb het al: pihole -up

[Reactie gewijzigd door sjonie100 op 24 juli 2024 18:36]

Fijne software om te draaien en ik gebruik het al jaren. Voorbeen gebruikte ik diverse blacklisten, maar sinds een jaar of twee staat alleen .* in mijn blacklist. Zaken die ik wil kunnen zien komen dan op mijn whitelist. Wanneer een adverteerder of tracker dan een nieuwe url heeft, hoef je ook niet te wachten op de update van de blacklists.
Erg fijn en met de combi met Tailscale heb ik ook buitenshuis geen reclames meer.
De Pihole update is versie 5.15.5, niet 5.15.4?

Op dit item kan niet meer gereageerd worden.