DNS over HTTPS spaziert glatt an deinen Kontrollen vorbei

Es gibt einen Weg, wie irgendetwas in deinem Netz einen Namen auflösen kann, ohne dass dein DNS-Server die Frage je hört. Keine Einstellung am Rechner geändert, keine Administratorrechte, nichts, was du in einem Log finden würdest. Die Anfrage verlässt den Rechner als ganz normale HTTPS-Anfrage über Port 443, geht an einen Resolver irgendwo im Internet und kommt mit einer Antwort zurück, die dein eigener Resolver verweigert hätte.

Die Sperrliste greift nie. Der Threat-Feed bekommt die Anfrage nie. Die Logzeile, nach der du gesucht hättest, wurde nie geschrieben.

Das Ganze heißt DNS over HTTPS, kurz DoH, und es wurde aus gutem Grund gebaut. Einfaches DNS reist im Klartext über Port 53, also können das Café, der Flughafen und dein Internetanbieter jeden Namen mitlesen, den du auflöst, und die Antworten ändern, wenn ihnen danach ist. DoH packt die Anfrage in dieselbe Verschlüsselung wie den Rest des Web und versteckt sie in der Masse. Als Privatsphäre-Maßnahme für jemanden in einem feindlichen Netz tut es genau das, was es verspricht.

Das Problem ist: Das, was es aushebelt, und das, worauf du dich verlässt, sind ein und dasselbe.

Dein Resolver ist nicht bloß ein Auflösungsdienst. Er ist ein Kontrollpunkt: wo eine als bösartig bekannte Domain mit nichts beantwortet wird, wo eine Anfrage an einen Command-Server im Log auftaucht, wo Protective DNS die Malware-Domain ablehnt, bevor die Verbindung zustande kommt. DoH nimmt die Auflösung von deinem Resolver weg und übergibt sie einem, den du nie gewählt hast, und jede Kontrolle, die du an diesen Resolver gehängt hast, geht mit.

Das ist kein Argument gegen die Verschlüsselung von DNS. Verschlüsseltes DNS ist richtig, und der letzte Abschnitt dieses Beitrags zeigt, wie man es betreibt. Es ist ein Argument darüber, wer den Resolver wählen darf, denn diese Wahl ist das ganze Spiel, und DoH wurde entworfen, um sie dir wegzunehmen und dem Browser zu geben, der App und, wenn du nicht aufpasst, dem Angreifer.

Was DoH wirklich ist

Zieh das Marketing ab, und DoH ist eine ganz normale Web-Anfrage, die zufällig eine DNS-Frage trägt.

Gewöhnliches DNS ist eine kleine Binärnachricht, über UDP oder TCP an Port 53 geschickt. DoH steckt genau diese Nachricht, oder eine JSON-Version davon, in eine HTTPS-Anfrage an einen Webserver, der das Protokoll spricht; die Antwort ist eine HTTPS-Antwort¹. Das ist die ganze Idee.

RFC 8484 hat es im Oktober 2018 standardisiert, und die Absicht war nie versteckt. Der Zweck, sagt die eigene Einleitung, sei „allowing web applications to access DNS information via existing browser APIs“¹.

Bestehende Browser-APIs. Eine Webseite. Das hat niemand Jahre später als unangenehmen Nebeneffekt entdeckt. Es steht im ersten Absatz des Standards, festgehalten als das Ziel.

Hier eine Auflösung auf die DoH-Art, von der Kommandozeile aus, gegen einen öffentlichen Resolver, die nach example.com fragt:

$ curl -s -H 'accept: application/dns-json' \
    'https://cloudflare-dns.com/dns-query?name=example.com&type=A'
{"Status":0,"TC":false,"RD":true,"RA":true,"AD":true,"CD":false,
 "Question":[{"name":"example.com","type":1}],
 "Answer":[{"name":"example.com","type":1,"TTL":146,
            "data":"23.192.228.80"}]}

Kein spezieller Client. Kein Port außer 443. Eine einzige HTTPS-Anfrage, dieselbe Form wie das Abrufen einer Webseite, und ein Name, aufgelöst von einer Maschine auf der anderen Seite der Welt, die von deinem Netz oder deinen Regeln nie gehört hat. Google betreibt denselben Endpunkt, Quad9 auch, und Dutzende weitere.

Sieh dir jetzt an, was deine Firewall sieht. Eine TLS-Verbindung zu einem Webserver auf 443, in die sie nicht hineinlesen kann, weil das der Sinn von TLS ist, und die sie nicht von den Hunderten anderen unterscheiden kann, die sich jede Sekunde zu Content Delivery Networks, Analytics und Werbung öffnen. Die DNS-Frage ist weg. Sie hat das Gebäude als Web-Verkehr verkleidet verlassen, und niemand an der Tür konnte ihr Gesicht sehen.

Es gibt drei Wege, wie ein Client eine DNS-Anfrage bewegen kann, und es lohnt sich, sie nebeneinanderzulegen, denn der Unterschied ist der ganze Beitrag.

Einfaches DNS ist lesbar und sperrbar, und genau deshalb war es leicht zu kontrollieren und leicht auszuspähen. DoT verschlüsselt die Anfrage, behält aber seinen eigenen Port, also kannst du sie an der Grenze weiter abweisen. DoH ist das eine ohne Griff: verschlüsselt wie DoT, aber auf demselben Port, den du nie schließen kannst, sodass der einzige verbleibende Hebel ist, welchen Resolver der Client gewählt hat, und um diesen Hebel geht es in diesem Beitrag.

Wer den Resolver auswählt

Das ist deshalb wichtig, weil eine moderne Maschine fünf verschiedene Dinge hat, die jeweils entscheiden können, wohin DNS geht, und du steuerst standardmäßig genau eines davon.

Das Betriebssystem fragt den Resolver, den dein Netz per DHCP oder Router Advertisements ausgeteilt hat. Der gehört dir, und es ist das Modell, von dem alles vor etwa 2019 ausging: ein Resolver, vom Netz ausgeteilt, weshalb DNS-Kontrollen auf Netzebene dreißig Jahre lang funktioniert haben.

Der Browser hat es kaputt gemacht. Firefox und Chrome liefern beide die Maschinerie mit, ihr eigenes DoH zu betreiben, zu einem Resolver, den ihr Hersteller ausgewählt hat, über deinen Kopf hinweg, und ziehen sich nur zurück, wenn sie ein verwaltetes Netz erkennen. Und eine Anwendung kann ihren eigenen DoH-Client und einen fest verdrahteten Resolver im Code tragen, zur Build-Zeit festgelegt; sie liest dein DHCP nicht und fragt nicht. Reichlich legitime Software tut das bereits.

Ein Skript auf einer Webseite ist das, was dich stutzig machen sollte, weil es überhaupt nichts Installiertes braucht. Der curl-Befehl oben ist eine einzige HTTPS-Anfrage, und ein Browser macht HTTPS-Anfragen für sein Leben gern. Ein paar Zeilen JavaScript auf irgendeiner Seite, die ein Nutzer öffnet, können Auflösungen an einen öffentlichen DoH-Endpunkt schicken, weil die großen Anbieter Cross-Origin-Anfragen absichtlich erlauben, damit Web-Apps sie nutzen können, der erklärte Zweck in RFC 8484. Die Seite, die du gerade liest, könnte gerade jetzt Namen über einen Resolver in einem anderen Land auflösen, und du würdest eine weitere HTTPS-Verbindung sehen.

Und Malware wählt ihren eigenen Resolver aus dem naheliegenden Grund: Sie will nicht, dass du siehst, wohin sie ruft. Sie trägt den Resolver im Code, erreicht ihn oft über die Adresse, sodass es keine Bootstrap-Auflösung zum Abfangen gibt, und braucht für nichts davon deine Erlaubnis.

Lies diese Spalte noch einmal. Die unteren drei brauchen keine Administratorrechte, keine geänderte Einstellung und nichts, was im Betriebssystem sichtbar wird. Die Kontrolle, die du über Jahre aufgebaut hast, ein Resolver, eine Sperrliste, ein Log, ging davon aus, dass die oberste Zeile die einzige Zeile ist. Das ist sie seit Jahren nicht mehr.

Derselbe Trick, den die Browser-Hersteller fürchteten

Der Webseiten-Fall ist weder theoretisch noch neu. So werden Protokoll-Helper missbraucht: Eine Webseite sendet Bytes, etwas weiter unten handelt danach und kann nicht erkennen, ob sie von der Seite eines Angreifers statt von einem echten Client kamen, weil sie auf der Leitung identisch sind. Bei DoH ist das Stück weiter unten ein öffentlicher Resolver, der antwortet, ohne wissen zu können, dass das anfragende JavaScript von einer Phishing-Seite kam, und dein Resolver, der mit der Sperrliste und dem Log, war nie im Pfad, um eine Meinung zu haben. Kein Loch, das durch deine Kontrollen geschlagen wird, sondern eine Straße, die um sie herum gebaut ist, gepflastert mit derselben Verschlüsselung, zu der du allen rätst.

Es ist bereits der Kanal der Malware-Autoren

Du musst dir nicht ausmalen, wie das genutzt wird. Es ist seit Jahren dokumentiert, von namentlich genannten Forschern, an echten Samples, und die Richtung ist eindeutig: vom kriminellen Bot 2019 zum staatlichen Geheimdienstwerkzeug im Jahr darauf, und seither jedes Jahr geschäftiger, mit frischen Backdoors, die noch 2026 auftauchen.

Godlua, der erste breit gemeldete Fall, war eine Linux- und Windows-Backdoor, deren Analyse festhält, sie „uses DNS over HTTPS to get the C2 name to ensure secure communication between the bots, the Web Server and the C2“². In einem Netz, das Port 53 beobachtet, ist das Auflösen deines Command-Servers ein Geschenk an den Verteidiger. Über DoH gibt es nichts zu beobachten.

Proofpoints Satz zu PsiXBot ist der zitierenswerte, ein Threat-Intelligence-Anbieter, der das Stille laut ausspricht. DoH für Command and Control zu nutzen, schrieben sie, „should be a warning shot for the cybersecurity community as there are no simple solutions to help identify an infected host or the process of receiving instructions“³. Keine einfachen Lösungen, von den Leuten, deren Job es ist, sie zu finden.

Dann hob OilRig es eine Stufe höher. Kasperskys Beschreibung ist genau die Änderung, um die es in diesem Beitrag geht: „instead of plain text requests to port 53, they would use port 443 in encrypted packets“, mit einem Tool, das „allows DoH queries to Google and Cloudflare services“⁴. Eine nationale Geheimdienstoperation, die die öffentlichen DoH-Anbieter als Rohr nutzt, um gestohlene Daten an allem vorbeizuschleusen, was das DNS beobachtete.

Und dabei blieb es nicht. Es breitete sich aus. Bis 2023 hatte ChamelGang eine C++-Linux-Backdoor, ChamelDoH, die ihren gesamten Command-Kanal über DoH führte, DNS-TXT-Anfragen an ihre eigenen Nameserver über Google und Cloudflare schickte; der Forscher, der sie fand, merkte an, dass sowohl Erkennung als auch Abwehr „become difficult“ werden, weil der verschlüsselte Transport nicht abgefangen werden kann und eine bösartige Anfrage sich nicht von einer echten unterscheiden lässt⁵. Im Dezember 2025 zerlegte CISA BRICKSTORM, eine China-nahe Backdoor, die HTTPS, WebSockets und verschachteltes TLS stapelt und „also uses DNS-over-HTTPS (DoH)“, um ihr C2 im gewöhnlichen Web-Verkehr zu vergraben⁶. Bis Februar 2026 war es schlicht Handwerk: Cisco Talos fing Dohdoor ab, das „securely sends encrypted DNS requests to Cloudflare’s DNS server over HTTPS port 443“, um seinen Command-Server zu finden, und sich per Phishing in amerikanische Schulen und Krankenhäuser hackte⁷.

So sieht es aus. Keine Technik, die ihren Moment hatte und verblasste, sondern eine, die Jahr für Jahr von mehr Händen aufgegriffen wird. Das Problem wird schlimmer, nicht besser, und eine frische Familie taucht inzwischen planmäßig auf.

Eine Eigenschaft erledigte die Arbeit in jeder einzelnen: Die Auflösung verließ den Rechner als HTTPS auf 443, und der Resolver des Verteidigers sah sie nie. Keine Schwäche, die jemand eines Tages finden könnte. Eine Funktion, die Angreifer wieder und wieder ausgeliefert haben, mehrere davon Staaten.

Und sei dir klar darüber, warum sich diese Tabelle Jahr für Jahr füllt. Jede Familie darin geht durch eine Tür, von der die Autoren von DoH gewarnt wurden, dass sie sie offen ließen, im Text des Standards selbst, und die sie trotzdem offen ließen⁸. Das war kein Versehen. Es war Kurzsichtigkeit, mit Absicht gewählt, von Leuten, zu denen ICANNs eigener Technologe gehörte. Ich nenne es also, wie es ist: In dieser Sache ist ICANN ein Wegbereiter von Cyberkriminalität. Im Text des Standards selbst gewarnt, was kaputtgehen würde, setzten ihre Leute trotzdem ihren Namen darunter, und die Tabelle oben ist, was durch die Lücke kam. Das Verbrechen ist keine Überraschung. Es ist die Rechnung für eine Entscheidung, und wessen Entscheidung das war, ist der Rest dieses Beitrags.

Und bei alldem kauft DoH nicht einmal das, was man ihm unterstellt: Schutz vor einer gefälschten Antwort. Den Sprung zu einem Resolver zu verschlüsseln, authentifiziert nicht, was der Resolver zurückgibt, und ein DoH-Server kann trotzdem einen gefälschten Record liefern. Der Standard gibt es zu und sagt, die Regel gegen nicht konfigurierte Server „does not guarantee protection against invalid data“⁹.

Der eine Mechanismus, der eine DNS-Antwort authentifiziert, ist DNSSEC, und DoH ist das nicht. Schlimmer noch, bei fast jedem Client wird DNSSEC am rekursiven Resolver validiert, nicht auf dem Gerät: Der Client vertraut einfach dem Wort des Resolvers, dass die Antwort geprüft wurde. DNSSEC hat dich also immer nur so weit geschützt, wie du dem prüfenden Resolver vertrautest, und DoHs eigentlicher Zug ist es, dieses Vertrauen einem entfernten Betreiber zu übergeben, den du nicht sehen oder prüfen kannst.

Insofern kann DoH dich eher auf einer gefälschten Seite landen lassen, nicht seltener: Die lokalen Verteidigungen, die eine gekaperte Antwort abgefangen hätten, der Protective-DNS-Feed, die eigene Filterung des Betreibers, sind genau das, worum du herumgeleitet hast, und übrig bleibt nur das Wort eines entfernten Betreibers, auf Treu und Glauben genommen.

Und nichts davon ist eine neue Idee, über die DoH aus Versehen gestolpert wäre. Bösartige Domains am Resolver zu filtern, ist genau das, was OpenDNS seit gut zwanzig Jahren tut, indem es Phishing und Malware für Millionen Nutzer blockt, bevor die Antwort sie je erreicht, und das ist das Modell, für dessen Besitz Cisco 2015 gezahlt hat¹⁰. Zwei Jahrzehnte Sicherheit auf Resolver-Ebene, die Leute schützte, die nie etwas konfiguriert haben, und DoH hat das ganze Modell mit einem Schlag ausgehöhlt: Richte die App auf ihren eigenen Resolver, und OpenDNS, oder was dein Netz sonst gewählt hat, ist nicht mehr im Pfad.

Warum die alte Antwort aufgehört hat zu funktionieren

Solange DNS auf Port 53 lebte, war die Antwort im Netz einfach. Zwing jeden Client, deinen Resolver zu nutzen, und sperre an der Grenze Port 53 ausgehend überall sonst. Eine Maschine, die nach einem externen DNS-Server griff, wurde abgewiesen, also musste sie über deinen kommen, also galten deine Kontrollen für alles. Grob, und es funktionierte.

DoH erledigt das mit einem Zug, indem es 443 nutzt. Ausgehendes 443 kannst du nicht sperren. Das ist das Web. Der Port, den du schließen würdest, um DNS durch deinen Resolver zu zwingen, ist also genau der, den du nie schließen kannst, und die Verschlüsselung, die deinen ISP am Schnüffeln hindert, hindert auch dich daran, eine DoH-Anfrage von einem Seitenaufruf zu unterscheiden.

Die zwei Dinge, mit denen du die Kontrolle zurückholen würdest, den Port schließen und den Verkehr lesen, sind beide bauartbedingt weg. Genau diese zwei auszuhebeln, in den Händen eines feindlichen Netzes, ist das, wofür DoH gebaut wurde.

Und den Verkehr zu lesen ist nicht der Ausweg, nach dem es klingt, denn es gibt nur einen Weg dahin: alles aufbrechen und inspizieren. Um das DNS in einer 443-Verbindung zu sehen, musst du jede HTTPS-Verbindung im Netz per Man-in-the-Middle abfangen, dein eigenes Root-Zertifikat auf jedes Gerät bringen und das Ganze entschlüsseln und neu verschlüsseln. Darauf greift eine wachsende Zahl von Admins jetzt zurück, um die Sichtbarkeit zurückzukratzen, die ihnen eine einzige Firewall-Regel früher umsonst gab.

Und es ist ein weit schlechterer Tausch: Du hast TLS für alles geschwächt, eine Entschlüsselungsbox in den Pfad jedes Logins und jeder Banking-Sitzung gesetzt und ein Ziel gebaut, das alles davon kompromittiert, eine Haltung, vor der US-CERT unumwunden gewarnt hat¹¹. Die verhältnismäßige Kontrolle war kaputt, also bleibt die unverhältnismäßige.

Das ist die Zwickmühle. Der Mechanismus, der einen Journalisten im Flughafen-WLAN vor einem feindlichen Netz schützt, ist derselbe, der Malware in deinem Netz vor dir schützt, und das Protokoll kann die beiden nicht auseinanderhalten. Ein Resolver, der umgangen wird, weiß nicht, ob er ein Zensor oder ein Sicherheitsteam ist. Er weiß nur, dass er ausgeschlossen wurde.

Die richtige Antwort war immer DNS over TLS

Hier kommt der Teil, der alles verrät. Um DNS zu verschlüsseln, brauchte es nichts von alldem. Das war zwei Jahre vor DoH erledigt, und zwar so, dass die Person, die das Netz betreibt, ihre Arbeit weiter machen konnte.

DNS over TLS, RFC 7858, ist von Mai 2016. Seine Kurzfassung sagt in der ersten Zeile, wofür es da ist: to „provide privacy for DNS“, eine Verschlüsselung, die „eliminates opportunities for eavesdropping and on-path tampering with DNS queries in the network“¹². Das ist der ganze Privatsphäre-Fall, erledigt: Das Café und der ISP genauso ausgesperrt wie bei DoH, weil die Anfrage Ende zu Ende verschlüsselt ist.

Und mitverfasst wurde es von Paul Hoffman, der dann auch den DoH-Standard mitverfasst hat¹. Also keine zwei rivalisierenden Lager. Dieselben Leute, die die Privatsphäre schon gelöst hatten, lösten sie noch einmal auf andere Weise.

Wer Hoffman ist, spielt eine Rolle, weil es sagt, woher das kam. Er ist kein Zuschauer im DNS: Sein Name steht auf mehr als achtzig RFCs, darunter der DNS-Terminologie-Standard, und er macht die Arbeit als Technologe bei ICANN¹³. Der Standard, der DNS auf 443 versteckte, wurde also aus dem Inneren von ICANN mitgeschrieben, der amerikanischen Instanz, die entscheidet, was in die Root kommt.

Und ICANN ist nicht der uneigennützige Verwalter, den das Wort nahelegt. Ich habe seine Bilanz getrennt dargelegt: in Kalifornien gegründet, Kalifornien verantwortlich, und bereit, seine Stellung über den Namensraum für die eigenen Zwecke zu nutzen. Das war keine Privatsphäre-Kampagne vom Rand. Es war das Establishment, das die Root hält, und traf einen Privatsphäre-Fall, den es 2016 bereits getroffen hatte, ein zweites Mal, auf eine Weise, die den Netzbetreiber entfernte.

Frag also, was der zweite Weg hinzufügte, denn Privatsphäre war es nicht.

Das einzige Kästchen, das sich geändert hat, ist das letzte. DoT läuft auf seinem eigenen Port, 853, also kann der Betreiber sehen, dass es DNS ist, und entscheiden, was damit passiert: es zum freigegebenen Resolver durchlassen, sonst abweisen. DoH legt dieselbe verschlüsselte Anfrage auf 443 und mischt sie ins Web, wo der Betreiber sie nicht herausgreifen kann.

Gleiche Privatsphäre, gleiche Verschlüsselung. Der einzige Unterschied zwischen den beiden Standards ist, ob die Person, die das Netz betreibt, ihr eigenes DNS noch sehen kann. Das ist keine Privatsphäre-Funktion. Privatsphäre kam 2016. Es ist eine Umgehungsfunktion, und es ist das Einzige, was DoH hinzufügt.

Und sie wussten es. Das ist dokumentiert, nicht gefolgert. RFC 8484s eigene Operational Considerations sagen es unverblümt: „Filtering or inspection systems that rely on unsecured transport of DNS will not function in a DNS over HTTPS environment due to the confidentiality and integrity protection provided by TLS“⁸.

Diese Systeme sind die Sicherheitswerkzeuge, die Nutzer bereits schützen: das Blocken von Malware und Command-Servern, Protective-DNS-Feeds, Jugendschutzfilter, Enterprise-Inspection. Der Standard benennt sie in seinem eigenen Text als die Dinge, die aufhören zu funktionieren. Werkzeuge kaputt zu machen, die Menschen bereits schützten, war eine Entscheidung, mit offenen Augen getroffen und standardmäßig ausgeliefert. Die Wirkung zu kennen und sich trotzdem dafür zu entscheiden, ist eine Entscheidung, für die man Rechenschaft verlangen darf.

Deshalb überlebt das Privatsphäre-Framing die Zeitleiste nicht. Sobald DoT existiert, kann Privatsphäre nicht der Grund für DoH sein, weil Privatsphäre schon erledigt war, vom selben Autor, zwei Jahre früher. Privatsphäre war also der Nebelvorhang.

Zieh ihn weg und sieh dir an, was der zweite Standard tatsächlich in Gang setzte: ein Wettrüsten. Es machte aus einer Kontrolle, die eine Firewall-Zeile war, eine dauerhafte Jagd, Resolver gegen Sperrlisten gegen frische Resolver, der Betreiber standardmäßig im Nachteil, und eine Handvoll US-Firmen mit dem Klartext am Ende davon.

Nenn das einen Nebeneffekt einer Privatsphäre-Funktion, wenn du magst. Nach der Beweislage, mit bereits ausgeliefertem DoT und dem Standard, der selbst zugibt, dass es die Filterung kaputt macht, ist es der Zweck, und Privatsphäre war das Wort, das auf die Schachtel gemalt war. Und es wurde unter diesem Wort hart vorangetrieben, von den Parteien, die profitierten.

Die Leute, die es als Privatsphäre verkauften, waren die Browser-Hersteller, und die Nutznießer waren nicht nur die Nutzer.

Darf ich fragen, warum, wenn das Ziel Privatsphäre war, die Antwort nicht der Standard für verschlüsseltes DNS war, den es schon gab und der den Betreiber im Bilde ließ, sondern ein zweiter, gebaut, damit der Betreiber es nicht sehen kann? Ich frage nicht, wer es abgezeichnet hat. Ich frage, welcher Teil von „Privatsphäre“ es verlangte, die eine Person auszuschließen, die für das Netz verantwortlich ist.

Denn das ist das eigentliche Ziel, und es ist der Netzadministrator: der Profi, der für die Sicherheit und den Schutz des Netzes verantwortlich ist, standardmäßig als Gegner behandelt. DoH entfernt nicht einmal die Überwachung, über die der Privatsphäre-Pitch klagte. Wie Bert Hubert von PowerDNS darlegte, wurde DNS „typically provided by the operator of a network“, und es standardmäßig zu einem Dritten zu verschieben ist „a net-negative for privacy for everyone“, weil dieser Dritte „gets a complete log per device of all DNS queries, in a way that can even be tracked across IP addresses“¹⁴.

Die Anfragen sind nicht versteckt. Sie werden einem US-Resolver-Betreiber statt dem Admin übergeben, und der Admin ist die einzige Partei, die entfernt wird. Die Hersteller wissen es auch. Die „detect a managed network and stand down“-Logik im nächsten Abschnitt existiert genau deshalb, weil die Voreinstellung den Admin übergeht, und sie haben den Ausschalter ausgeliefert, statt die Voreinstellung zu ändern.

Frag jetzt, wer davon profitiert, DNS am Betreiber vorbeizuleiten. Das Aushängeschild ist der Journalist im feindlichen Flughafen-WLAN, und diese Person gibt es wirklich. Die Werbe- und Tracking-Industrie gibt es auch, deren Domains an der Sperrliste eines Netzes vorbeispazieren, sobald eine App oder ein Browser sie über DoH auflöst.

Sperren auf Netzebene, der Pi-hole, die Firmen-Sperrliste, der filternde Resolver, funktioniert, indem der Name eines Trackers mit nichts beantwortet wird. DoH ist der Weg, wie der Name trotzdem beantwortet wird. Und der größte Betreiber eines öffentlichen DoH-Resolvers ist Google¹⁵, ein Werbeunternehmen, das DoH auch in seinem eigenen Browser ausliefert¹⁶.

Eine Privatsphäre-Funktion, verkauft von der Firma, die das Tracking verkauft, deren Design das Werkzeug aushebelt, das die Leute betreiben, um es zu blocken. Mach daraus, was du willst. Ich habe mir meine Meinung gebildet.

Sogar die grobe Version dieses Einwands wurde geäußert. Im Juli 2019 nominierte der britische ISP-Verband Mozilla als „Internet Villain“ für DoH, das „bypass UK filtering obligations and parental controls, undermining internet safety standards in the UK“¹⁷. Sie wählten ein ungeschicktes Ziel und einen noch schlechteren Rahmen, wurden niedergeschrien und zogen es zurück.

Zieh aber die Politik ab, und die Beobachtung darunter war richtig, und sie gilt, egal ob die umgangene Kontrolle ein Jugendschutzfilter, eine Firmen-Sperrliste oder ein Pi-hole im Abstellzimmer ist. DoH ist dafür gebaut, DNS an dem vorbeizubringen, der das Netz betreibt.

Und das ist keine Kleinigkeit, denn DoH ist jetzt das am schwersten zu sperrende der drei. DoT sitzt auf 853, wo ein Netz es noch abweisen kann. DoH nicht, also ist es von allen Wegen, wie DNS ein Netz verlassen kann, der eine ohne Griff, was es zum größten Einzelrisiko von allen macht.

Das reicht bis ins Recht, nicht nur in die Sicherheit. In Großbritannien läuft die Sperrung mit rechtlichem Gewicht beim ISP über DNS: die Liste der Internet Watch Foundation mit Material über sexuellen Kindesmissbrauch und die Urheberrechts-Verfügungen, die der High Court nach section 97A erlässt, werden über DNS- und IP-Filterung auf dem Resolver durchgesetzt, den ein Kunde erhält¹⁸.

Leite die DNS-Hälfte davon über DoH herum, und die Sperre gilt für diesen Client nicht. Ein Gericht kann anordnen, eine Seite zu sperren, ein Netz kann angewiesen werden, es durchzusetzen, und ein Browser, der über DoH auflöst, findet die Adresse trotzdem, über einen Kanal, den das Netz nicht sehen und nicht schließen kann. Ein Cybergesetz oder einen Gerichtsbeschluss auf Netzebene durchzusetzen, wo es immer getan wurde, wird nahezu unmöglich.

Und hier landet die Rechnung bei allen, nicht nur beim Netz. Zerbrich die verhältnismäßige Kontrolle, die chirurgische, die per Gerichtsbeschluss eine benannte Domain am Resolver sperrte, und der Staat gibt nicht auf. Er greift zu einem gröberen Instrument. Der britische Online Safety Act ist dieses Instrument: umfassende Pflichten für Plattformen, vorgeschriebene Alterskontrollen und Ofcom dahinter mit den Bußgeldern, ein Regime, das jeden Nutzer und jeden Dienst im Land betrifft¹⁹.

Ich verteidige das Gesetz nicht. Ich zeige, woher der Druck dafür kam. Wenn das schmale Werkzeug, das das Recht am Netz durchsetzte, aufhört zu funktionieren, bekommst du nicht weniger Durchsetzung, du bekommst gröbere, breitere, aufdringlichere Durchsetzung, die auf alle zielt, weil die zielgenaue Version nicht mehr trägt. Das ist der Preis dafür, eine grundlegende Kontrolle zu zerbrechen, und die Leute, die sie zerbrachen, sind nicht die, die ihn zahlen.

Und ICANN ist das völlig gleichgültig, denn von Kalifornien aus ist es nicht ihr Problem. Wenn eine Sperre versagt oder eine Plattform ihre Pflichten verletzt, steht nicht ICANN vor Gericht, sondern der Betreiber, die Plattform, das Unternehmen, die sich Ofcom und den Bußgeldern stellen müssen. Die Folgen tragen alle stromabwärts einer Entscheidung, für die die Stelle, die sie traf, nie geradestehen muss.

Stell die Folgen nebeneinander, und sie haben alle dieselbe Form: etwas, das das Netz am Resolver durchsetzte und nicht mehr kann.

DoT war die ehrliche Antwort. Es verschlüsselt dein DNS und lässt den Betreiber seine Arbeit machen. DoH behielt die Verschlüsselung und legte eine Sache obendrauf: Der Betreiber kann es nicht mehr sehen. Alles andere daran folgt aus dieser einen Entscheidung.

In den USA gebaut, überall sonst ausgefochten

Nichts davon hört am Ärmelkanal auf, und es als britisches Problem zu lesen schrumpft es auf einen Bruchteil seiner Größe. Dieselbe Form läuft quer durch Europa und bis nach Australien. Ein rechtliches Instrument am einen Ende hinein, eine DNS-Sperre im Netz am anderen hinaus.

Australien lässt sein Bundesgericht den ISPs anordnen, den Zugang zu ausländischen rechtsverletzenden Seiten nach section 115A des Copyright Act zu sperren²⁰. Portugal überspringt das Gericht ganz: ein Verwaltungsmemorandum, unter dem Rechteinhaber eine Stelle namens MAPINET benachrichtigen, und die ISPs sperren per DNS binnen fünfzehn Werktagen²¹. Verschiedene Gesetze, eine tragende Annahme, und es ist die Annahme, die DoH unter ihnen allen wegtritt. Dass der Client über den Resolver auflöst, den er zugeteilt bekam.

Sieh also, was ein Staat tut, wenn diese Annahme scheitert. Er hört auf, sich auf den ISP zu stützen, und beginnt, den öffentlichen Resolvern selbst anzuordnen, die falsche Antwort zurückzugeben. Das ist keine Prognose. Es ist ein Stapel von Urteilen, und er wird höher.

Lies das als eine Sache, nicht als fünf. Ein paar US-Konzerne schrieben DNS für den ganzen Planeten aus eigener Machtvollkommenheit um, brachen die verhältnismäßige Kontrolle, die jedes dieser Länder aufgebaut hatte, und überließen es den Gerichten, herauszufinden, was mit dem Trümmerhaufen zu tun sei. Die Antworten, die diese Firmen geben, alle paar Monate vor eine andere Kammer gezerrt, sagen dir genau, was der Rest der Welt bei ihnen wiegt. Eine legt Berufung ein und schreit Zensur. Eine lässt die Auflösung scheitern und sagt dem Nutzer nichts. Und OpenDNS, der Resolver, der zwanzig Jahre lang stillschweigend Malware filterte und den dieser Beitrag bereits als das nachzuahmende Vorbild hochgehalten hat, streitet gar nicht erst. Er schaltet sich für Frankreich und für Portugal ab, statt sie zu diesen Bedingungen zu bedienen²⁶.

Bleib bei diesem Letzten. Es ist das gute Beispiel in diesem ganzen Stück, das den Raum verlässt. Der Dienst, der Menschen schützte, die nie etwas konfigurierten, findet inzwischen ein ganzes Land leichter aufzugeben als zu bedienen, und der Grund führt geradewegs zu einer Design-Entscheidung zurück, die in Kalifornien von Leuten getroffen wurde, die nie an ein französisches oder ein portugiesisches Gericht denken mussten.

Das ist das Muster, und ich benenne es. Das ist, was US-Plattform-Engineering mit allem anstellt, das nicht die Vereinigten Staaten ist. Es baut für den eigenen Markt, liefert das Ergebnis als Standard an die Welt aus und behandelt jedes andere Landesrecht, jede Aufsichtsbehörde, jede Gemeinschaft stromabwärts der Änderung als den Schlamassel, den ein anderer aufräumen soll.

Und die Heimatregierung stützt die Firmen bis zum Anschlag. Im Februar 2025 setzte das Weiße Haus seinen Namen unter ein Memorandum, das die digitalen Gesetze anderer Länder als „Erpressung aus Übersee“ amerikanischer Unternehmen brandmarkt, das Vereinigte Königreich und die EU beim Namen nennt und den Handelsbeauftragten auf Zölle als Antwort ansetzt²⁷. Sechs Monate später schrieb eine US-Behörde einem Dutzend amerikanischer Tech-Firmen und warnte, dass das Befolgen des britischen Online Safety Act oder des EU Digital Services Act selbst US-Recht brechen könnte²⁸. Lies das zweimal. Das Land, dessen Firmen die Kontrollen brachen, sagt diesen Firmen nun, dass das Befolgen der Antwort einer anderen Demokratie auf den Bruch die Straftat sei.

Das sagt alles. Ein Gesetz, das ein gewähltes Parlament in Westminster oder Brüssel verabschiedet hat, wird von Washington aus zu einem Angriff auf Amerika umgedeutet, und den Firmen wird gesagt, es zu ignorieren. Es ist nicht so, dass sie den Rest der Welt abgewogen und sich dagegen entschieden hätten. Der Rest der Welt stand nie auf der Waage.

Die Lösung ist nicht, Verschlüsselung zu verbieten

Der bequeme Schluss lautet also “DoH sperren”, und der ist falsch, genauso wie “ICMP sperren” bei der Firewall falsch ist. Du willst kein unverschlüsseltes DNS zurück. Klartext-Anfragen auf Port 53 sind ein echtes Risiko, und zu ihnen zurückzukehren, um Sichtbarkeit zurückzugewinnen, tauscht ein Loch gegen ein anderes.

Was du tatsächlich verloren hast, war nicht die Verschlüsselung. Es war die Wahl des Resolvers. Also hol dir die zurück und lass die Verschlüsselung genau da, wo sie ist.

Die Form ist dieselbe, die das DNS in einer Active-Directory-Domäne in Ordnung bringt: Das Argument ist nie “schalt die Funktion ab”, es ist “entscheide, wer sie steuern darf”. Und so sieht das im Einzelnen aus.

Betreibe verschlüsseltes DNS selbst. Stell einen Resolver auf, der DoH und DoT bedient, nicht nur Port 53, damit ein Client, der Verschlüsselung will, sie von dir bekommt. Du kannst Clients nicht „kein DoH“ sagen und es ernst meinen, während du keinen eigenen verschlüsselten Resolver anbietest. Gib ihnen einen und behalte die Sperrliste, den Threat-Feed und das Logging darauf wie zuvor.

Kündige ihn an, damit Clients ihn absichtlich finden. Discovery of Designated Resolvers (RFC 9462) lässt einen Client einen speziellen Namen abfragen, den eigenen verschlüsselten Resolver seines Netzes erfahren und automatisch auf DoH oder DoT dagegen umsteigen²⁹. Ein DDR-fähiger Client verschlüsselt dann sein DNS und nutzt deinen: die Privatsphäre, die der Nutzer wollte, und die Kontrolle, die du brauchtest, in einem Zug.

Beantworte den eingebauten Ausschalter des Browsers. Firefox prüft eine Canary-Domain, use-application-dns.net, bevor es DoH standardmäßig einschaltet: Beantworte sie mit NXDOMAIN oder SERVFAIL, und Firefox zieht sich auf den System-Resolver zurück³⁰. Zwei ehrliche Grenzen, beide in Mozillas Worten. Die Canary „only applies to users who have DoH enabled as the default option. It does not apply for users who have made the choice to turn on DoH by themselves“³⁰. Es ist also ein Standardmäßig-aus-Signal, keine Sperre, und es tut nichts gegen die App und die Malware, die den Browser nie etwas gefragt haben.

Setze die Browser-Richtlinie, wo du die Maschine verwaltest. Auf einem Gerät, das dir gehört, verlass dich nicht auf die Canary. Chromes DnsOverHttpsMode nimmt off, automatic und secure, und Googles Doku sagt, dass, wo sie nicht gesetzt ist, „for managed devices DNS-over-HTTPS queries will not be sent“³¹; Chrome schaltet sein eigenes Auto-DoH ab, sobald es eine Enterprise-Richtlinie sieht¹⁶. Richte es auf deinen Resolver, oder setze es auf off und lass DDR die Verschlüsselung tragen. Firefox hat die passenden Schalter Enabled, ProviderURL und Locked³². Verwaltete Maschine, verwaltete Entscheidung, und die Zeile, die du tatsächlich schließen kannst.

Weise die Alternativen an der Grenze ab. Die Regeln sind kurz, und sie sagen alle dasselbe: DNS jeglicher Art, nach draußen, nur von deinem Resolver.

Du wirst nicht jeden DoH-Endpunkt über die Adresse erwischen, und du kannst es nicht, weil ein neuer nur ein Webserver ist und es kein Ende der Webserver gibt. Bleib also einen Moment bei dem, was diese Sperre jetzt kostet. Um für DoH das zu tun, was block 53 outbound umsonst tat, ziehst du eine Liste von DoH-Server-Adressen, die jemand anderes für dich weiter scannt: Die gepflegten Sperrlisten existieren, weil das der einzige verbliebene Weg ist, und eine davon löst jede bekannte öffentliche DoH-Domain jede Stunde per geplantem Job auf ihre aktuellen IPs neu auf und liefert die Änderungen aus³³. Das ist der Tausch, den die Umgehung erzwungen hat.

Eine Kontrolle, die eine statische Zeile war, ist jetzt ein Abo auf ein bewegliches Ziel, eine Jagd auf Webserver, die jeder schneller aufstellen kann, als eine Liste sie benennen kann. Protective DNS schließt das andere Ende: Richte den Upstream deines Resolvers auf einen Filterdienst wie das PDNS des NCSC, das „was built to hamper the use of DNS for malware distribution and operation“³⁴, und die bösen Domains werden vor der Verbindung abgewiesen, für jeden Client, der über deinen Resolver kommt, was, sobald diese Regeln stehen, alle sind.

Stell die den fünf Zeilen von vorhin gegenüber, und jede von ihnen hat eine Kontrolle, die sie schließt. Das ist der Test einer Lösung: nicht „haben wir DoH gesperrt“, sondern „was hindert jedes Ding, das einen Resolver wählen kann, daran, den falschen zu wählen“.

Nichts davon schaltet auch nur ein Bit Verschlüsselung ab. Clients bekommen weiter DoH, sie bekommen es nur von dir, und die, die versuchen, es woanders zu bekommen, laufen gegen eine Wand. Die Privatsphäre ist intakt und die Kontrolle ist zurück. Insofern hat man einzig die Freiheit verloren, einen Resolver zu wählen, den du nie freigegeben hast, und die war in einem Netz, für das du verantwortlich bist, nie ihre.

Darf ich fragen, was diesen Resolver gewählt hat

Hier ist die Frage, die man jedem stellen sollte, der einem sagt, das Netz sei so, wie es ist, in Ordnung.

Wenn eine Maschine in deinem Netz einen Namen auflöst, was entschied, welcher Resolver antwortete? Wenn die ehrliche Antwort lautet „was auch immer das OS bekommen hat“, gut, aber nur, wenn du die anderen vier Zeilen dieser Tabelle geschlossen hast, denn sonst lautet sie „was auch immer das OS bekommen hat, es sei denn, der Browser, eine App, eine Webseite oder etwas Übleres hat anders gewählt, in welchem Fall ich keine Ahnung und keine Aufzeichnung habe“. Das ist kein DNS-Aufbau. Das ist eine Hoffnung, und Hoffnung fängt nichts.

Ich frage nicht, wer den Resolver betreibt. Ich frage, was auf jeder Maschine ihn wählen darf, und ob du den Resolver benennen könntest, zu dem gestern jede Auflösung ging. In einem Netz, in dem DoH nicht verwaltet ist, kannst du das nicht, und die Lücke ist jede App, die ihren eigenen Resolver mitbringt, jede Seite, die ein Nutzer öffnet, und jedes Stück Malware, das dieselbe Recherche gelesen hat, die ich gerade verlinkt habe. Drei namentlich genannte Bedrohungsakteure haben ihre Kanäle auf genau dieser Lücke gebaut, und einer ist einer Regierung unterstellt.

Ein Protokoll, das die Wahl des Resolvers dem Netz wegnimmt, war immer ein Geschenk an den, den das Netz zu beobachten versuchte, und so zu tun, als wäre es anders, weil das Marketing „Privatsphäre“ sagte, ist der Weg, wie eine Kontrolle, auf die es ankam, standardmäßig abgeschaltet wird und niemand den Tag protokolliert, an dem es geschah.

Verschlüssle dein DNS. Betreibe den Resolver selbst. Kündige ihn an, beantworte die Canary, setze die Richtlinie, schließe die Grenze. Behalte die Verschlüsselung und behalte die Wahl. Du kannst beides haben, und wenn du beruflich Netze betreibst, ist beides zu haben die Aufgabe.

Privatsphäre war das Wort auf der Schachtel

Also Ehre, wem Ehre gebührt. Danke an ICANN, die amerikanische Instanz, die die Root hält und das von innen mitgeschrieben hat, dafür, dass sie das US-Tech-Playbook noch einmal durchgezogen hat: Nimm ein Problem, das schon gelöst war, wickle die Lösung in ein tugendhaftes Wort und zentralisiere das Ergebnis auf eine Handvoll US-Firmen, die am Ende den Klartext halten.

Und es sind immer die USA. Die Instanz, die die Root hält, der Resolver, zu dem zwei Browser jetzt standardmäßig gehen, die Werbefirma, die den größten öffentlichen betreibt, das Land, in dem der Klartext landet: amerikanisch, jedes Mal. Es ist ein Muster, keine Pechsträhne.

Privatsphäre war der Nebelvorhang. DNS war 2016 verschlüsselt, privat und weiterhin regelbar auf Port 853, und jeder, auf den es ankam, wusste es. Was das Establishment obendrauf auslieferte, war ein Protokoll, gebaut, um die eine Person zu blenden, die für das Netz verantwortlich ist, ein dauerhaftes Wettrüsten aus stündlich neu gescannten Sperrlisten und Gerichtsbeschlüsse, die am Browser tot enden.

Ob das Unfähigkeit oder Gier war, überlasse ich dir, auch wenn die verlinkte Bilanz in eine Richtung zeigt. So oder so hat es den gesunden Menschenverstand geschlagen.

Und Entscheidungen wie diese sind der Grund, warum die Rufe, ICANN die Root wegzunehmen, immer wiederkommen, und warum sie sitzen: damit die internationale Gemeinschaft ein Mitspracherecht bekommt, statt dass die Institution eines einzigen Landes das DNS für alle anderen entscheidet und es Verwalterschaft nennt.

Früher haben wir das alles mit einer einzigen Zeile gemacht.