LW IT Solutions
« Blog Overview /Raspberry Pi / DNS-Level Ad-Blocking & Sicherheit: Pi-hole und AdGuard...
This post in other languages:

DNS-Level Ad-Blocking & Sicherheit: Pi-hole und AdGuard Home im UniFi-Netzwerk

DNS-Level Ad-Blocking & Sicherheit: Pi-hole und AdGuard Home im UniFi-Netzwerk
Inhalt
  1. 1. Multi-VLAN-DNS-Architektur im UniFi-Umfeld
  2. 2. Verschlüsselung der Upstream-Anfragen: DoH und DoT
  3. 3. Unterbindung von DNS-Bypasses am Gateway
  4. 4. Mehrschichtige Blockierung von Telemetrie und Tracking
  5. Quellen

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.
Multi-VLAN-DNS mit Pi-hole, NAT-Umleitung für fest eingetragene Resolver und verschlüsseltem Upstream
Den DNS-Server per DHCP zu setzen ist eine Bitte, keine Pflicht. Erst die NAT-Regel am Gateway macht eine daraus — sie schreibt jede Anfrage auf Port 53 zurück auf den Filter.

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 durch verschlüsselte externe Verbindungen zu unterbinden, sollten die öffentlichen IP-Adressen bekannter externer DoH-Server in der Firewall ausgehend gesperrt werden – allerdings nur für die Client-Subnetze, 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.

Lukas Wojcik

Lukas Wojcik

Systems architect and technology enthusiast specializing in scalable tracking solutions, GMP Stack (GA4 & GTM), and robust backend architectures. Advocate for clean code and privacy-first design.

Get in Touch

Briefly describe your project or inquiry for a tailored response. This site is protected by reCAPTCHA.

Leave a Reply

Your email address will not be published. Required fields are marked *

ALL ARTICLES & CATEGORIES

CCTV

Diese Rubrik per RSS verfolgen

Cloud & AI

Diese Rubrik per RSS verfolgen

Data Privacy

Diese Rubrik per RSS verfolgen

Digital Analytics

Diese Rubrik per RSS verfolgen

Digital Marketing

Diese Rubrik per RSS verfolgen

IT & Networks

Diese Rubrik per RSS verfolgen

Raspberry Pi

Diese Rubrik per RSS verfolgen

Smart Home

Diese Rubrik per RSS verfolgen

Web Entwicklung

Diese Rubrik per RSS verfolgen

Wordpress Hacks

Diese Rubrik per RSS verfolgen