Als Basis für die meisten Internet-Dienste spielt DNS eine gewichtige Rolle und hat sich im Laufe der Jahre was die Netzwerk-Konnektivität angeht kaum verändert. Das lief die ganze Zeit wie viele “alten” Dienste unverschlüsselt und ungesichert über Port 53/udp und nimand hat sich Gedanken gemacht, ob das ein Problem sein könnte.

Damals war die Welt halt noch in Ordnung. Blümchenwiese eben.

Irgendwann kamen Menschen auf die Idee, dass das ja vielleicht doch gar nicht so toll ist, dass DNS-Daten weder vor den Augen Dritter noch vor Manipulation geschützt sind. Da hat das grosse Frickeln angefangen: DNSSEC und DNS über TLS (DoT) sind zwei Dinge, die da herausgepurzelt sind und eigentlich schon ganz brauchbar.

DNSSEC sorgt dafür, dass DNS-Daten nicht mehr (so einfach) manipuliert werden können, DoT für die Verschlüsselung der Daten auf dem Transportweg.

Soweit so gut.

Eigentlich wäre das jetzt schon eine gute Grundlage, um DNS neu zu bauen bzw. zu modernisieren. An der einen oder anderen Stelle müsste noch optimiert werden, die ganzen Hersteller und Maintainer müssten sich mal einigen. Und vor allem müssten Leute geschult werden, denn gerade DNSSEC ist ein Biest! Das passiert aber nicht oder nur sehr schleppend.

Stattdessen kommen die Browser-Hersteller und Content Provider mit einem neuen Standard um’s Eck: DNS over Http. Was auf den ersten Blick total toll klingt, hat auf den Zweiten seine Misstöne:

Die Konfiguration erfolgt nicht an zentraler Stelle im Netz sondern am Endgerät

Aus der Perspektive eines Firmen- und Familien-Admins finde es immer besser, wenn ich Dinge zentral verwalten kann. Sobald ich an’s Endgerät muss, skaliert das nicht mehr so gut. Mit jedem Parameter, den ich am Endgerät setzen kann oder muss, steigt der Aufwand. Und: Je mehr User, desto mehr kann schief gehen. Und: User tun Dinge.

Ich muss dem Browserhersteller vertrauen (zum Beispiel Google)

Natürlich haben wir in den Browserhersteller ein genauso grosses Vertrauen, wie in den Hersteller unseres Betriebssystems.

Betretenes Schweigen.

Es gibt Menschen, denen ist das egal. Die reden mit Siri oder ChatGPT, klemmen allen möglichen bei Amazon gekauften Heim-Automations-Dreck an ihre Fritzbox und wissen, dass in Cookies manchmal braune Brocken sind. Find ich persönlich schwierig. Ich versuche, Angriffsflächen eher zu minimieren. Durch Wissen.

Wenn du dich und den Feind kennst, brauchst du den Ausgang von hundert Schlachten nicht zu fürchten. Wenn du dich selbst kennst, doch nicht den Feind, wirst du für jeden Sieg, den du erringst, eine Niederlage erleiden. Wenn du weder den Feind noch dich selbst kennst, wirst du in jeder Schlacht unterliegen.

Sun Tsu - Die Kunst des Krieges

Was ist, wenn Du im Chrome zum Beispiel den DoH Server Deines Vertrauens einstellst (da gibt’s ein paar), aber die Einstellung mit dem nächsten Chrome-Update überschrieben wird?

Das gleiche gilt natürlich für alle Browser-Hersteller.

Ich muss dem DoT-Anbieter vertrauen (zum Beispiel Cloudflare)

Dass man der Content Mafia nicht trauen kann, versteht sich von selbst. Der Kollege Joff Thyer hat das sehr treffend formuliert: “We live in the age of surveillance capitalism today…”, dem wäre nichts mehr hinzu zu fügen. Keine Firma “da draussen” macht Dinge aus reiner Menschenliebe, die wollen alle nur eins: Unsere Daten, die sind das neue Gold.

Und die haben alle mehr oder weniger gute “Beziehungen” zum den “Diensten” und der Urheberrechts-Plage.

Ich kann keine DNS-Basierten Content-Filter (z.B. Pihole oder AdGuard gegen Werbung und Tracking) verwenden bzw. die User können die ganz einfach umgehen

Das ist ein Problem, wenn Benutzer Dinge tun, die sie eigentlich nicht tun dürften. Wenn Dein zwölfjähriger Sohn zum Beispiel auf Youporn unterwegs ist oder wenn C&C Traffic ins Internet geht, den Du eigentlich in Adguard geblockt haben wolltest

Fazit

Manchmal ist es gut, wenn man die Namensauflösung im Browser einstellen kann. Wenn man zum Beispiel irgendwelche Restriktionen umgehen will, die einem zum Beispiel der Internet Provider oder ein autoritäres Regime auferlegt hat. Wenn man Dinge an einer Firewall vorbei tun möchte. Wenn die eigene Privatsphäre in Gefahr ist, kompromittiert zu werden. Wenn man ein Whistleblower oder sonst jemand ist, der darauf angewiesen ist, vertraulich zu kommunizieren.

Dann muss man allerdings auch im Hinterkopf behalten, dass das ganze SSL-Ding eigentlich schon lange mehr oder weniger kaputt ist, weil jede “Autorität” eine Zertifizierungsstelle betreiben kann, der ein Browser uneingeschränlt vertraut, wenn der Browser-Hersteller das so will. Und damit wäre eine System, das irgendwo zwischen dem eigenen Browser und dem Zielsystem steht und den Datenstrom abfangen kann, in der Lage, den verschlüsselten Verkehr abzufangen und mitzulesen. Aber das ist eine ganz andere Geschichte.

Für Netzwerke in Firmen, die regulieren wollen oder müssen, welche Seiten ihre Benutzer im Internet aufrufen oder für den fürsorgliche Familien-Admin, der Porno, Malware und andere fragwürdige Dinge aus seinem Heimnetz fernhalten möchte, ist DoH keine gute Wahl, denn damit lässt sich mehr oder weniger gar nicht regulieren, was aufgerufen wird.

Die Lösung: DoH-Requests ausgehend blockieren

Wenn Du wie ich weder Deinem Internet-Provider noch dem Hersteller des Internet-Routers vertraust, dann hast Du vielleicht schon eine Firewall hinter dem Plaste-Router vom Provider am Start, idealerweise mit Debian, iptables, ipset und ferm.

Das Regelwerk kannst Du dann recht simpel um ein paar mehr oder weniger dynamische Regeln erweitern, um DoH Requests (also https-Verbindungen auf einen DoH Server) zu blocken. Dazu brauchst Du eine möglichst vollständige Liste von DoH Servern, die Du per Shell-Skript periodisch in ein IPset schiebst.

Das Skript dazu:

#!/bin/bash

# create blacklist ipset to block dns over https requests
# run frequently (daily/weekly) using cron
#
# list is from https://github.com/oneoffdallas/dohservers
# you may also use https://github.com/curl/curl/wiki/DNS-over-HTTPS
# but the scrape script needs some modification to provide a usable list of hosts
#
# dj0Nz 07/2020

ipset -q create doh hash:ip
ipset flush doh

output=/tmp/doh.list
if [ -f $output ]; then
   rm $output
fi

wget -q https://raw.githubusercontent.com/oneoffdallas/dohservers/master/iplist.txt -O $output
sed -i 's/#.*$//;/^$/d' $output

while read -r line
do
   ipset -q add doh $line
done < $output

# additional:
ipset -q add doh 1.1.1.1
ipset -q add doh 1.0.0.1
ipset -q add doh 1.1.1.2
ipset -q add doh 1.0.0.2
ipset -q add doh 1.1.1.3
ipset -q add doh 1.0.0.3

Der entsprechende Abschnitt im Firewall-Regelwerk ist auch überschaubar:

# Block DoH to known public servers
mod set set doh dst proto tcp dport 443 {
  LOG log-prefix "[Firewall] DoH Block: ";
  REJECT;
}

Geht natürlich auch mit Plain iptables, da wäre das sowas wie:

-A FORWARD -p tcp --dport 443 -m set --match-set doh dst -j DROP