DNS-Server werden nicht nur beim Surfen verwendet. Alle Dienste verwenden das DNS-System, um die IP-Adressen der Server zu ermitteln (E-Mail, Chat.... usw.)
Ein DNS-Server kennt also alle Internet Dienste und alle Webseiten, die man aufruft. Außerdem kann der DNS-Server durch Manipulation der Antworten entscheiden, welche Webseiten der Surfer sehen kann und welche Dienste man nutzen kann.
Die Möglichkeit der DNS-Manipulation zur Zensur des Internetzugangs sollte 2010 mit dem Zugangserschwerungsgesetz (ZugErschwG) genutzt werden. Alle Provider sollten eine geheime, vom BKA gelieferte Sperrliste von Domainnamen sperren und die Surfer beim Aufruf dieser Webseiten durch manipulierte DNS-Anworten auf eine Stopp-Seite umlenken. Durch zumutbare technische Maßnahmen gemäß dem Stand der Technik sollten die Provider die Nutzung alternativer, unzensierter DNS-Server verhindern.
Neben dem damaligen Innenminister Schäuble haben sich besonders Hr. v. Guttenberg und die damalige Familienministerin Ursula von der Leyen für das Gesetz engagiert. Frau v.d.Leyen wurde dafür mit dem Big Brother geehrt. Aufgrund des Widerstandes der Zivilgesellschaft wurde das ZugErschwG wieder aufgehoben.
Aktuell wird die Sperrung von Webseiten in Iran, Türkei, Ukraine. Süd Korea oder Vietnam beispw. nach diesem Muster umgesetzt und in Großbritannien gibt es konkrete Pläne für eine Zensurinfrastruktur auf Basis von DNS-Manipulationen. Für die Türkei wurde auch nachgewiesen, dass die Nutzung alternativer DNS Server blockiert wird und DNS Anfragen auf immer an kompromittierte Server umgeleitet werden. Nur verschlüsseltes DNS ermöglicht eine Umgehung der Zensur.
DNSSEC verbreitet sich langsam aber immer weiter als Sicherheitskomponente. Ein DNSSEC validierender DNS-Server kann die Echtheit der DNS Informationen anhand kryptografischer Signaturen verifizieren und damit Manipulationen erkennen und verwerfen, wenn der Domaininhaber die DNS-Daten signiert hat. Damit wird verhindert, dass Dritte die Daten manipulieren und den Surfer irgendwie umleiten (Zensur? Phishing?). Wie das konkret funktioniert, ist eine Menge Krypto-Voodoo. Nehmen wir mal an, dass es funktioniert.
DNSSEC ist außerdem die Basis, um via DANE/TLSA die SSL-Zertifikate zu verifizieren oder um mit OPENPGPKEY bzw. SMIMEA kryptografische Schlüssel sicher zu verteilen.
Im ersten Schritt ist es also ein Sicherheitsgewinn, wenn man einen DNSSEC validierenden DNS-Server verwendet. DNSSEC sichert aber nur die Auflösung der DNS-Anfragen auf dem DNS-Server, die "letzte Meile" zwischen DNS-Server und Nutzer bleibt ungeschützt.
Um diese Schwäche zu vermeiden, könnte man die DNSSEC Signaturen zusätzlich auf dem eigenen Rechner validieren:Das DNS-Protokoll enthält keine Authentifizierung die sicherstellt, dass man wirklich mit dem gewünschten DNS-Server verbunden ist. DNS-Anfragen können vom Provider auf eigene, zensierende Server umgeleitet werden, wie es zu Durchsetzung des des ZugErschwG im DFN Forschungsnetz geplant war und z. B. in der Türkei seit Jahren umgesetzt wird.
Um diese Schwächen zu vermeiden, kann man den Datenverkehr zum DNS-Server verschlüsseln. Das stellt kryptografisch sicher, dass man wirklich mit dem gewünschten Server verbunden ist (Authentifizierung) und verhindert eine Manipulation der Daten.
Die Verschlüsselung der DNS-Daten in Kombination mit ESNI (Encrypted Server Name Indication) in TLS 1.3 hat das Potential, die staatliche Infrastruktur zur Zensur des Internet in den meisten Länder auszutricksen. Aus diesem Grund versuchen einige Länder, diese technischen Entwicklungen zu blockieren:
DNScrypt ist die älteste Technik für verschlüsseltes DNS und basiert auf DNScurve von D.J. Bernstein. DNScrypt stellt mit kryptografischen Verfahren sicher, dass man wirklich den gewünschten DNS-Server verwendet und verschlüsselt die DNS Daten.
Um DNScrypt zu verwenden, muss man den dnscrypt-proxy installieren, den es für verschiedene Betriebssystem und Smartphones gibt. Nach der Installation sollte man die Konfiguration anpassen und die vertrauenswürdigen Server auswählen, standardmäßig verwendet dnscrypt-proxy auch Google und Cloudflare.
DNS-over-TLS (DoT) wurde von der IETF im Mai 2016 im RFC 7858 spezifiziert. Die meisten aktuellen Versionen der Linux DNS-Server beherrschen inzwischen DNS-over-TLS.
DNS-over-HTTPS (DoH) wurde 2016 von Google initiiert. Es dient in erster Linie der Umgehung von Zensur durch DNS Manipulation und kommt auch durch "Facist Firewalls".
Verglichen mit DNS-over-TLS ist DoH aufgrund des HTTP Overhead weniger performant. Außerdem ergeben sich durch die Nutzung des HTTP-Protokoll Implikationen für die Privatsphäre. Ein Server könnte HTTP-Auth-Header, E-Tags sowie SSL-Session-ID für das Tracking instrumentalisieren oder HTTP-Header wie User-Agent, Accept-Language usw. für das Fingerprinting des Browsers nutzen. Simples Tracking via Cookies wäre aber zu einfach. Die Cookies soll ein DoH Client ignorieren, wie die IETF in RFC 8484 schreibt.
Wenn man die Wahl hat, sollte man DNS-over-TLS statt DNS-over-HTTPS bevorzugen.
Es gibt einige Clients, die DNS-over-HTTPS sprechen können:DNS-over-QUIC (DoQ) soll die Vorteile von DoT und DoH verbinden. Statt TCP soll das QUIC Protokoll mit TLS 1.3 Verschlüsselung genutzt werden, dass auch bei HTTP/3 zum Einsatz kommen soll. DoQ soll nicht manipulierbar sein, die gleiche Privatsphäre wie DoT bieten, eine geringe Latenz wie unverschlüsseltes DNS über UDP und nicht blockierbar sein wie DoH.
Aktuell gibt es nur einen Draft der IETF und noch keine exakte Spezifikation.
DNS-over-HTTPS-over-Tor (DoHoT) kann man machen, wenn ein sinnvolles Gesamtsicherheitskonzept es erfordert. Man kann beliebigen HTTPS Traffic durch Tor tunneln, um zu verhindern, dass der/die DNS-Server die eigene IP-Adresse protokollieren kann.
Man erreicht das gleiche Ziel aber auch ohne Perfomance Einbußen, indem man einen vertrauenswürdigen DNS-Server mit No-Logging-Policy verwendet.
Abgesehen von einigen Szenarien mit höchsten Sicherheitsanforderungen, für die es schwer fällt, ein plausibles Beispiel zu konstruieren, ist DoHoT meist Overkill.
Oblivious DNS-over-HTTPS (ODoH) wurde von Cloudflare im Dez. 2020 initiert, weil es Vorbehalte in Europa gegen die Nutzung von Cloudflare als Defaut Trust-Recursive-Resolver (DoH) in Firefox gab. Derzeit läuft der Standardisierungsprozess.
Cloudflare ist nicht daran interessiert, welche Webseiten Lieschen Müller oder Pitschie Hufnagel aufrufen. Sie interessieren sich für eine globale Sicht, welche neuen Ideen gewinnen an Popularität, was ist der neue "heiße Shit" und was ist anderseits auf dem absteigenden Ast. Diese Informationen frühzeitig zu haben ist wertvoll, wie es Google mit seiner Suchmaschine demonstriert. Für Cloudfare besteht die einmalige Chance, als Default DNS-over-HTTPS Server für alle Firefox Nutzer millionenfach diese Daten zu sammeln, wenn sie die Bedenken der Privacy Community ausräumen können.
Aus technischer Sicht verwendet Oblivious DNS-over-HTTPS einfach Onion Routing mit nur einem Hop. Wenn die Betreiber der Hops nicht mit Cloudflare kooperieren, bleibt die Privatsphäre der Nutzer ähnlich gut geschützt, wie bei DoHoT mit wesentlich geringeren Einbußen bei der Performance.
Kann sein, dass ich mich täusche und ODoH ein neuer "heißer Trend" wird. Aber man muss nicht unbedingt Cloudflare DNS-Server nutzen. ;-)
Die Anmeldung für viele Wi-Fi Hotspots (zum Beispiel in Hotels, U-Bahn usw.) arbeitet in der Regel mit einer Manipulation des DNS. Auf Laptops funktioniert die DNSSEC Validierung und Verschlüsselung mit DNScrypt oder DNS-over-TLS daher an Wi-Fi Hotspots nicht.
Wer mit seinem Laptop unterwegs einen Wi-Fi Hotspot nutzen möchte, muss den DNS-Server des Hotspot Betreibers verwenden und die lokale DNSSEC Validierung abschalten.
Bei Android Smartphones und iPhones besteht dieses Problem nicht. Bei einem Wechsel des Netzwerkes wird erst der Captive Portal Check mit dem zugewiesenen DNS-Server ausgeführt und danach auf DNS-over-TLS umgeschaltet (wenn es aktiviert ist).