Neben den gängigen Routingprotokollen ist das Domain Name System (DNS) eines der dienstältesten Infrastrukturprotokolle des Internets. Mit einer stetig wachsenden Anzahl der Teilnehmer im gemeinsam entwickelten Internet (damals noch ARPANET, später NSFNET) stieg der manuelle Aufwand für die Pflege der Hostnamen-Datei (oft einfach "/etc/hosts" genannt). Der erste Entwurf in RFC 882 beziehungsweise RFC 883 wird im nächsten Jahr bereits 40 Jahre alt.

Althergebrachte Angriffe wie DNS Spoofing und Cache Poisoning sind heute zum Glück praktisch nicht mehr durchführbar. DNS hat seit der Einführung einige Erweiterungen erfahren. Das spricht retrospektiv für einen guten Entwurf, der offensichtlich in viele Richtungen erweiterbar ist. Heute gibt es etwa eine unüberschaubare Anzahl an Top-Level-Domains, Länderdomains in unterschiedlichen Sprachen und mit unterschiedlichen Zeichensätzen, DNS über TCP für besonders große Anfragen und Antworten und viele weitere große und kleine Erweiterungen. Auch sichern die meisten Resolver ihre Anfragen an die autoritativen Nameserver inzwischen per DNSSEC und weiteren Maßnahmen ab, um nicht mehr versehentlich gefälschte Antworten entgegenzunehmen.

DNS bildet heute zudem eine Grundlage zum Schutz vieler weiterer Anwendungsprotokolle. Hier sind vor allem HTTP für die Zertifikatausstellung für den Webzugriff und SMTP für die Absicherung der E-Mail-Kommunikation mit DMARC im Einsatz.

Während also das DNS an sich deutlich sicherer geworden ist, bleibt die unverschlüsselte Strecke zwischen Clients und Resolvern als Einfallstor für Angreifer und Schnüffler bestehen. So fließen die Daten ungeschützt per UDP. Ein bisher nicht umfassend gelöstes Problem ist daher die Privatsphäre bei DNS-Anfragen. Auch müssen die Clients den Resolvern dahingehend vertrauen können, dass diese korrekte Antworten liefern – Stichwort Schutz vor Cache Poisoning und Zensur – und die Kundendaten vertraulich behandeln, oder besser: gar nicht erst speichern.

Die DNS-Anfragen bilden die Webaktivitäten der Nutzer relativ genau ab und laden daher zum Missbrauch ein. Sei es, dass die Betreiber von DNS-Servern Anfragen speichern und zu Werbezwecken weiterverkaufen, oder dass der Provider mit den unverschlüsselt durch seine Netze fließenden Daten Schindluder betreibt. Das wichtigste Argument in dieser Diskussion bleibt daher das Vertrauen: Es stellt sich die Frage nach dem Vertrauen oder Misstrauen in den eigenen Internet-anbieter, in Vereine zum Schutz vor Zensur [1] oder Datenschutz [2] oder in große DNS-Anbieter wie Cloudflare [3], Google [4] oder Quad9 [5]. Letzterer filtert übrigens bewusst die DNS-Antworten, um Nutzer so vor schädlichen Domains zu schützen, die Malware oder Phishing beinhalten.

Selbst wenn der Anbieter des DNS-Resolvers vertrauenswürdig wäre, die Kommunikation mit diesem bleibt zunächst unverschlüsselt. Daher gibt es unterschiedliche Protokolle, um die Verbindung zwischen Client und Server zu schützen. Bereits 2016 wurde mit DNS-over-TLS (DoT) ein Protokoll definiert, das die Anfrage zur Namensauflösung mit TLS über TCP absichert. Damit ist die angefragte Domain nur für den angefragten DNS-Server sichtbar. Um mögliche Geschwindigkeitsnachteile auszugleichen, wird die TCP-Verbindung nach der Anfrage zunächst aufrechterhalten und bei der nächsten Anfrage wiederverwendet. Die Kommunikation läuft über Port 853 und ist im Netzwerk zwar verschlüsselt, aber durch den Port als DNS-Traffic erkennbar.

Neben DoT ging mit DNS-over-HTTPS (DoH) ein weiteres Verschlüsselungsverfahren an den Start. Das 2018 veröffentlichte Protokoll soll die Privatsphäre der Benutzer umfänglich schützen und dabei sogar noch weiter gehen als DoT. Die DNS-Anfrage geht dabei per HTTPS an einen Webserver, der eine entsprechende API betreibt. Bei den meisten Implementierungen können Sie dabei zwischen unterschiedlichen Antworttypen wählen. Die vermutlich am häufigsten genutzten sind "application/dns-json" und "application/dns-message". Mit "curl" können Sie auf der Kommandozeile ausprobieren, wie eine Abfrage aussehen kann:

Dabei verwenden wir "jq", um die Ausgabe etwas schöner zu formatieren. Mit "-s" unterdrücken wir noch die Statusausgabe von curl und mit "-H" geben wir den Accept-Header an und entscheiden uns in der Anfrage für eine Ausgabe in JSON. Für unser Beispiel verwenden wir den DNS-Server von Cloudflare. Natürlich können Sie hier je nach Vorliebe einen alternativen Server auswählen. Bei der Nutzung von application/dns-message erwartet der Server eine Base64-kodierte Nachricht, die einer klassischen (binären) DNS-Abfrage entspricht. Die Antwort ist auf der Konsole dann auch nicht mehr so schön anzusehen, sie enthält entsprechend der Anfrage auch Binärdaten.

Da es sich bei DoH um gewöhnliche HTTPS-Anfragen handelt, sind diese von außen auch nicht voneinander zu unterscheiden. Stellt ein Webserver sowohl Webseiteninhalte als auch DoH zur Verfügung, lassen sich Abfragen zur Namensauflösung auch in Paketfiltern oder Firewalls nicht mehr unterscheiden, solange Sie dort nicht auch die TLS-Verbindungen untersuchen.

Damit können natürlich auch hinter restriktiven Firewalls externe DNS-Quellen genutzt werden, die möglicherweise aktive DNS-Filter umgehen. Firefox hat für Benutzer in den USA bereits 2020 DoH mit Cloudflare-Servern zum Standard erklärt. In den Einstellungen des Browsers können Sie bei Interesse DoH aktivieren und auch einen alternativen Server eintragen.

Wenn Sie DoH in Ihrem Browser einschalten, bleiben die Einstellungen des Systems als Fallback erhalten. DoH funktioniert nämlich nicht, wenn Sie sich etwa in einem Hotel hinter einem Cap-

tive-Portal befinden. Normalerweise funktioniert hier die Namensauflösung per DNS, HTTP(S)-Verbindungen sind aber bis zur Anmeldung blockiert. Auch mit DoT kann es in dem Fall übrigens Probleme geben, wenn die Umleitung auf das Captive-Portal auf einem DNS-Hijacking beruht.

Es ist aber auch möglich, DoH für Angriffe auf Unternehmensnetzwerke zu verwenden. Mit JavaScript und dynamischen Anfragen (Ajax) lässt sich ein interner DoH-Server abfragen und auf diese Weise zusätzliche Informationen über das Unternehmensnetzwerk sammeln. Verhindern ließe sich dies mit entsprechenden CORS-Headern in den Antworten des DNS-Servers. Heute verwenden viele Unternehmen in ihrem Monitoring die DNS-Anfragen der Clients, um etwa den Befall mit Schadsoftware zu überprüfen. Solche Mechanismen lassen sich mit DoH nicht mehr ohne weiteres nutzen, wenn die Malware der Zukunft auch DoH gegen Standardserver von Google oder Cloudflare implementiert.

Die gängigen DNS-Server bieten bereits DoH-Schnittstellen an. Wenn Sie die Anfragen von einem Proxy-Webserver weiterleiten, können Sie diese in Ihrem normalen HTTPS-Traffic verstecken. Auch gilt: Die klassischen HTTP-Authenticate-Verfahren funktionieren nicht, um Clients vor der Benutzung des DNS-Servers zu authentifizieren. Um ein wenig Schutz für Ihren DoH-Server zu implementieren, können Sie die URL zur Abfrage individuell anpassen. Tatsächlich besteht so die Möglichkeit, in Ihrem HTTP-Proxy dann anhand der URL unterschiedliche Backend-Server anzusprechen und beispielsweise für manche Benutzer gefilterte Antworten zurückzuliefern.

Auf dem DNS-System baut unsere gesamte Internetkommunikation auf. Dabei wurde dem altbewährten Dienst längst nicht die Aufmerksamkeit zuteil, die er verdient hat. Dies änderte sich durch DoT und DoH. Der Security-Tipp in diesem Monat hat Ihnen einen Einblick in die Funktionsweise von DNS-oder-HTTPS gegeben. Innovation hat auch in diesem Fall zwei Seiten; die Vor- und Nachteile von DoH muss dabei jeder individuell bewerten. Gängige Software wie etwa Webbrowser unterstützt DoH bereits.

Damit ist es an Ihnen zu entscheiden, ob Sie weiterhin den DNS-Dienst Ihres Providers nutzen, verschlüsselt oder unverschlüsselt, oder ob Sie auf einen Anbieter mit klarem Datenschutzfokus oder gar mit Malwareschutz ausweichen. Als Administrator sollten Sie in jedem Fall ein Auge auf möglicherweise versteckten DoH-Traffic in Ihrem Netzwerk haben.