+01
Netzweit statt pro Gerät
Ein zentraler DNS-Server filtert für alle. Kein Ad-Blocker-Plugin auf jedem Laptop, Handy oder Fernseher – die Fritz!Box schickt einfach jede Anfrage über Pi-hole.
Berufsschulprojekt · IT · Beispiel-Dokumentation
Zerörkler zerörkelt jede Werbung im ganzen Netz.
Ein Raspberry Pi 400, Pi-hole als zentraler DNS-Server und ein kleiner Ninja, der Werbung netzweit zerlegt – bevor sie überhaupt lädt.
Raspberry Pi 400Pi-holeRaspberry Pi OS LiteFritz!BoxUpstream Cloudflare 1.1.1.1Static IP 192.168.188.33/24DNS-Sinkhole
01 // KONTROLLZENTRUM
Pi-hole Kontrollzentrum
Erlebe live, was Pi-hole macht: Stoppe es – und das Netz versinkt in Werbung. Starte es – und der Zerörkler räumt auf.
Pi-hole: AKTIV
„Stoppe Pi-Hole“ simuliert das Netz ohne Schutz: überall Werbe-Pop-ups. „Starte Pi-Hole“ ruft den Ninja – er zerörkelt alles wieder sauber.
📄 Vollständige Doku als PDF — im echten Projekt inklusive
🎬 Einführungs-Video
❓ FAQ
🧾 Doku auf der Seite
Heute geblockte Werbungen
● Statistik läuft live
02 // BILANZ
Vorteile & Nachteile
// Vorteile
+02
Werbung lädt gar nicht erst
Weil schon die DNS-Auflösung von Werbe- und Tracker-Domains blockiert wird, kommt der Datenverkehr nie an. Das spart Bandbreite und macht Seiten spürbar schneller.
+03
Weniger Tracking
StevenBlack's Unified Hosts List blockt nicht nur Banner, sondern auch viele Tracker. Weniger Datensammler im Hintergrund, ohne dass man je ein Häkchen setzen muss.
+04
Sichere Auflösung über Cloudflare
Alles, was kein Werbekram ist, geht an Cloudflare 1.1.1.1 / 1.0.0.1 weiter – mit DNSSEC, das die Echtheit der DNS-Antworten prüft und Manipulation erschwert.
+05
Voller Überblick im Dashboard
Die Admin-Oberfläche zeigt live, was blockiert wurde, welche Domains wie oft anfragen und wie viel Prozent des Verkehrs draußen bleibt. Query-Logging inklusive.
+06
Sparsame Hardware
Ein Raspberry Pi 400 mit Raspberry Pi OS Lite reicht völlig. Kein extra Rechner, kaum Stromverbrauch, läuft still im Hintergrund.
// Nachteile
−01
Single Point of Failure
Fällt der Pi aus, funktioniert die Namensauflösung im Netz nur noch eingeschränkt, bis man in der Fritz!Box auf einen anderen DNS zurückstellt. Ein zweiter DNS als Fallback wäre der nächste sinnvolle Schritt.
−02
Whitelist-Pflege nötig
Manche Seiten laden Bausteine von Domains, die auf der Blockliste stehen. Dann muss man die betroffene Domain gezielt über die Whitelist freigeben – etwas Handarbeit bleibt.
−03
Caches tricksen anfangs
Fritz!Box und Endgeräte speichern DNS-Antworten zwischen. Nach dem Umstellen dauert es, bis der alte Cache abgelaufen ist – ohne Neustart oder Cache leeren wirkt es kurz so, als würde nichts blocken.
−04
Blockt nur DNS-basierte Werbung
Werbung, die von derselben Domain wie der Inhalt kommt, lässt sich über DNS nicht sauber trennen. Solche In-Content-Anzeigen rutschen durch – Pi-hole ist stark, aber kein Allheilmittel.
03 // EINFÜHRUNG
Einführung Pi-Hole
Unser Werbevideo erklärt in wenigen Sekunden, warum ein netzweiter Werbeblocker das Netz besser macht – augenzwinkernd, aber technisch korrekt.
// Einführungs-Video
Zum Projekt gehört ein kurzes Werbevideo, das den Nutzen eines netzweiten Werbeblockers augenzwinkernd erklärt — im echten Projekt als eingebettetes Video enthalten.
04 // TELEMETRIE
Live-Stats
Die Zahlen zum Projekt auf einen Blick: welche Hardware, welche IP, welcher Upstream, welche Blockliste – und was am Ende wirklich blockiert wurde.
01
0
DNS-Anfragen (24 h)
Vom Pi-hole verarbeitete Anfragen an einem Tag – live aus unserem Dashboard.
02
0
Geblockte Anfragen (24 h)
Werbung & Tracker, die gar nicht erst geladen wurden.
03
0,6 %
Blockrate
Anteil der geblockten Anfragen im Testzeitraum.
04
0
Domains auf Blocklisten
Bekannte Werbe- und Tracking-Domains in den aktiven Listen.
05
0 Geräte
Netzweit getestet
Laptop und Smartphone – ganz ohne Zusatz-Software geschützt.
06
0 %
Ziel erreicht
Projektziel netzweiter Werbeblocker vollständig erreicht.
05 // STECKBRIEF
Was ist Zerörkler?
Ausgangspunkt war die Frage, wie man in einem Heimnetz Werbung und Tracker nicht nur in einem einzelnen Browser, sondern auf allen Geräten gleichzeitig blockieren kann. Wir haben dafür einen Raspberry Pi 400 mit Pi-hole als zentralen DNS-Server im Netz hinter einer Fritz!Box eingerichtet. Der Pi filtert ab sofort netzweit alle DNS-Anfragen und blockiert bekannte Werbe- und Tracking-Domains, während die Fritz!Box weiterhin die IP-Adressvergabe per DHCP übernimmt.
Raspberry Pi 400Pi-holeRaspberry Pi OS LiteFritz!BoxUpstream Cloudflare 1.1.1.1Static IP 192.168.188.33/24DNS-Sinkhole
07 // DEMO-MODUS
Der Ninja zeigt es dir
Drück auf den Ninja. Er fragt, ob er die Adds zerörkeln soll, fliegt eine Runde – und dann zerspringt jede Werbung auf dieser Seite. Genau so, nur netzweit, macht Pi-hole das im echten Heimnetz.
Klick auf Werbe-Invasion starten – dann poppen überall Fake-Anzeigen auf. Unten rechts erscheint der Ninja: böse, solange Werbung da ist, entspannt, wenn alles clean ist.
Ein Klick auf ihn und er fragt: „Soll ich die Adds zerörkeln? Dann drück auf mich!" Danach fliegt er eine Runde, eine Schockwelle zerspringt jede Ad – und der Zähler zeigt, wie viel er zerörkelt hat.
08 // DOKUMENTATION
Die Dokumentation
So haben wir Zerörkler gebaut: Raspberry Pi 400 mit Raspberry Pi OS Lite, feste IP über /etc/dhcpcd.conf, Pi-hole per Ein-Zeilen-Installer, Cloudflare als Upstream und StevenBlack als Blockliste. Jeder Schritt mit Screenshot – von der ifconfig-Ausgabe bis zum fertigen Dashboard.
// Projektidee
Werbung im Internet wird meist über Browser-Erweiterungen wie uBlock Origin oder AdBlock geblockt. Das hat aber zwei Nachteile: Man muss die Erweiterung auf jedem Gerät und in jedem Browser einzeln installieren, und auf vielen Geräten geht das gar nicht — zum Beispiel auf einem Smart-TV, einer Spielekonsole oder in den meisten Apps auf dem Smartphone. Werbung, die eine App direkt nachlädt, sieht ein Browser-Blocker nie.
Ein netzweiter Werbeblocker setzt eine Ebene tiefer an: beim DNS. Bevor ein Gerät eine Werbe- oder Tracking-Domain überhaupt kontaktieren kann, muss es deren IP-Adresse über DNS auflösen. Genau an dieser Stelle greift Pi-hole ein. Es beantwortet Anfragen an bekannte Werbe-Domains mit einer Leer-Antwort, sodass die Verbindung gar nicht erst zustande kommt. Weil alle Geräte im Netz denselben DNS-Server benutzen, wirkt der Schutz automatisch für jedes Gerät — vom Laptop über das Smartphone bis zum Fernseher — ohne dass man dort etwas installieren muss. Das war unsere Motivation für dieses Projekt.
// Projektziel
Ziel war es, einen Raspberry Pi 400 mit Raspberry Pi OS Lite so einzurichten, dass er im Heimnetz als zentraler DNS-Server mit Pi-hole läuft und netzweit Werbung sowie Tracker blockiert, ohne die bestehende Fritz!Box-Infrastruktur (insbesondere DHCP) zu ersetzen.
// Netzwerk-Architektur
Die Skizze zeigt den Aufbau: Alle Endgeräte fragen wie gewohnt bei der Fritz!Box an, die weiterhin die IP-Adressen per DHCP vergibt. Für die Namensauflösung ist jetzt der Raspberry Pi 400 mit Pi-hole zuständig. Bekannte Werbe- und Tracking-Domains beantwortet er selbst ins Leere, alle erlaubten Anfragen reicht er an die Cloudflare-Server 1.1.1.1 / 1.0.0.1 weiter.
// Material
Raspberry Pi 400
Einplatinencomputer in Tastaturform, dient als dauerhaft laufender DNS-Server für Pi-hole
Raspberry Pi OS Lite
schlankes Betriebssystem ohne grafische Oberfläche, sparsam im Ressourcenverbrauch und passend für einen reinen Server-Dienst
microSD-Karte mit vorinstalliertem Raspberry Pi OS Lite
Systemdatenträger des Raspberry Pi
Fritz!Box (Router)
bestehender Heimnetz-Router, bleibt für Internetzugang und DHCP zuständig, verweist per lokalem DNS-Eintrag auf den Pi
Netzteil USB-C
Stromversorgung des Raspberry Pi 400
WLAN-Verbindung (Interface wlan0)
Netzwerkanbindung des Pi ans Heimnetz
Laptop und Smartphone
Testgeräte zur Prüfung, ob die netzweite Filterung greift
// Grundlagen
DNS (Domain Name System)
Das DNS ist das Adressbuch des Internets. Es übersetzt einen Domainnamen wie www.beispiel.de in die zugehörige IP-Adresse, die ein Gerät zum Verbindungsaufbau braucht.
DHCP (Dynamic Host Configuration Protocol)
Ein Dienst, der Geräten im Netz automatisch eine IP-Adresse, das Gateway und den DNS-Server zuweist. In unserem Projekt bleibt DHCP auf der Fritz!Box.
Statische IP-Adresse
Eine fest vergebene IP-Adresse, die sich nicht ändert. Ein Server wie Pi-hole braucht sie, damit er immer unter derselben Adresse (hier 192.168.188.33) erreichbar ist.
Pi-hole
Eine kostenlose Software, die als DNS-Server arbeitet und Anfragen an bekannte Werbe- und Tracking-Domains blockiert, statt sie aufzulösen.
DNS-Sinkhole
Das Prinzip hinter Pi-hole: Anfragen an unerwünschte Domains werden ins Leere geleitet (auf eine nicht existierende bzw. Null-Adresse), sodass keine Verbindung entsteht.
Cloudflare (1.1.1.1 / 1.0.0.1)
Ein schneller, öffentlicher DNS-Anbieter. Pi-hole leitet alle nicht geblockten Anfragen an Cloudflare weiter (Upstream), um sie regulär aufzulösen.
DNSSEC
Eine Erweiterung des DNS, die DNS-Antworten kryptografisch signiert. So lässt sich prüfen, ob eine Antwort echt und unverfälscht ist, und Manipulationen fallen auf.
Upstream-DNS
Der übergeordnete DNS-Server, an den Pi-hole alle erlaubten Anfragen weiterreicht, weil es selbst keine vollständige DNS-Datenbank führt. Bei uns ist das Cloudflare.
Blockliste / StevenBlack's Unified Hosts List
Eine gepflegte Liste bekannter Werbe- und Tracking-Domains. Pi-hole gleicht jede Anfrage gegen diese Liste ab und blockiert Treffer. StevenBlack ist eine bekannte, oft genutzte Standardliste.
FTL (Faster Than Light)
Die DNS- und Statistik-Engine von Pi-hole. Sie beantwortet die Anfragen und liefert die Daten für das Dashboard. Der Privacy-Mode von FTL steuert, wie detailliert Anfragen protokolliert werden.
Whitelist
Eine Ausnahmeliste. Domains, die versehentlich geblockt werden, aber gebraucht werden, trägt man hier ein, damit Pi-hole sie wieder durchlässt.
// Durchführung
01
Netzwerklage prüfen und IP des Pi ermitteln
Zuerst haben wir den Raspberry Pi 400 mit Raspberry Pi OS Lite gestartet und ins WLAN gebracht. Mit dem Befehl ifconfig haben wir uns die aktuelle Netzwerkkonfiguration angesehen. Der Pi hatte über das Interface wlan0 zunächst eine per DHCP zugewiesene, also dynamische Adresse. Das war der erste Anhaltspunkt, dass wir für einen Server-Dienst eine feste Adresse brauchen, weil eine wechselnde IP dazu führen würde, dass der DNS-Server plötzlich nicht mehr erreichbar ist.
ifconfigScreenshot: ifconfig-AusgabeIm echten Projekt steht hier der Screenshot dieses Schritts.
02
Statische IP über /etc/dhcpcd.conf einrichten
Damit der Pi immer unter derselben Adresse erreichbar ist, haben wir ihm eine statische IP-Adresse vergeben. Dazu haben wir mit dem Editor nano die Datei /etc/dhcpcd.conf geöffnet und einen Konfigurationsblock für wlan0 ergänzt. Wir haben 192.168.188.33/24 als feste Adresse, 192.168.188.1 als Router/Gateway und die DNS-Server 192.168.188.1 und 1.1.1.1 hinterlegt. Der /24 gibt das Subnetz an (255.255.255.0). Nach einem Neustart hatte der Pi zuverlässig seine feste Adresse.
sudo nano /etc/dhcpcd.conf
interface wlan0
static ip_address=192.168.188.33/24
static routers=192.168.188.1
static domain_name_servers=192.168.188.1 1.1.1.1Screenshot: /etc/dhcpcd.confIm echten Projekt steht hier der Screenshot dieses Schritts.
03
Pi-hole-Installation starten
Für die Installation haben wir das offizielle Installationsskript von Pi-hole genutzt. Der Befehl lädt das Skript per curl herunter und führt es direkt in der Shell aus. Das Skript prüft das System, installiert die nötigen Pakete und startet danach einen geführten Konfigurations-Assistenten, in dem wir alle wichtigen Einstellungen gesetzt haben.
curl -sSL https://install.pi-hole.net | bashScreenshot: curl-InstallerIm echten Projekt steht hier der Screenshot dieses Schritts.
04
Netzwerk-Interface auswählen
Im Assistenten mussten wir festlegen, über welche Netzwerkschnittstelle Pi-hole lauschen soll. Da der Pi per WLAN angebunden ist, haben wir wlan0 gewählt. So weiß Pi-hole, auf welchem Interface es DNS-Anfragen entgegennimmt.
Screenshot: Interface-AuswahlIm echten Projekt steht hier der Screenshot dieses Schritts.
05
Upstream-DNS-Anbieter festlegen (Cloudflare mit DNSSEC)
Pi-hole beantwortet geblockte Anfragen selbst, muss aber alle erlaubten Anfragen an einen übergeordneten DNS-Server weiterleiten. Als Upstream haben wir Cloudflare (1.1.1.1 / 1.0.0.1) gewählt, weil dieser Anbieter schnell ist und Datenschutz zusagt. Zusätzlich haben wir DNSSEC aktiviert, damit DNS-Antworten auf ihre Echtheit geprüft werden und Manipulationen auffallen.
Screenshot: Upstream CloudflareIm echten Projekt steht hier der Screenshot dieses Schritts.
06
Blockliste auswählen (StevenBlack)
Damit Pi-hole weiß, welche Domains es blocken soll, braucht es mindestens eine Blockliste. Wir haben StevenBlack's Unified Hosts List mit Yes bestätigt. Diese Liste ist gut gepflegt, weit verbreitet und deckt die gängigen Werbe- und Tracking-Domains ab. Jede DNS-Anfrage wird beim Betrieb gegen diese Liste abgeglichen.
Screenshot: BlocklisteIm echten Projekt steht hier der Screenshot dieses Schritts.
07
Query-Logging aktivieren
Wir haben das Query-Logging mit Yes eingeschaltet. Damit protokolliert Pi-hole die DNS-Anfragen. Das ist für uns wichtig, um im Dashboard nachvollziehen zu können, welche Anfragen gestellt und welche geblockt wurden — genau das brauchten wir später beim Testen und bei der Fehlersuche, etwa um zu sehen, ob eine Seite fälschlich blockiert wurde.
Screenshot: Query-LoggingIm echten Projekt steht hier der Screenshot dieses Schritts.
08
Privacy-Mode von FTL setzen
Beim Privacy-Level der FTL-Engine haben wir 0 (Show everything) gewählt. In dieser Einstellung werden alle Details der Anfragen im Dashboard angezeigt. Für ein privates Lern- und Testprojekt ist die volle Sichtbarkeit sinnvoll, weil wir so genau sehen, welches Gerät welche Domain angefragt hat.
Screenshot: Privacy-ModeIm echten Projekt steht hier der Screenshot dieses Schritts.
09
Installation abschließen und Zugangsdaten sichern
Am Ende zeigt der Assistent eine Zusammenfassung an: die IPv4-Adresse des Pi (192.168.188.33) und ein automatisch generiertes Passwort für das Web-Dashboard. Diese Daten haben wir notiert. Das Admin-Dashboard ist danach unter http://192.168.188.33/admin bzw. http://pi.hole/admin erreichbar. Dort sieht man Statistiken und kann Einstellungen wie die Whitelist verwalten.
Screenshot: Installation CompleteIm echten Projekt steht hier der Screenshot dieses Schritts.
10
Fritz!Box auf den Pi als lokalen DNS-Server umstellen
Der entscheidende Schritt für die netzweite Wirkung: In der Fritz!Box haben wir unter den Netzwerk-/DNS-Einstellungen den Raspberry Pi (192.168.188.33) als lokalen DNS-Server eingetragen. Die Fritz!Box gibt diese Adresse per DHCP an alle Geräte weiter. Dadurch fragen ab sofort alle Geräte im Netz zuerst Pi-hole, das filtert und die erlaubten Anfragen an Cloudflare weiterreicht. DHCP selbst bleibt bei der Fritz!Box, Pi-hole übernimmt ausschließlich DNS.
// Probleme & Lösungen
PROBLEM
Der Raspberry Pi erhielt zunächst eine wechselnde (dynamische) IP-Adresse.
// Ursache
Beim Start bekam der Pi seine Adresse per DHCP von der Fritz!Box. Diese kann sich ändern, ein DNS-Server muss aber dauerhaft unter derselben Adresse erreichbar sein.
// Lösung
Wir haben in /etc/dhcpcd.conf eine statische IP (192.168.188.33/24) für wlan0 festgelegt. Nach dem Neustart hatte der Pi seine feste Adresse.
PROBLEM
Nach der Installation wurde im Netz weiterhin Werbung angezeigt, die Filterung griff nicht.
// Ursache
Die Fritz!Box verteilte noch ihren alten DNS-Server an die Geräte, nicht den Pi. Solange die Geräte nicht Pi-hole befragen, kann nichts gefiltert werden.
// Lösung
In der Fritz!Box haben wir den Pi (192.168.188.33) als lokalen DNS-Server eingetragen. Danach lief die Filterung netzweit.
PROBLEM
Einzelne Geräte filterten auch nach der Umstellung noch nicht.
// Ursache
Die Endgeräte hatten den alten DNS-Server bzw. alte DNS-Antworten noch im Cache gespeichert.
// Lösung
Wir haben den DNS-Cache der betroffenen Geräte geleert bzw. die Geräte neu gestartet, damit sie die neue DNS-Zuweisung der Fritz!Box übernehmen.
PROBLEM
Einzelne benötigte Webseiten funktionierten nicht mehr korrekt.
// Ursache
Die Blockliste blockte einzelne Domains, die für die betroffenen Seiten gebraucht wurden (sogenannte False Positives).
// Lösung
Wir haben die betroffenen Domains im Pi-hole-Dashboard über die Whitelist freigegeben, danach funktionierten die Seiten wieder.
// Testergebnisse
Nach der Umstellung der Fritz!Box haben wir die netzweite Wirkung mit zwei unterschiedlichen Geräten geprüft, um sicherzustellen, dass die Filterung nicht nur auf einem Betriebssystem funktioniert. Auf beiden Geräten war die Filterung ohne zusätzliche Software aktiv. Im Pi-hole-Dashboard konnten wir außerdem sehen, dass die Anfragen der Geräte tatsächlich beim Pi ankamen und geblockte Domains als solche markiert wurden. Das Projektziel wurde damit vollständig erreicht.
| Test | Gerät | Ergebnis |
|---|---|---|
| Werbung auf werbelastigen Webseiten und im Nutzungsalltag | Laptop | Werbung und Tracker wurden geblockt, ohne dass eine Browser-Erweiterung installiert war; Seiten luden sauber. |
| Werbung in Browser und Apps im WLAN | Smartphone | Auch ohne installierten Blocker deutlich weniger Werbung; geblockte Anfragen im Pi-hole-Log sichtbar. |
| Sichtbarkeit der Anfragen und Blockrate | Pi-hole-Dashboard (http://192.168.188.33/admin) | Anfragen beider Geräte wurden angezeigt, geblockte Domains klar erkennbar (Query-Logging aktiv). |
| Freigabe fälschlich geblockter Seiten | Laptop | Nach Eintrag in die Whitelist waren die betroffenen Seiten wieder normal nutzbar. |
// Ergebnis
✓ Erreicht
- ✓Der Raspberry Pi 400 läuft mit Pi-hole als zentraler DNS-Server im Heimnetz unter der festen Adresse 192.168.188.33.
- ✓Alle Geräte im Netz werden über den lokalen DNS-Eintrag der Fritz!Box automatisch gefiltert, ohne dass dort etwas installiert werden muss.
- ✓Werbe- und Tracking-Domains werden über die StevenBlack-Blockliste netzweit blockiert.
- ✓Erlaubte Anfragen werden über Cloudflare (1.1.1.1 / 1.0.0.1) mit aktiviertem DNSSEC aufgelöst.
- ✓DHCP bleibt sauber auf der Fritz!Box, Pi-hole übernimmt ausschließlich die DNS-Rolle.
- ✓Das Admin-Dashboard liefert über Query-Logging eine vollständige Übersicht der Anfragen und der Blockrate.
- ✓Die Filterung wurde auf Laptop und Smartphone erfolgreich getestet; fälschlich geblockte Seiten lassen sich per Whitelist freigeben.
✗ Bewusst offen gelassen
- ✗Pi-hole übernimmt bewusst nicht das DHCP — das bleibt bei der Fritz!Box, um die bestehende Infrastruktur nicht zu ersetzen.
- ✗Der Pi ist per WLAN (wlan0) angebunden statt per LAN-Kabel; eine kabelgebundene Anbindung wäre für einen dauerhaften Serverdienst stabiler, war im Rahmen des Projekts aber nicht vorgesehen.
- ✗Verschlüsseltes DNS zwischen Pi-hole und Endgeräten (DoH/DoT für Clients) wurde nicht eingerichtet.
- ✗Es wurde keine ausfallsichere Zweitlösung (redundanter DNS-Server) aufgebaut; fällt der Pi aus, greift die im DHCP hinterlegte zweite DNS-Adresse.
- ✗Das automatisch generierte Admin-Passwort wurde nicht auf ein eigenes, dauerhaft genutztes Passwort geändert (im Testbetrieb belassen).
// Einschränkung
Der Raspberry Pi stand nur in der Schule zur Verfügung, sodass die finale Umsetzung dort auf der echten Hardware erfolgte. Einzelne Konfigurationsschritte haben wir zuhause in einer virtuellen Maschine nachvollzogen, um Abläufe wie das Bearbeiten von /etc/dhcpcd.conf und den Pi-hole-Installationsassistenten vorzubereiten und zu verstehen. Die verbindlichen Ergebnisse und Tests stammen aus der Umsetzung auf dem Raspberry Pi.
// Reflexion
Die Arbeit im Team funktionierte sehr gut. Bereits zu Beginn teilten wir die einzelnen Aufgaben sinnvoll auf und unterstützten uns gegenseitig bei der Umsetzung. Während ein Teammitglied die Installation vorbereitete, kontrollierte das andere die Netzwerkeinstellungen und dokumentierte die einzelnen Arbeitsschritte. Durch den regelmäßigen Austausch konnten kleinere Probleme schnell erkannt und gemeinsam gelöst werden.
Besonders interessant war für uns die praktische Umsetzung eines DNS-Servers. Viele Inhalte, die zuvor nur theoretisch behandelt wurden, konnten wir im Projekt direkt anwenden und dadurch deutlich besser verstehen.
// Werbevideo
Ergänzend zur Dokumentation gehört ein kurzes Werbevideo zum Projekt. Es stellt in wenigen Sekunden augenzwinkernd den Nutzen eines netzweiten Werbeblockers dar und dient als anschaulicher Aufhänger bei der Präsentation, bevor die technischen Details erklärt werden.
// Video
Einführungs-Video zum netzweiten Werbeblocker — im echten Projekt als eingebettetes Video enthalten.
// Do's & Don'ts
✓ Do's
- ✓Dem Pi vor der Pi-hole-Installation eine statische IP geben, damit der DNS-Server dauerhaft erreichbar bleibt.
- ✓Genau prüfen, welches Interface (hier wlan0) aktiv ist, und im Assistenten dasselbe auswählen.
- ✓Das beim Abschluss angezeigte Admin-Passwort sofort notieren, es wird nur einmal gezeigt.
- ✓In der Fritz!Box den Pi als lokalen DNS-Server eintragen — sonst wirkt die Filterung nicht netzweit.
- ✓Nach der DNS-Umstellung den DNS-Cache der Testgeräte leeren oder sie neu starten.
- ✓Query-Logging aktivieren, um im Dashboard nachvollziehen zu können, was geblockt wird und was nicht.
- ✓Fälschlich blockierte, aber benötigte Seiten gezielt über die Whitelist freigeben.
✗ Don'ts
- ✗Nicht zusätzlich das DHCP von Pi-hole übernehmen lassen, wenn die Fritz!Box es schon macht — das führt zu doppeltem DHCP und Netzwerkproblemen.
- ✗Den DNS-Server nicht mit einer dynamischen IP betreiben, sonst ist er nach einer Adressänderung nicht mehr erreichbar.
- ✗Nicht vergessen, die Fritz!Box umzustellen, und dann erwarten, dass die Filterung schon greift.
- ✗Nach der Umstellung nicht erwarten, dass alle Geräte sofort filtern — der DNS-Cache muss erst geleert werden.
- ✗Nicht blind alle Blocklisten aktivieren; zu aggressive Listen erzeugen viele False Positives.
- ✗Das Standard-Passwort des Dashboards nicht dauerhaft im Produktivbetrieb belassen.
- ✗Den Pi nicht als einzige DNS-Quelle ohne Fallback einplanen, wenn Verfügbarkeit wichtig ist.
09 // FAQ
Häufige Fragen
Die häufigsten Fragen: Was ist DNS überhaupt, warum bleibt DHCP auf der Fritz!Box, was tun wenn eine Seite streikt – kurz erklärt, ohne Fachchinesisch.
Pi-hole ist ein DNS-Server, der Namensauflösung für das ganze Netz übernimmt. DNS ist quasi das Telefonbuch des Internets: Es übersetzt Namen wie beispiel.de in IP-Adressen. Fragt ein Gerät eine bekannte Werbe- oder Tracker-Domain an, gibt Pi-hole keine echte Adresse zurück – die Werbung wird gar nicht erst geladen. Alles andere reicht Pi-hole an Cloudflare (1.1.1.1) weiter.
Weil wir in der Fritz!Box den Pi (192.168.188.33) als lokalen DNS-Server eingetragen haben. Damit läuft jede DNS-Anfrage aus dem Heimnetz zuerst über Pi-hole – egal ob Laptop, Handy oder Smart-TV. Kein Plugin auf jedem einzelnen Gerät nötig.
Nein. DHCP, also die automatische Adressvergabe, bleibt bewusst auf der Fritz!Box. Pi-hole übernimmt ausschließlich DNS. So bleibt das Netz stabil, falls der Pi mal aus ist, und die Aufgaben sind sauber getrennt.
Am Anfang bekam der Pi eine dynamische IP von der Fritz!Box – die kann sich ändern. Als DNS-Server muss er aber immer unter derselben Adresse erreichbar sein, sonst weiß die Fritz!Box nicht mehr, wohin. Wir haben ihn deshalb in /etc/dhcpcd.conf fest auf 192.168.188.33/24 gelegt, mit Gateway 192.168.188.1.
Dass Werbung anfangs trotzdem durchkam. Grund: Die Fritz!Box nutzte noch den alten DNS, und die Endgeräte hatten alte Antworten im DNS-Cache zwischengespeichert. Nach dem Umstellen des DNS in der Fritz!Box und einem Neustart bzw. Leeren des Caches lief Pi-hole dann netzweit.
Dann tragen wir die Domain in die Whitelist der Pi-hole-Weboberfläche ein. Einzelne Seiten haben Bausteine geladen, die auf einer Blockliste standen – über die Whitelist geben wir genau diese wieder frei, ohne den Schutz für alles andere aufzugeben.
Über die Admin-Weboberfläche unter http://192.168.188.33/admin oder http://pi.hole/admin. Dort sieht man Live-Statistiken, blockierte Anfragen, das Query-Log und kann Block- und Whitelists pflegen. Das Admin-Passwort wird bei der Installation automatisch erzeugt.
Der Raspberry Pi stand nur in der Schule. Einzelne Konfigurationsschritte haben wir zuhause in einer VM nachvollzogen, um sie zu verstehen und vorzubereiten. Die finale, funktionierende Umsetzung lief aber komplett auf dem echten Raspberry Pi.
10 // QUELLEN & ANHANG
Quellen & Anhang
Verwendete Quellen und alle Screenshots des Projekts – zum Nachvollziehen und Nachbauen.
// Downloads
Zum Projekt gehören die vollständige Projektdokumentation als PDF, alle Screenshots und das Werbevideo – zum Nachlesen, Nachbauen und für die Abgabe.
// Beispiel-Hinweis
Projektdokumentation (PDF), Screenshot-Paket und Werbevideo — im echten Projekt als Downloads inklusive.
// Quellen
- ↗Pi-hole – Offizielle Dokumentationhttps://docs.pi-hole.net/
- ↗Pi-hole – One-Step Automated Installhttps://docs.pi-hole.net/main/basic-install/
- ↗Cloudflare 1.1.1.1 – Öffentlicher DNS-Resolverhttps://1.1.1.1/
- ↗Cloudflare Docs – 1.1.1.1 DNS-Resolverhttps://developers.cloudflare.com/1.1.1.1/
- ↗Raspberry Pi – Offizielle Dokumentationhttps://www.raspberrypi.com/documentation/
- ↗Raspberry Pi OShttps://www.raspberrypi.com/software/operating-systems/
- ↗StevenBlack – Unified Hosts List (GitHub)https://github.com/StevenBlack/hosts
- ↗AVM Fritz!Box – Anderen DNS-Server / lokalen DNS-Server verwenden (Hilfe)https://fritz.com/service/wissensdatenbank/
// Anhang · Screenshots
Alle Schritte im Bild – inkl. Netzwerkskizze, Fritz!Box und Dashboard.
ifconfig-Ausgabe
Statische IP
curl-Installer
Interface-Auswahl
Upstream Cloudflare
Blockliste
Query-Logging
Privacy-Mode
Installation Complete
Netzwerkskizze
Fritz!Box DNS
Pi-hole Upstream
Dashboard
Screenshots als Platzhalter — im echten Projekt sind hier die Original-Aufnahmen eingebunden.