Zensur und Tracking umgehen
Schluss mit neugierigen Providern: Ein tiefer technischer Einblick in die autarke DNS-Namensauflösung.
Das Domain Name System (DNS) fungiert als der unsichtbare Türsteher des Internets, dem tagtäglich lückenlos das eigene Surfverhalten anvertraut wird, meist ohne dass jemals Änderungen an den Standardeinstellungen vorgenommen wurden. Diese zentrale Infrastruktur wird jedoch nicht nur zur reinen Namensauflösung genutzt, sondern zunehmend für Tracking, Zensur und Datensammlung missbraucht. Durch den Einsatz moderner Verschlüsselung, maßgeschneiderter Blocklisten und idealerweise eines selbstgehosteten DNS-Servers lässt sich nicht nur die Privatsphäre drastisch erhöhen, sondern auch das gesamte Heimnetzwerk wirkungsvoll vor Malware und Werbung abschirmen.
Die unsichtbare Schwachstelle des Internets
Im Informatikstudium lernt man, dass DNS lediglich ein Adressverzeichnis ist, welches menschenlesbare Namen wie example.com in maschinenlesbare IP-Adressen übersetzt. In der Praxis hat sich dieses System jedoch zur Achillesferse der digitalen Privatsphäre entwickelt. Wird eine Webseite aufgerufen, fragt das Endgerät zunächst bei einem DNS-Resolver nach dem Weg. In den allermeisten Heimnetzwerken ist dieser Resolver der Internetdienstanbieter (ISP) wie Vodafone oder Telekom, oder aber ein US-Gigant wie Google (8.8.8.8) beziehungsweise Cloudflare (1.1.1.1). Mit Werkzeugen wie dnscheck.tools lässt sich in Sekundenschnelle herausfinden, wem die eigenen Anfragen aktuell anvertraut werden.
Das Problem dabei ist tiefgreifend. Zwar wird durch die heutzutage allgegenwärtige HTTPS-Verschlüsselung der Inhalt der besuchten Seiten geschützt, jedoch bleibt die aufgerufene Domain im DNS-Prozess im Klartext sichtbar. Der DNS-Betreiber erfährt somit detailliert, wann welche Nachrichtenseiten, Online-Banking-Portale oder spezialisierten Foren besucht werden. Bei US-Anbietern kommt erschwerend der CLOUD Act hinzu, welcher US-Behörden den Zugriff auf gespeicherte Daten ermöglicht.
Noch kritischer wird es, wenn DNS zur aktiven Zensur eingesetzt wird. Ein eindrückliches Beispiel in Deutschland ist die Clearingstelle Urheberrecht im Internet (CUII), ein Zusammenschluss privater Internetanbieter. Diese blockierte zeitweise Webseiten per DNS-Sperre auf Basis privatwirtschaftlicher Abkommen, zunächst gänzlich ohne richterliche Anordnung. Wer DNS kontrolliert, entscheidet nicht, was wahr ist, aber er entscheidet unweigerlich, was erreichbar ist.
Verschlüsselung als erster Schutzschild
Um das Mitlesen und Manipulieren der DNS-Anfragen durch den eigenen Internetanbieter oder Hacker in offenen WLAN-Netzwerken zu unterbinden, ist Verschlüsselung unerlässlich. Bereits in einem früheren Beitrag zum Thema DNS-Privatsphäre wurde ausführlich dargelegt, wie Protokolle wie DNS-over-HTTPS (DoH) und DNS-over-TLS (DoT) diese Sicherheitslücke schließen.
Dabei wird die eigentliche DNS-Anfrage in einen verschlüsselten Tunnel gepackt. Es gibt mittlerweile hervorragende, öffentliche Projekte, die diese verschlüsselten Protokolle anbieten. Erwähnenswert ist hierbei DNS4EU, ein von der EU gefördertes Projekt, das verschiedene Filterstufen von unzensiert über Malware-Schutz bis hin zu Werbeblockern anbietet. Auch der in der Community hochgeschätzte Entwickler Hagezi betreibt öffentliche DNS-Server, die komplett in Europa gehostet werden und keinerlei Logs anlegen. Doch auch hier gilt: Die Hoheit über die Daten liegt bei einem Dritten. Vertrauen bleibt zwingend notwendig.
Die wahre Macht der DNS-Blocklisten
Betreibt man die Namensauflösung selbst, eröffnet sich ein völlig neues Maß an Kontrolle. Die Technik, die Provider zur Zensur nutzen, lässt sich nämlich exzellent zur eigenen Verteidigung umdrehen. Das Prinzip des "DNS-Sinkholing" ist trivial, aber äußerst mächtig: Fragt ein Endgerät nach der IP-Adresse einer bekannten Malware- oder Tracking-Domain (beispielsweise doubleclick.net oder der Domain eines Facebook-Tracking-Pixels), antwortet der eigene DNS-Server einfach mit einer leeren oder ungültigen Adresse (z.B. 0.0.0.0). Der Browser oder die App kann die Werbung schlichtweg nicht laden.
Der wahre Schatz in diesem Bereich sind gut gepflegte Blocklisten. Die unangefochtene Referenz hierfür sind die Hagezi Blocklisten. Anstatt pauschal das halbe Internet zu blockieren, werden hier durch aufwendige Analysen, Heuristiken und Threat-Intelligence-Feeds gezielt bösartige Akteure isoliert.
Es gibt verschiedene Eskalationsstufen dieser Listen, die sich je nach Bedarf kombinieren lassen:
- Threat Intelligence Feeds (TIF): Blockieren bekannte Botnetze, Command-and-Control-Server (C2) und Ransomware-Infrastrukturen. Hat sich ein Trojaner ins System geschlichen, scheitert der Versuch, gestohlene Daten an den Angreifer zu senden, oft genau an dieser DNS-Sperre.
- Fake & Scam: Filtert betrügerische Online-Shops und bekannte Phishing-Domains heraus. Ein Klick auf einen verseuchten Link in einer SMS läuft somit ins Leere.
- Tracker & Ads: Unterbindet das Laden von Werbebannern, Telemetrie von Betriebssystemen (wie Windows) und Verhaltens-Trackern.
- Safesearch & Jugendschutz: Optional lassen sich illegale Streaming-Seiten, Glücksspiel oder NSFW-Inhalte blockieren.
Da jeder Haushalt ein anderes Toleranzlevel für geblockte Inhalte aufweist, ist die Nutzung externer, vorgefertigter DNS-Dienste oft frustrierend, wenn legitime Seiten plötzlich nicht mehr funktionieren. Die Lösung hierfür ist die eigene Administration.
Souveränität durch den eigenen DNS-Server
Die absolute Kontrolle erlangt man erst, wenn man die Kette selbst betreibt. Ein Setup aus AdGuard Home und Unbound gilt hierbei als der Goldstandard. AdGuard Home übernimmt die Rolle des Türstehers, blockiert Tracker anhand der zuvor genannten Hagezi-Listen und bietet eine ansprechende Weboberfläche.
Doch wohin schickt AdGuard Home Anfragen, die erlaubt sind? Würde man hier wieder Google (8.8.8.8) eintragen, wäre wenig gewonnen. Hier kommt Unbound ins Spiel. Unbound ist ein rekursiver DNS-Resolver. Anstatt einen externen Dienstleister zu fragen, geht Unbound direkt zu den Wurzeln des Internets – den ICANN Root-Servern.
Der Pfad einer Anfrage nach example.de sieht dann wie folgt aus: Unbound fragt die Root-Server, wer für .de zuständig ist (die DENIC). Anschließend wird die DENIC gefragt, welcher Server example.de verwaltet. Erst dieser finale Server liefert die eigentliche IP-Adresse. Durch aggressives Caching lokaler Anfragen und "QNAME Minimisation" (es wird immer nur der minimal nötige Teil der Domain an die Zwischenstationen gesendet) wird dieses System nach wenigen Tagen nicht nur extrem privat, sondern auch pfeilschnell.
Technische Umsetzung mit AdGuard Home und Unbound
Ein solches System lässt sich idealerweise auf einem kleinen Heimserver, einem Raspberry Pi oder einer günstigen Cloud-Instanz betreiben. Mit Docker ist die Bereitstellung in wenigen Minuten erledigt.
Zunächst wird eine docker-compose.yml erstellt, welche beide Dienste miteinander verknüpft:
# M. Meister - DNS Privacy Stack
services:
adguardhome:
image: adguard/adguardhome:latest
container_name: adguardhome
restart: unless-stopped
ports:
- "53:53/tcp"
- "53:53/udp"
- "80:80/tcp" # Webinterface
- "3000:3000/tcp" # Setup
volumes:
- ./adguard/work:/opt/adguardhome/work
- ./adguard/conf:/opt/adguardhome/conf
depends_on:
- unbound
unbound:
image: mvance/unbound:latest
container_name: unbound
restart: unless-stopped
ports:
- "5053:53/tcp"
- "5053:53/udp"
volumes:
- ./unbound:/opt/unbound/etc/unbound
Im angebundenen Verzeichnis ./unbound muss nun die Konfigurationsdatei unbound.conf angelegt werden. Diese ist essenziell, um das Abfragen der Root-Server sicher und performant zu gestalten:
# M. Meister - Unbound Recursive Config
server:
verbosity: 0
interface: 0.0.0.0
port: 53
do-ip4: yes
do-udp: yes
do-tcp: yes
# Sicherheitseinstellungen
harden-glue: yes
harden-dnssec-stripped: yes
harden-algo-downgrade: yes
harden-large-queries: yes
# Privatsphäre: QNAME Minimisation
qname-minimisation: yes
# Zugriff nur aus dem lokalen Docker-Netzwerk erlauben
access-control: 127.0.0.0/8 allow
access-control: 10.0.0.0/8 allow
access-control: 172.16.0.0/12 allow
access-control: 192.168.0.0/16 allow
# Root Hints (werden vom Container automatisch aktuell gehalten)
root-hints: "/opt/unbound/etc/unbound/root.hints"
# Caching Optimierungen
cache-min-ttl: 300
cache-max-ttl: 86400
prefetch: yes
prefetch-key: yes
Nachdem der Stack mittels docker compose up -d gestartet wurde, ist das Setup-Interface von AdGuard Home über Port 3000 im Browser erreichbar. Bei der Einrichtung der sogenannten "Upstream-DNS-Server" (also wohin AdGuard erlaubte Anfragen schickt), trägt man lediglich die IP-Adresse des eigenen Unbound-Containers samt Port ein (z.B. 127.0.0.1:5053 oder die entsprechende Docker-Gateway-IP). Abschließend navigiert man im AdGuard-Menü zu den "DNS-Sperrlisten" und fügt die gewünschten URLs der Hagezi-Listen hinzu.
Wird nun die IP dieses Servers im heimischen Router als primärer DNS-Server eingetragen, profitiert das gesamte Netzwerk – vom Smart-TV bis zum Smartphone – augenblicklich von Werbefreiheit, Tracking-Schutz und maximaler Privatsphäre.
Fazit
Die Kontrolle über das Domain Name System zurückzugewinnen, ist einer der effektivsten Hebel zur Stärkung der eigenen IT-Sicherheit und Privatsphäre. Durch die Kombination aus verschlüsselter Kommunikation, den granularen Blocklisten von Hagezi und einem selbstgehosteten Resolver-Stack bestehend aus AdGuard Home und Unbound wird der unsichtbare Türsteher des Internets endlich zu einem loyalen Leibwächter. Man macht sich unabhängig von datenhungrigen Konzernen und profitiert gleichzeitig von einem spürbar schnelleren und sichereren Surferlebnis.
