Software-update: Pi-hole Core 5.3 / Web 5.5 / FTL 5.8

Pi-hole logo (75 pix) Versie 5.3 van Pi-hole Core is verschenen. Ook zijn Pi-hole Web 5.5 en FTL 5.8 uitgekomen. Pi-hole is een advertising-aware dns- en webserver bedoeld om te draaien op een Raspberry Pi in het netwerk. Als op de router naar Pi-hole wordt verwezen voor dns-afhandelingen, zullen alle apparaten binnen het netwerk er automatisch gebruik van maken zonder dat er instellingen moeten worden aangepast. Vervolgens worden advertenties niet meer opgehaald, waardoor pagina's sneller laden. In potentie kan er ook malware mee buiten de deur worden gehouden. Voor meer informatie verwijzen we jullie door naar de uitleg en video's op deze pagina, of deze handleiding van tweaker jpgview. De changelog voor deze uitgave ziet er als volgt uit:

Highlights

More details for your adlists

The web dashboard does now provide health-status and statistics about downloaded and processed adlists. You can see when they were last downloaded, when they were last changed and it they work at all or contain invalid domains. This aims at simplifying using additional lists.

Add Pi-hole darker theme

This PR adds a third default theme, an even `darker` variant of the dark one. It also fixes an issues with the existing `dark` theme where links in box headers (like the Query Log’s “show all”) were completely invisible. Comparison between the existing dark (on the left) and the new darker (on the right):

Automated IP blocking mode

Until now, FTL’s IP and IP-NODATA-AAAA blocking modes sourced the IP to deliver on a blocked domain from the setupVars.conf values IPV4_ADDRESS and IPV6_ADDRESS. This is, however, quite a limitation, especially if the device running Pi-hole has more than one interface or of the address is changing. To address this, FTL v5.8 implements an automated IP blocking mode. Instead of reading the addresses from setupVars.conf, we dynamically determine the address of the interface a query arrived on. We then use this IP address in the blocked reply. This does not only reduce maintenance (IPV4_ADDRESS and IPV6_ADDRESS can now be removed from setupVars.conf) but also localizes blocked queries. The automated detection can be overwritten using REPLY_ADDR4 and REPLY_ADDR6 in pihole-FTL.conf.

Update embedded dnsmasq to v2.85

New features, bug fixes and several other tweaks are contained in this release. Check out the change log below for more information.

FTL changelog

  • Automate IP blocking mode #965
  • Simplify handling of .lua and .db files #1086
    • pihole-FTL something.lua
      automatically launches the embedded LUA engine
    • pihole-FTL something.db
      behaves the same way as sqlite3 something.db
    • Similar things like
      pihole-FTL something.db "SELECT * FROM abc;"
      are possible as well
  • Add more regex warnings to message table #1092
  • Circle CI: skip uploading build artifacts on forks #1093 (thanks @bershanskiy)
  • Update SQLite to 3.35.4 #1083 #1089 #1097
  • Various enhancements and a few memory-leak fixes #1084
  • Resize shared memory only when locking #1072
    This is not really a functional change, however, it makes the code more read- and understandable in some places.
  • Escape DHCP options if necessary #1070
  • Ensure FTL can be compiled from static tarballs #1091
  • Use properly-sized buffer for format_time() #1088 (thanks @bershanskiy)
  • Fix pihole-FTL test not terminating properly (noticed in a docker environment) #1067
  • Fix incorrect “FATAL: Trying to access upstream ID -1” warning in the logs #1061
  • DNS server improvements:
    • Fix problem with DNS retries in earlier versions.
      The new logic in 2.83/2.84 which merges distinct requests for the same domain causes problems with clients which do retries as distinct requests (differing IDs and/or source ports.) The retries just get piggy-backed on the first, failed, request.
      The logic is now changed so that distinct requests for repeated queries still get merged into a single ID/source port, but they now always trigger a re-try upstream.
      To avoid excessive spamming of the upstream server, similar queries are collected for up to two seconds when the query has already been sent upstream. All clients will get replies when the answer comes back.
    • Avoid treating a dhcp-host which has an IPv6 address as eligible for use with DHCPv4 on the grounds that it has no address, and vice-versa.
    • Add dynamic-host option
      A and AAAA records which take their network part from the network of a local interface. Useful for routers with dynamically prefixes.
    • Teach bogus-nxdomain and ignore-address to take an IPv4 subnet.
    • Use random source ports where possible if source addresses/interfaces in use. CVE-2021-3448 applies.
      It’s possible to specify the source address or interface to be used when contacting upstream name servers: server=8.8.8.8@1.2.3.4 or server=8.8.8.8@1.2.3.4#66 or server=8.8.8.8@eth0, and all of these have, until now, used a single socket, bound to a fixed port. This was originally done to allow an error (non-existent interface, or non-local address) to be detected at start-up. This means that any upstream servers specified in such a way don’t use random source ports, and are more susceptible to cache-poisoning attacks.
      We now use random ports where possible, even when the source is specified, so server=8.8.8.8@1.2.3.4 or server=8.8.8.8@eth0 will use random source ports. server=8.8.8.8@1.2.3.4#66 or any use of query-port will use the explicitly configured port, and should only be done with understanding of the security implications. Note that this change changes non-existing interface, or non-local source address errors from fatal to run-time. The error will be logged and communication with the server not possible.
    • Change the method of allocation of random source ports for DNS. Previously, without min-port or max-port configured, dnsmasq would default to the compiled in defaults for those, which are 1024 and 65535. Now, when neither are configured, it defaults instead to the kernel’s ephemeral port range, which is typically 32768 to 60999 on Linux systems. This change eliminates the possibility that dnsmasq may be using a registered port > 1024 when a long-running daemon starts up and wishes to claim it. This change does likely slightly reduce the number of random ports and therefore the protection from reply spoofing. The older behavior can be restored using the min-port and max-port config switches should that be a concern.
    • Scale the size of the DNS random-port pool based on the value of the dns-forward-max configuration.
    • TFTP tweak: Check sender of all received packets, as specified in RFC 1350 para 4.

Web changelog

  • Add details to adlist table #1673 (@DL6ER)
  • Don’t count new status types as blocked queries in long-term data #1743 (@yubiuser)
  • Add hint for update command & documentation link #1749 (@j15e)
  • Add Pi-hole darker theme #1731 (@DL6ER)
  • Trim CNAME target input field value data #1759 (@Yrlish)

Core changelog

Versienummer 5.3 / 5.5 / 5.8
Releasestatus Final
Besturingssystemen Scripttaal
Website Pi-hole
Download https://github.com/pi-hole/pi-hole/releases/tag/v5.3
Licentietype GPL

Reacties (54)

54
54
46
4
0
4
Wijzig sortering
Inmiddels is hier ook alweer een hotfix in Pi-hole Core naar V5.3.1 (https://github.com/pi-hole/pi-hole/releases/tag/v5.3.1) uitgebracht die ervoor zorgt dat het weer mogelijk is om als upstream DNS server 127.0.0.1#5335 in te stellen.

Edit: typo

[Reactie gewijzigd door Sand0rf op 22 juli 2024 15:53]

Je bedoeld 127.0.0.1?
Correct, local host
Dit Engels YT video laat zien wat er zo speciaal is met de Upstream DNS en poort 5335.
https://www.youtube.com/watch?v=FnFtWsZ8IP0
DNS adblocking werkt niet meer zo goed als vroeger. Ik vraag me af hoe dat komt. Vaker direct via ip adressen? Of wordt HTML5 gebruikt?
Veel apparaten gebruiken ook een ingebouwde DNS server op het moment dat er iets geblokkeerd wordt. Google staat hierom bekend, maar ook veel IOT apparaten hebben toevallig nog een derde achterdeurtje lopen via bijvoorbeeld 8.8.8.8, zoals bijvoorbeeld de Samsung smart tv's.
Mag het gebruik van een geforceerde DNS server wel? Dat lijkt mij iig tegen privacywetgeving, omdat je via DNS-servers getracked kan worden.

[Reactie gewijzigd door MrFax op 22 juli 2024 15:53]

Dit kun je alleen ondervangen via je router/modem anders gaat je dit niet lukken. De meeste modems staan het toe om je eigen DNS-servers in te stellen i.p.v. die van de provider.
Hoe zou ik dat dan moeten vangen? Alle bekende DNS-providers (ip-adressen) blokkeren, en alleen je Pi-Hole whitelisten, zodat deze nog wel DNS-queries kan maken naar bijv. 1.1.1.1?

[Reactie gewijzigd door MrFax op 22 juli 2024 15:53]

Sorry ik was in mijn vorige post niet volledig. Je kunt een firewall rule kunnen aanmaken dat je al het DNS verkeer op bijvoorbeeld 8.8.8.8 blokkeert en je DNS servers op je router/modem instelt op bijvoorbeeld die van Cloudflare, Quad9 of en andere dienstverlener.

Gebruik maken van Unbound is bijvoorbeeld een andere mogelijkheid. Hier kun je best veel howto's over vinden op het web :)

[Reactie gewijzigd door Miki op 22 juli 2024 15:53]

Sorry ik was in mijn vorige post niet volledig. Je kunt een firewall rule kunnen aanmaken dat je al het DNS verkeer op bijvoorbeeld 8.8.8.8 blokkeert en je DNS servers op je router/modem instelt op bijvoorbeeld die van Cloudflare, Quad9 of en andere dienstverlener.
Je blokkeert dan niet 8.8.4.4 of 9.9.9.9, bijvoorbeeld.

Het is mogelijk om al het uitgaande DNS verkeer te blokkeren, maar daarmee heb je bijvoorbeeld DNS over HTTPS nog niet geblokkeerd.

[Reactie gewijzigd door The Zep Man op 22 juli 2024 15:53]

Je kunt een firewall rule kunnen aanmaken dat je al het DNS verkeer op bijvoorbeeld 8.8.8.8 blokkeert en je DNS servers op je router/modem instelt op bijvoorbeeld die van Cloudflare, Quad9 of en andere dienstverlener.
En dan schakelt men gewoon over naar gebruik van DoH (DNS over HTTPS).
En zie hier dus het kat en muisspelletje tussen tweakers en de advertentieboeren :)
Je kunt de DNS servers ook blokkeren met behulp van "static routing" in je router. Mijn Android telefoon verbindt soms, bij snel wisselen tussen routers in huis, direct naar 8.8.8.8 en verbindt dan dus niet via Pi-Hole met als gevolg dat je dan reclame te zien krijgt. Om dit te voorkomen heb ik de google servers volledig geblokkeerd via deze static routing (waardoor ik dan wel soms tijdelijk een DNS error te zien krijg, maar dat liever dan Google DNS!)

https://help.trickbyte.com/category/block-public-dns/
Je kunt de DNS servers ook blokkeren met behulp van "static routing" in je router.
Waarom blokkeer je dat, en laat je 'onveilige' DNS naar 8.8.8.8 en 8.8.4.4 niet gewoon afhandelen door je router zelf? :?
Maar DNS is puur voor het omzetten van records naar IP-adressen. Windows Update trekt zich er niet zoveel van aan, die resolved *intern* al gewoon naar hun IP adressen.
Een hele makkelijke is, wanneer je een Raspberry PI als PI-Hole gebruikt:
1. Firewall rule BLOCK toegang tot poort 53 voor ALLES behalve het IP adres van de PI-Hole.
2. Verander de WAN DNS adres(sen) naar de PI-Hole IP adres(sen).
3. Bij gebruik van DHCP, verander de DNS adres setting van de DHCP server naar het PI-Hole IP adres(sen).
Hierdoor kunnen alle apparaten, inclusief de router alleen met de PI-Hole als DNS werken.

[Reactie gewijzigd door Bart_Smith op 22 juli 2024 15:53]

Als DNS geforceerd op 8.8.8.8 staat in een apparaat kan je dat alleen in je router ondervangen door de routingtabel handmatig aan te passen. Dat is zeker geen standaardfunctionaliteit.
Je kan toch ook een ACL-regel aanmaken die alles via poort 53 blokkeert behalve een enkele DNS provider? Je kan zelfs zeggen dat alleen je Pi-hole deze kan benaderen, zodat je alleen via de Pi-hole queries kan maken.

[Reactie gewijzigd door MrFax op 22 juli 2024 15:53]

Handiger is het als je een NAT redirect aanmaakt om alsnog bij je pi hole uit te komen.
Werkt uiteraard alleen bij IPv4, maar IPv6 is anno 2021 nog steeds een drama bij te veel "mobiele" apparatuur. 8)7
Dat is wel erg ver gezocht. Dat is net zoiets als een zoekmachine verbieden omdat de zoekmachine weet wat je zoekt. Ergens komt iemand iets te weten anders kan jij ook niks vinden.

Anyway, ik had hetzelfde issue. Ik had DNS verkeer naar buiten geblokkeerd van binnen naar buiten. De pi-hole werkt met DoH dus die heeft daar geen last van. De Nefit app op mijn telefoon deed niets meer. Die maakte wel hard gebruik van 8.8.8.8.

Dus een NAT regel aangemaakt : al het verkeer van intern naar internet wat gebruikt maakt van DNS (53) omleiden naar de Pi-Hole.
Ah zo zou dat dus ook kunnen. Hierboven zei ik wat anders, maar wat jij zegt is misschien een wat makkelijkere oplossing.
Android doet dit ook vaak. Als je maar 1 DNS server instelt op je netwerk, dan zet Android vaak 8.8.8.8 als 2e en krijg je alsnog de advertenties via die server.

Wat hier goed tegen helpt is het gebuik van DNS filtering op je router/firewall. Die kan alle DNS verzoeken weer doorsturen naar je Pi. Dat zorgt er dan ook voor dat veel IoT apparaten geen reclame meer kunnen opzoeken.
Is het ook niet verstandig om unbound te installeren in combinatie met pi-hole, zodat het een recursive DNS server wordt?
Dat ligt er aan wat je doel is.

Als je niet afhankelijk wil zijn van een paar derde partijen, of niet wil dat één derde partij al je DNS-verkeer ziet, dan kan je dat doen. (Je kan natuurlijk je pi-hole/Adguard Home naar een hele zwik backends laten praten om te voorkomen dat één partij al je DNS-verkeer ziet, maar dat is een ander verhaal.)

Als je wilt dat je DNS-verkeer naar het internet toe versleuteld is, kan je er voor kiezen om bijvoorbeeld met DoH (of DoT, enz. enz.) richting een derde partij kan praten. pi-hole heeft daar derdepartijsoftware voor nodig. Adguard Home ondersteund intern (ook DoH binnen je LAN, zodat eventuele malware die op je netwerk draait niet je DNS-verkeer kan afluisteren, wat opzich handig kan zijn in deze tijd van IOT-devices, die je niet zelf echt in controle hebt).

Voordeel daarvan is, is dat ook je ISP niet je DNS-verkeer kan zien. (al hebben die uiteraard ook andere manieren om je te tracken als zij dat graag zouden willen)
Intressant, ik had toevallig ook net een vraag gesteld op het forum over het gebruik maken van interne DNS servers. Je ziet vaak dat men Pi-hole in combinatie pakt met bijvoorbeeld Unbound.

Als Adguard dat beter als 1 oplossing af kan vangen, dan is dat zeker een voordeel voor Adguard. Ben je toevallig ook bekend met andere DNS oplossing zoals CoreDNS?
AdGuard Home is niet een recursive dns server als unbound. AGH is een alles-in-een dns server met filterlijsten.
Pi-hole is een systeem met allerlei aan elkaar gescripte onderdelen (plat gezegd is het een aangepaste dnsmasq server met een lighttpd webserver ervoor aangevuld met een zwerm scriptjes om de boel als een geheel te laten draaien.
Begrijp me niet verkeerd. Het is knap aan elkaar gezet!

AGH is een binary en een configuratiebestand. Het is niet beperkt door de functionaliteit van dnsmasq.
Het ondersteund out of the box, DoH, DoT, enz, en heeft geen extra software nodig om te functioneren.

Beide oplossingen hebben een externe upstream sever nodig om te werken.
Voor beide oplossingen zou je bijvoorbeeld unbound kunnen gebruiken als je per se bijvoorbeeld niet de Google DNS of Cloudflare DNS diensten wil gebruiken om welke reden dan ook (zonder waardeoordeel van mijn kant af :) )
Echter kan Unbound een ook werken met blacklists en met een beetje hack-en-slash-werk dus zelfs zonder pi-hole of AGH kunnen werken.

Software als coredns biedt in de praktijk meer voordeel als je je DNS-diensten wil integreren in allerlei andere diensten. Meestal is dit niet nodig voor particulier gebruik.
Bedankt voor je uitgebreide antwoord!
Ik ga starten met AGH en werk vandaar weer verder.

Software als coredns biedt in de praktijk meer voordeel als je je DNS-diensten wil integreren in allerlei andere diensten. Meestal is dit niet nodig voor particulier gebruik.
Dat begrijp ik uiteraard. Ik ben echter op zoektocht om alles in mijn netwerk om te bouwen naar een container based oplossing om hiervan te leren hoe men zaken op een moderne manier oplost. Tot nu toe een fantastische (en soms frustrerende) ervaring. Voor nu nog bezig alle interne 'diensten' aan te bieden via traefik maar de volgende stap is DNS waarbij ik mogelijk ook mijn eigen zone wil hosten (geen idee of het kan, het is voor nu nog maar een idee).

Nogmaals, dank voor je antwoord!
Inderdaad. Op die manier contacteer je zelf de authoritative DNS servers, en vermijd je dat andere partijen AL je dns queries ontvangen (zoals bvb Google, Cloudflare, ...)
Dat niet alleen maar je merkt steeds vaker dat apps op een TV bijvoorbeeld advertentie servers nodig hebben om te werken, dus als je bepaalde dingen niet whitelist start de hele stream niet op.
Weet iemand hoe dat op Openwrt zou moeten?
Ik heb het met een DNAT-Rule opgelost.
Alle dns-verkeer niet afkomstig van de pihole wordt naar de pihole ge-dnat.

( Edgerouter 4 )

[Reactie gewijzigd door BushWhacker op 22 juli 2024 15:53]

Met een DNAT-rule is wat mij betreft de juiste oplossing. Blokkeren van DNS (als 8.8.8.8) ip-adressen niet.
Inderdaad. Merkte dat ook op bij mijn Shield TV. Natuurlijk vrij simpel om gewoon al het DNS verkeer behalve naar je pihole te blokkeren maar toch.
Dit kan je opvangen met de "DNS filter" feature als deze in je router firmware zit.
Xwrt-Vortex onder andere heeft deze feature. http://xvtx.ru/xwrt/
Onderschept alle verkeer op poort 53 en route het alsnog naar de Pi-Hole.
Werkt hier goed.
Dat kan je dan alleen ondervangen door 8.8.8.8 te blokkeren in je firewall (router) en een uitzondering voor je Pihole te maken lijkt me.
Veel advertenties komen tegenwoordig steeds meer van hetzelfde domein als waar de content van de website vandaan komt. In dat geval wordt het veel moeilijker om ze te blokkeren, omdat je dan mogelijk ook niet-advertentie content blokkeert.

Waar deze tools nog wel handig voor zijn is om de meeste tracking van derden te blokkeren. En natuurlijk phishing/malware tegen te houden.
Ze maken vaak gebruik van een vermomde tracker, www.cultofmac.com is er zo eentje die dat doet. Sommige lijsten blokkeren dan het hele domein.

https://medium.com/nextdn...rty-trackers-195205dc522a

Nextdns heeft de optie om dit soort vermomde trackers te blokkeren.

[Reactie gewijzigd door satya op 22 juli 2024 15:53]

Je verwijst naar deze
https://medium.com/nextdn...rty-trackers-195205dc522a pagina, voor meer detail.

Niets nieuws onder de zon, pihole kan dit ook, out of de (sinds v5) box, zij noemen het "deep cname inspection"

Ik leg het ook uit in mijn manual, section 15 (users.telenet.be whitelisten om de manual te lezen) en verwijs naar twee scriptjes op github, om de domains, die van deze techniek gebruik maken te regex blacklisten, de lijst van nextDNS en die van Adguard Team. Lees, download en voer de scriptjes uit, een aantal regex blacklist entries worden toegevoegd, en je bent beschermd...
Zojuist gedaan, fijn idee om weer wat beter beschermd te zijn!

Ik werk niet dagelijks meer met mijn pi-holes (ik heb er twee in mijn netwerk), dus moest even zoeken hoe ik nou precies de scriptjes moest ophalen en uitvoeren. Voor degenen net als ik of liever lui dan moe zijn:

$ wget https://raw.githubusercontent.com/jpgpi250/piholemanual/master/NextDNS.sh
$ sudo chmod +x /home/pi/NextDNS.sh
$ sudo /home/pi/NextDNS.sh

En voila, de entries zijn toegevoegd!

[Reactie gewijzigd door ultramarine op 22 juli 2024 15:53]

Voor de erg luie mensen gaat dit niet op.
De CLI neemt je puntjes ... te letterlijk
wget: unable to resolve host address 'raw.githubusercon...emanual'


wget https//raw.githubusercontent.com/jpgpi250/piholemanual/master/NextDNS.sh

Ja ik ben erg lui :D
is er ook een "undo" scriptje/optie voor die nextDNS settings?
ik merk nu dat nadat ik het heb aangezet er meer cookie wall popups zijn dan gewoonlijk (fok!) maar ook meer advertenties doorheen glippen lijkt het met name in embeded video's op social media.
nope, delete the entries in the web interface (blacklist)

als alles goed gegaan is, hebben alle entries the comment "NextDNS CNAME list", makkelijk om ze te idenficeren...
Het werkt op zich nog best goed, maar dan voornamelijk vanuit een privacy-oogpunt. Voor de grote spelers (Facebook/Google) zal het niet zo goed meer werken zolang je hun producten gebruikt.

Voor websites zie je inderdaad steeds vaker dat de advertenties worden geserveerd via "www.domein.nl/advertenties/vagetrackingscriptjes.js"

Zolang je een pc/telefoon/tablet gebruikt, kan je adblockers in die apps/applicaties gebruiken. (smart-TV zou ik persoonlijk niet weten). Waar de pi-hole-achtige producten wel goed voor zijn, zijn de advertentieblokkades in niet-browser-apps. Je zal toch vaak zien dat willekeurige telefoonspelletjes vaak nog gebruik maken van de servers van de advertentieboeren.

Waar de pi-hole-achtige applicaties wel handig voor blijven (voorlopig althans) zijn, is dat ze een extra laag tegen malware/phishing en ook 'tracking' en externe analytics die je eventueel niet wilt en dat soort zaken zijn.

Als ik bijvoorbeeld (puur anekdotisch natuurlijk) kijk naar mijn Ad Guard Home installaties zie ik ongeveer 6-7% geblokkeerde DNS-verzoeken (ik heb dan ook adblockers op m'n telefoons/tablets/pc's enzo). Het overgrote deel van de geblokkeerde zaken komen af van andere apparaten en omvat grotendeels trackers:

(app-measurement.com, crashlitics, enz. enz. enz.)
Voor een Smart-TV werkt Pi-Hole ook aardig, maar het breekt wel snel bepaalde functionaliteit. Een Samsung stuurt heel veel gebruikersdata naar "huis". Als je al die servers blokkeert werkt er niet veel meer op je TV. Het is dus een beetje trial & error. Voor mijn TV heb ik 78 domeinen geblokkeerd en merk dan geen functieverlies, behalve dat hij de check voor een update niet meer kan doen.
En dat is wellicht maar goed ook, na een update zal je zien dat ze weer nieuwe urls gebruiken voor de tracking :)

En als je dan toch wilt upgraden even de pi hole pauzeren ...
Gelukkig worden blocklists (of 'adlists'), die je in Pi-Hole redelijk makkelijk kunt linken, regelmatig geüpdatet.
Ik zelf gebruik deze voor mijn Samsung tv, en je ziet dat-ie redelijk recent is bijgewerkt en dat er behoorlijk wat domeinen zijn uitgecomment, en waarom ze niet geblockt worden (bijvoorbeeld om updates binnen te trekken).

Groot nadeel van zulke 'third-party' lists is natuurlijk dat je niet volledig zelf in de hand hebt wat geblokkeerd wordt en dat ze soms offline worden gehaald.

[Reactie gewijzigd door Kjoe_Ljan op 22 juli 2024 15:53]

Je ziet inderdaad dat steeds meer sites een combinatie van advertenties via een advertentiebedrijf en advertenties via de eigen server aanbieden. Die laatste kun je niet blokkeren via DNS.
ik heb dit probleem eigenlijk alleen bij youtube.
daarnaast had ik hier heel erg last van met Ziggo icm IPv6
ze maken het middels onmogelijk om de v6 dns server goed te overrulen.

Ik heb daarom net zo lang lopen zeuren totdat ze IPv6 compleet uitgeschakeld hadden.
Ik gebruik pfsense in combinatie met pihole en de firewall is zodanig ingesteld dat geen enkele client een dns request kan doen op internet behalve de unbound dns server van pfsense zelf . Unbound op zijn beurt laat enkel dns request toe van mijn pihole . Op die manier zijn er 0 achterpoortjes voor toestellen die mijn dns filter willen omzeilen :) , ze moeten allemaal via mijn pihole er is geen andere weg. Alles zowel geconfigureerd voor ipv4 en 6

[Reactie gewijzigd door voelie op 22 juli 2024 15:53]

Blokken is soms niet goed, want sommige clients kunnen flink eigenwijs zijn. Vandaar op mijn router ik alle verzoeken naar port 53 van none-Pi-Hole re-direct naar de Pi-Hole. De client is blij en ik ben blij :o
Behalve via DoT? ;)
Het DNS adblocking is leuk zolang het nog werkt. Wat ik veel leuker vind om te zien is wat er allemaal gebeurd aan verkeer binnen mijn netwerk. Zoals al die smarthome devices en bridges van verschillende merken. Heb eigenlijk nog niet andere (gratis) software gezien die dit zo in kaart brengt

Op dit item kan niet meer gereageerd worden.