English
Deutsch
PolskiDNS-Level Ad-Blocking & Sicherheit: Pi-hole und AdGuard Home im UniFi-Netzwerk
Inhalt
Die Filterung von Datenverkehr auf Ebene des Domain Name Systems (DNS) stellt eine äußerst wirksame Methode dar, um Werbung, Tracking-Skripte und unerwünschte Telemetriedaten netzwerkweit zu blockieren. Die Integration eines eigenständigen DNS-Resolvers wie Pi-hole oder AdGuard Home in eine UniFi-Netzwerkarchitektur ermöglicht eine zentrale Inspektion der Namensauflösung, ohne dass Client-Software oder Browser-Erweiterungen auf den Endgeräten installiert werden müssen.
1. Multi-VLAN-DNS-Architektur im UniFi-Umfeld
Eine saubere Netzwerksegmentierung verlangt, den DNS-Resolver in ein geschütztes Management- oder Server-VLAN zu setzen (z. B. 10.0.10.0/24). Damit Endgeräte in isolierten Subnetzen – wie IoT-, Gäste- und Hauptnetzwerken – den lokalen Resolver nutzen, muss die interne IP-Adresse in den DHCP-Einstellungen des jeweiligen VLANs explizit als primärer DNS-Server konfiguriert werden.
- DHCP-DNS-Zuweisung: Im UniFi Network Controller sollte der Eintrag für den DHCP-Name-Server in jedem VLAN ausschließlich auf die IP des lokalen Resolvers verweisen anstatt auf das Standard-Gateway oder externe Anbieter.
- Inter-VLAN-Firewall-Regeln: Eine dedizierte “LAN IN”-Firewall-Regel muss Verbindungen auf TCP/UDP-Port 53 aus den Client-VLANs zum DNS-Server im Server-Subnetz gestatten, während sonstiger Inter-VLAN-Zugriff gesperrt bleibt.
2. Verschlüsselung der Upstream-Anfragen: DoH und DoT
Klassischer DNS-Datenverkehr erfolgt unverschlüsselt über UDP-Port 53 und kann von Internetanbietern (ISPs) oder Dritten mitgelesen oder manipuliert werden. Für eine geschützte Namensauflösung muss der lokale Resolver so konfiguriert werden, dass ausgehende Anfragen über verschlüsselte Protokolle an externe Upstream-Server weitergeleitet werden:
- DNS-over-TLS (DoT): Verschlüsselt Anfragen über den dedizierten TCP-Port 853 und bietet eine geringe Latenz sowie eine kryptografische Validierung autoritativer Upstream-Resolver (z. B. Cloudflare, Quad9).
- DNS-over-HTTPS (DoH): Kapselt DNS-Abfragen im standardmäßigen HTTPS-Datenverkehr auf Port 443, wodurch die Namensauflösung nicht vom normalen Webverkehr zu unterscheiden ist und Port-Sperren umgangen werden.
3. Unterbindung von DNS-Bypasses am Gateway
Zahlreiche IoT-Geräte, Streaming-Hardware und Smart-TVs ignorieren die per DHCP zugewiesenen DNS-Server und setzen stattdessen fest einprogrammierte Adressen (wie 8.8.8.8 oder 1.1.1.1) ein. Um die Filterung kompromisslos durchzusetzen, muss das UniFi-Gateway jeglichen ausgehenden DNS-Verkehr abfangen:
Konfiguration der NAT- und Firewall-Umleitung
- Abfangen von Port 53: Eine NAT-/Firewall-Regel auf dem Router muss alle Pakete aus den Client-Subnetzen an TCP/UDP-Port 53 abfangen, die nicht an die interne IP-Adresse des lokalen Resolvers gerichtet sind.
- Transparente Umleitung oder Sperrung: Die abgefangenen Pakete können entweder transparent an die interne Pi-hole-/AdGuard-Home-Instanz umgeleitet oder verworfen werden, was Applikationen zum Rückfall auf den zugewiesenen Server zwingt.
- Sperrung externer DoH-/DoT-Server: Um das Umgehen von Filtern über verschlüsselte externe Verbindungen zu unterbinden, sollten die öffentlichen IP-Adressen bekannter externer DoH-Server ausgehend in der Firewall gesperrt werden. Diese Regeln dürfen nur für die Client-Subnetze gelten, damit die verschlüsselten Upstream-Verbindungen des lokalen Resolvers selbst weiterhin zugelassen bleiben.
4. Mehrschichtige Blockierung von Telemetrie und Tracking
Die Kombination zentraler Blocklisten mit effizientem DNS-Caching reduziert unnötigen Datenverkehr im Hintergrund drastisch. Durch das Blockieren von Telemetrieanfragen von Betriebssystemen, Haushaltsgeräten und mobilen Apps auf DNS-Ebene wird Bandbreite eingespart, die Ladezeit von Webseiten verkürzt und ein hohes Datenschutzniveau im gesamten Netzwerk etabliert.
Fragen und Antworten
Wie weit trägt eine Sperrliste bekannter DoH-Server, wenn die Umleitung von Port 53 bei DNS-over-HTTPS nicht greift?
Nicht weit, und das ist die ehrliche Grenze dieses Aufbaus. Eine Liste bekannter DoH-Adressen ist gepflegte Handarbeit, sie veraltet laufend, und ein Gerät mit fest eingebautem Endpunkt hinter einem großen CDN lässt sich per IP kaum vom übrigen HTTPS-Verkehr trennen.
Verlässlich wirken drei Maßnahmen. Das Abfangen von Port 53 erfasst alle Geräte, die unverschlüsselt an fest eingetragene Server fragen. Das Sperren von Port 853 für die Client-Subnetze kostet nichts, weil DoT keinen anderen Zweck hat. Und für den Rest hilft die Frage anders gestellt: Ein IoT-VLAN ohne direkten Weg nach draußen umgeht auch keinen DNS-Filter, denn dort entscheidet die Firewall, nicht der Resolver.
Eine vierte Sache ist keine Sperre, sondern eine Absprache und deshalb leicht zu übersehen: Firefox fragt vor dem automatischen Einschalten von DoH die Canary-Domain use-application-dns.net ab. Beantwortet der lokale Resolver sie mit NXDOMAIN, verzichtet der Browser von selbst auf DoH, sofern es nicht ausdrücklich eingeschaltet wurde. Das erledigt einen verbreiteten Umgehungsweg ohne eine einzige Firewall-Regel.
Quellen
Passend dazu
