Blocky DNS-Adblocker mit Visor auf dem Raspberry Pi OS 64-Bit im Test. Warum der DNS-Dienst Technitium DNS, AdGuard Home und Pi-hole schlägt.
Der Blocky DNS-Adblocker mit Visor auf dem Raspberry Pi OS 64-Bit im Test. Warum der DNS-Dienst nach Technitium DNS, AdGuard Home und Pi-hole am Ende die Führung übernahm. Nach Technitium DNS, AdGuard Home und Pi-hole blieb im Test auf dem Raspberry Pi OS 64-Bit am Ende nur Blocky mit Visor übrig. Es bietet den kleineren Unterbau, erlaubt den direkteren Zugriff und ist im Alltag näher an dem, was auf so einem Host tatsächlich gebraucht wird. Das gilt auch, wenn nicht jeder Handgriff sauber über die Oberfläche läuft. Blocky Visor ist dabei die externe Web-Oberfläche, also das Dashboard für Blocky. Bei GitHub ist das Tool hier verfügbar, das Dashboard gibt es hingegen dort.
Technitium DNS war für den Pi einfach zu groß
Technitium DNS war im damaligen Vergleich natürlich der Kandidat, der am meisten konnte. Der Dienst kann als kompletter DNS-Server wirklich deutlich mehr, als ein Raspberry Pi im Heimnetz leisten muss. Er bietet eigene DNS-Bereiche, rekursive Auflösung und eine große Verwaltungsoberfläche sowie einen weiteren, je nach User sinnvollen Unterbau.
Für einen kleinen Host, der vor allem DNS-Anfragen filtern soll, ist das für viele Nutzer einfach zu viel des Guten.
AdGuard Home ist bequem, hat aber nicht so viele Optionen
AdGuard Home ist natürlich weiterhin die bequemste Lösung. Man muss es nur einrichten, Filter eintragen, die DNS umstellen und dann laufen lassen. Die Oberfläche zeigt schnell, was es blockiert und welche Geräte Anfragen schicken. Genau das ist die Stärke von AGH. Der Preis ist, dass man nicht so viele Optionen hat wie bei anderen DNS-Sinkholes. Wer tiefer in die Konfiguration einsteigen oder den DNS-Dienst lieber direkter am Host halten möchte, merkt das sehr schnell.
Pi-hole ist und bleibt halt Pi-hole
Pi-hole ist leider der bekannte Standard. Das Software-Projekt ist etabliert, die Oberfläche vertraut und die Dokumentation ist heute brauchbarer als noch vor ein paar Jahren. Mit Version 6 wurde der Aufbau endlich schlanker, da der Webserver und die REST-API nun direkt im FTL-Dienst stecken. FTL steht für Faster Than Light. Das ist die DNS-Engine plus Datenbank und das Statistik-Backend in einem.
Am Charakter und dem alten System dahinter ändert sich aber nichts. Pi-hole bleibt ein Gesamtpaket mit eigener Logik und eigener Begriffswelt. Wer genau das sucht, bekommt ein ausgereiftes, aber nicht mehr zeitgemäßes Projekt. Wer mehr direkten Zugriff will, schaut sich früher oder später meistens woanders um.
Blocky ist die schlanke Lösung
Blocky hält alles funktionell und minimalistisch. Der Dienst filtert den Domain Name Server (DNS) und kann nebenher Werbung und Malware filtern. Dafür braucht die Software ein Binary, eine Konfigurationsdatei und einen laufenden Dienst. Mehr Rattenschwanz und Abhängigkeiten hängen da nicht dran. Auf einem Raspberry Pi passt das besser als das nächste System mit vielen Extras, die man erst einmal einstellen und verwalten muss.
Erst mit der Web-Oberfläche Visor wird der Aufbau im Alltag aber wirklich brauchbar. Blocky liefert die Basis und Visor hängt sich direkt daran. Abfragen testen, Blocking schalten, Listen neu laden, Cache leeren. Mit dem Sidecar kommen Logs, Verlauf und der Konfigurationszugriff hinzu. Ein Sidecar ist ein zusätzlicher Begleitdienst, der Blocky erweitert. Beispielsweise für die Erstellung von Logs für eine spätere Auswertung, die grafische Oberfläche oder für die Nutzung von APIs.
Dann hängt die Verwaltung nicht mehr irgendwo zwischen YAML-Konfigurationsdateien (Configdateien als reiner Text), Journal und Terminal. Alles sitzt unter einer Oberfläche maximal effizient vereint, wie aus einem perfekten Guss. Technitium war dafür zu groß, AdGuard Home zu eng geführt mit zu wenig Optionen und Pi-hole ist halt einfach Pi-hole. Blocky mit Visor löst das wesentlich nüchterner und pragmatischer. Trotzdem muss man dabei auf nichts verzichten, im Gegenteil.
DoH und DoT sind dabei kein Problem
Bei den verschlüsselten Upstreams hält Blocky den Aufbau erstaunlich minimalistisch. DoH und DoT sind direkt in der Konfiguration integriert. Ein zusätzlicher Dienst ist dafür glücklicherweise nicht nötig. DoH (DNS over HTTPS) und DoT (DNS over TLS) sind zwei Verfahren, um DNS-Anfragen zu verschlüsseln.
Bei Pi-hole landet man da schnell wieder bei ergänzenden Bastellösungen wie Unbound, wenn der Resolver und man überhaupt die Möglichkeit haben will DoH und DoT zu nutzen. Unbound ist ein lokaler, rekursiver DNS-Resolver, den man zusätzlich zu Pi-hole betreiben kann. Wenn man Unbound dann noch in Tailscale laufen lassen will, braucht man mehrere Tage, um es irgendwie stabil zum Laufen zu kriegen. Ohne Tailscale läuft es ohne Frage. Aber mit ist es eine große Herausforderung, die auch Fachleute mit Pi-Hole immer noch nicht erfolgreich bewältigen können.
Grafana liefert vor allem Kurven, Visor hängt dagegen direkt am Dienst
Das Monitoring-System Prometheus sammelt die Messwerte. Die Visualisierungsschicht Grafana setzt diese als Dashboard um. Das ist für größere Setups nicht verkehrt. In diesem Test auf dem Raspberry Pi lag der Fokus jedoch woanders. Hier ging es nicht um eine weitere Ansicht im Browser, sondern um einen DNS-Dienst, der sich im Alltag schneller prüfen und direkter bedienen lässt.
Wer wirklich nur Kurven sehen will, kann sich den Rest einfach daneben bauen. Wer jedoch wissen will, warum eine Anfrage durchgeht, ob Blocking aktiv ist oder wann die Listen zuletzt neu geladen wurden, ist mit Visor besser beraten. Dort sitzt auch das Query-Tool und die Schalter, die einen sauberen Ablauf im Alltag ermöglichen.
Sidecar macht den Unterschied
Mit der externen Komponente Sidecar wird auch für den letzten User alles sichtbarer. Die Logs, der Verlauf, der Konfigurationszugriff und Dienststatus hängen dann an derselben Programmstruktur. Für einen Dienst wie Blocky ist das von Vorteil, da es so nicht noch einen weiteren Graph im Browser gibt.
Es gibt jedoch eine klare Grenze. Das Sidecar läuft zwar überall dort, wo Go läuft. Die Funktionen für den Dienststatus und Neustart setzen jedoch zwangsweise ein Linux-System mit systemd voraus. Ohne systemd fallen diese Funktionen leider weg. Deshalb passt die native Installation hier einfach besser als eine Container-Installation. systemd ist ein Init-System und Service-Manager für Linux, also eine zentrale Komponente. Diese sorgt dafür, dass das System startet und alle benötigten Dienste laufen.
Im Test hat sich die native Installation durchgesetzt. Nicht aus Prinzip und nicht, weil manche Nutzer Docker ungern nutzen, sondern weil diese Lösung pragmatischer ist.
Konfiguration, Logs und Dienst hängen jetzt genau dort, wo sie hingehören. Die Konfiguration befindet sich unter /etc/blocky, die Logs liegen auf dem Host und der Dienst wird von systemd gesteuert. Wenn etwas nicht startet, steht es im Journal, sodass man nicht rätseln muss, woran es liegen könnte, wie es bei einer Docker-Installation der Fall ist. Wenn eine Liste mal wieder nicht lädt, landet die Meldung ebenfalls dort.
Docker geht natürlich, keine Frage. In genau diesem Aufbau fehlt jedoch ein Teil dessen, was nativ sauber zusammenspielt. Gerade der Sidecar lebt davon, dass Dienststatus und Hostverwaltung harmonieren.
Die Listen von Blocky sollen treffen, nicht gut aussehen
Bei der Auswahl der Listen hat man bewusst darauf geachtet, dass sie nicht zu knapp oder zu überbordend ausfallen. HaGeZi Ultimate deckt bereits viel von dem ab, was im Heimnetz stört. Im Test kamen trotzdem Pro, TIF, Popupads und die nativen Speziallisten für Amazon, Samsung, Xiaomi sowie Oppo-Realme hinzu. Ergänzt wurde dies durch die Perflyst-Listen für Smart-TVs, Fire-TV und Android-Tracking. Hinzu kam d3Host für die bekannten DNS-Blocktests.
Kurz ist die Liste natürlich leider nicht. Für ein Netz mit Fernsehern, Streaming-Sticks und Android-Geräten ist sie dennoch verständlich und wichtig. Gerade die nativen und gerätespezifischen Listen erfassen den Datenverkehr, der allgemeinen Werbe- und Trackinglisten oft nicht berücksichtigen. Wer solche Geräte im Netz hat, spart sich damit einiges an Arbeit und hat den Datenschutz, den er eigentlich von vornherein haben sollte.
Wie gesagt, Blocky arbeitet mit Allowlists. Wenn eine Domain in derselben Gruppe sowohl in der Denylist als auch in der Allowlist steht, gewinnt die Allowlist und die Domain wird wieder erlaubt. Wichtig ist außerdem: Ohne passende clientGroupsBlock-Zuordnung haben Allow- und Denylists gar keine Wirkung.
So sieht das in der config.yml aus:
blocking:
denylists:
default:
– https://deine-blockliste.example/list.txt
allowlists:
default:
– tarnkappe.info
– www.tarnkappe.info
– cdn.tarnkappe.info
clientGroupsBlock:
default:
– default
Danach die Listen neu laden oder alternativ Blocky neu starten.
d3Host fällt aus dem Rahmen
d3Host fällt aus dem Rest etwas heraus, hat aber eine klare Aufgabe. Die Liste ersetzt keine Browser-Regeln, die sichtbare Werbeelemente ausblenden. Und sie löst auch keine Script-Regeln, die DNS allein nicht erfassen kann. Sie deckt die typischen Host-Abfragen der bekannten Blocktests ab und hebt dort das Ergebnis. Doch es geht nicht um das Pushen der Statistiken der Adblocker-Tests. d3Host blockiert auch die ganzen nervigen Abfragen, die Reddit und Co. auf uns loslassen. Sie ist also eine sinnvolle praktische Ergänzung zu den Listen, die man ohnehin laufen lassen sollte, um nicht mit Werbung, Tracking und Co. überflutet zu werden.
Natürlich überschneiden sich die Listen gelegentlich, aber sie ergänzen sich besser, als dass sie sich beißen. Ultimate ist bereits sehr umfangreich. Wer dazu noch Pro, TIF und weitere Spezialisten einträgt, erstellt keine filigrane, wirklich fein justierte Konfiguration. Es sollte nicht darum gehen, dass die YAML-Dateien besonders elegant aussehen. Ziel der Aktion war ein DNS-Dienst, der in einem typischen Heimnetzwerk möglichst wenig durchrutschen lässt. Ein Fernseher oder ein Fire-TV-Stick interessiert sich schließlich auch nicht dafür, ob die Konfiguration hübsch aussieht. Sie muss einfach zuverlässig und stabil funktionieren, ohne dass man ständig daran herumschrauben muss.
Im Test kamen diese beiden DNS-over-HTTPS-Dienste als Upstreams zum Einsatz: https://dns.nextdns.io und https://dns.adguard-dns.com/dns-query. Als Bootstrap-DNS kamen tcp+udp:9.9.9.9, tcp+udp:149.112.112.112, tcp+udp:94.140.14.140 und tcp+udp:94.140.14.141 zum Einsatz.
Blocky gefällt natürlich nicht jedem
Ganz ohne Ärger läuft es leider auch nicht immer. Blocky mit Visor passt sicher nicht jedem. Die Web-Oberfläche Visor nimmt einem einiges ab, aber nicht alles. Gerade beim Aktualisieren der Listen führt der Weg gelegentlich wieder ins Terminal. Dann läuft der Refresh nicht über die Oberfläche, sondern manuell in der Shell. Wer das gelegentliche Neuanstoßen des Downloads vermeiden möchte, ist mit AdGuard Home* sicherlich besser beraten. Wer als nicht so technikaffiner Mensch Blocky trotzdem nutzen will und keine Lust hat das Terminal zu nutzen, folgt einfach dem üblichen Klischee: Kabel raus, Kabel rein, fünf Minuten warten und die Listen sollten sich dann aktualisiert haben. Das Verhaspeln beim Download sollte dann auch Geschichte sein.
So lief die Installation von Blocky im Test
Im Test lief der Aufbau nativ unter Raspberry Pi OS 64-Bit. Blocky haben wir als Binary auf das System geladen. Die Konfiguration lag unter /etc/blocky/config.yml, dazu kam ein systemd-Dienst und feste Pfade für Logs und Daten. Danach folgten Visor und der Sidecar. Im Test lief der Aufbau nativ. Zuerst wurde Blocky installiert, dann Visor und schließlich der Sidecar.
Blocky kann seine Denylists direkt per HTTP oder HTTPS laden. Darum lassen sich HaGeZi, Perflyst und d3Host in derselben Konfiguration unterbringen, ohne dass ein zusätzlicher Listen-Umweg dazwischengeschaltet werden muss.
Ja, das Installations-Skript hat eine KI erstellt, da es viele Fallstricke gibt, die man erst mit Trial and Error beheben kann. Ob ihr sie nutzt oder nicht, ist natürlich euch überlassen. Wir wollten sie euch nicht vorenthalten. Ein Skript ist speziell für einen Raspberry Pi und ein Skript ist extra für einen NUC gedacht, womit Blocky mit seinen Ergänzungen sinnvoll laufen kann. Wir haben beide Skripte getestet und es lief damit problemlos alles durch. Auch die im Artikel genannten Listen sind gleich integriert.
Umbrel, CasaOS und ähnliche Oberflächen sind dabei nahezu nutzlos
Docker funktioniert zwar. Aber nicht alle Aspekte, die den Aufbau mit Visor wirklich interessant machen, funktionieren dort sauber im Zusammenspiel. Für Umbrel, CasaOS und ähnliche Oberflächen gibt es deshalb auch keinen sauberen Ein-Klick-Weg. Man könnte sich alles maximal in Portainer selber zusammenbauen. Dort bekommt man aber alle bereits erwähnten Nachteile einer Docker-Installation früher oder später zu spüren. Das macht somit wenig Sinn.
Blocky – unser Fazit
Wir lassen den Aufbau des Systems so stehen, weil das Zusammenspiel der Bestandteile alle Anforderungen an einen DNS-Adblocker erfüllt. Das System macht seinen Job zuverlässig und stabil, auch Wochen nach dem Test.
Es gibt eine weitere tolle Funktion, die uns von allen bisher getesteten DNS-Adblockern bis jetzt am besten gefällt. Blocky kann live die Abfragen nach IPs zuordnen, was bisher nur bei großen Firewalls und Infrastrukturen aus dem Businessbereich möglich war. Wenn man sehen möchte, ob die Tochter live auf TikTok surft oder der Sohn statt der Hausaufgaben seine Zeit auf Facebook verschwendet, kann man das dort sehen. Leider kann man dann nicht mit einem Klick wie bei AdGuard Home die Dienste komplett sperren. Über Blocky Visor ist aber auch das schnell erledigt. So konnten wir unsere benutzerdefinierte AdGuard-DNS-Liste aus dem Account importieren und somit einfügen.
Im Webinterface auf der AdGuard-Seite kann man mit wenigen Klicks die Dienste sperren und sie werden im eigenen Profil übernommen. Da AdGuard keinen Low Latency DNS hat, benutzen wir lieber NextDNS. Aber man merkt den Unterschied im Alltag nicht, außer bei kritischen Sachen, die auf dem Homeserver ihren Dienst verrichten.
Blocky ist gekommen, um zu bleiben. Die Ergänzung durch die eigene Custom-Adblock-DNS-Liste hebt das Tool auf ein neues Level. So kann es bleiben. Auch wenn Adguard Home ähnliche Fähigkeiten besitzt, gefällt uns der Live-Service von Blocky zu gut, als dass wir ihn wieder missen wollen.
(*) Alle mit einem Stern gekennzeichneten Links sind Affiliate-Links. Wenn Du über diese Links Produkte oder Abonnements kaufst, erhält Tarnkappe.info eine kleine Provision. Dir entstehen keine zusätzlichen Kosten. Wenn Du die Redaktion anderweitig finanziell unterstützen möchtest, schau doch mal auf unserer Spendenseite oder in unserem Online-Shop vorbei.
