Chromium und die Root-DNS-Server

Die APNIC zeigt, dass der Chromium-Browser mit einer unscheinbaren DNS-Probing-Technik mutmaßlich 51 % der DNS-Anfragen ausmacht. Ein Aufruf zum sorgsamen Umgang mit Ressourcen.

Wie schon öfter in meinem Blog praktiziert, beginnen wir das heutige Thema mit einem kleinen Exkurs: in der IT herrscht an vielen Stellen, zumindest früher, der Grundsatz, dass mit Ressourcen behutsam umgegangen wird. Ein gutes Beispiel dafür ist das Unix-Programm nice. Mit dem Programm ist es möglich, die niceness eines Prozesses festzulegen. Je höher der Wert eingestellt wird, desto geringer ist die Gewichtung des Prozesses. Anhand der Gewichtung weist das Betriebssystem dem Prozess entsprechende CPU-Zeit für Berechnungen zu. Je mehr CPU-Zeit der Prozess zugewiesen bekommt, desto schneller kann er eine vorgegebene Eingabe verarbeiten.

Mit nice ist es also möglich, Prozessen eine geringere Gewichtung zuzuweisen. Das macht besonders Sinn, wenn der Prozess eine hohe Arbeitslast, aber geringe Zeitpriorität hat, er also ruhig länger dauern darf. Ein Beispiel wäre das nächtliche Backup: Die Sicherung eines Servers kann somit herab gewertet werden, was dazu führt, dass das Backupprogramm die volle CPU-Zeit ausnutzen kann – sofern nichts weiter auf dem Server los ist (deswegen laufen Backups auch meist nachts). Sind allerdings andere Nutzer und Programme aktiv, wird die CPU-Zeit gemäß der Gewichtung aufgeteilt. Unix-Nutzer können also für ihre Prozesse einstellen, wie nett (= nice) sie zu den weiteren Benutzern sind.

So viel zum Grundsatz. Heute werden wir uns anschauen, dass dieses Prinzip, Ressourcen zu minimieren und andere nicht zu stören, schon durch kleine Codeblöcke massiv gestört werden kann.

Chromiums Innovation

Vor drei Tagen hat sich Matthew Thomas im Blog der APNIC, die für Asien und den Pazifik Netzwerkressourcen, darunter auch die Root-DNS-Server zur Verfügung stellt, zu Wort gemeldet. Er spricht eine interessante Beobachtung an: Eine Funktion vom Chromium-Browser verursacht 51 % des DNS-Traffics der dort verwalteten DNS-Root-Server.

Das Chromium-Projekt wurde vor über zehn Jahren bei Google ins Leben gerufen und bildet neben der eigenen Anwendung auch die Grundlage für Browser wie den Google Chrome oder neuerdings auch den Microsoft Edge. Zusammen erreicht Chromium inklusive der Derivate einen Marktanteil von über 70 %, wenn man dem W3Counter Glauben schenkt.

Chromium hat neben der drastischen Verbesserung der Geschwindigkeit auch viel Wert auf die als Omnibox bezeichnete Adressleiste gelegt. Die Funktionalität ist heute in so gut wie jedem Webbrowser vertreten, wurde zur Einführung allerdings besonders von Google beworben, da die Omnibox viele Suchresultate einblendet.

Die Omnibox...

Drückt man nach der Eingabe in der Adressleiste nun Enter, wird nicht zwangsläufig der eingegebene Begriff als URL aufgerufen: entscheidet die Omnibox, dass der Begriff wahrscheinlich keine URL ist, wird anstelle dessen eine Google-Suche durchgeführt.

Hieraus ergibt sich allerdings ein Problem: Was ist, wenn der eingegebene Begriff, zu dem die Google-Suche durchgeführt wird, in Wirklichkeit eine gültige URL ist? Beispiel "server1": die daraus resultierende URL http://server1/ kann durchaus gültig sein, wenn das DNS, eventuell in Verbindung mit einer sog. DNS-Suchdomäne (also einer automatisch angehängten Domäne bei solchen Suchbegriffen), diesen Namen auflösen kann. Dies ist nicht nur in Unternehmensnetzen verbreitet, sondern auch z. B. in FritzBox-Netzwerken. Wird hier unter Standardeinstellungen z. B. ein Computer "server1" (NetBIOS-Name) genannt, kann dieser unter http://heimpc/ erreicht werden, da intern mit DNS-Suchdomäne die Adresse http://server1.fritz.box/ entsteht, welche durch das FritzBox-DNS aufgelöst werden kann.

Damit die Nutzer weiterhin solche Seiten im Chromium öffnen können, haben sich die Entwickler etwas überlegt: führt eine solche DNS-Abfrage zur einer gültigen IP-Adresse, wird auf der Seite mit den Suchergebnissen oben vom Browser eine Leiste angezeigt, in der „Wollten Sie http://server1/ aufrufen?“ steht. Klickt man auf diesen Link, gelangt man sicher zur URL.

Clever gelöst, oder? Nicht ganz, denn können wir den DNS-Abfragen vertrauen?

... und ihre Probleme ...

Die Antwort lautet: nein. Denn oft werden DNS-Anfragen, deren Übertragung naturgemäß unverschlüsselt erfolgt, manipuliert – und das von vielen Intranets und selbst Internetprovidern. Diese Technik ist als „DNS hijacking“ bekannt und wird für unlautere als auch „gute“ Zwecke durchgeführt, um z. B. bei DNS-Anfragen, zu denen kein DNS-Eintrag (RR) hinterlegt ist, eine Suchseite anstatt einem Fehler vom Browser anzuzeigen. Solche DNS-Anfragen ohne mögliche Antwort werden standardmäßig mit NXDOMAIN beantwortet, hier wird also die NXDOMAIN-DNS-Antwort durch eine DNS-Antwort mit einer IP-Adresse für z. B. die Suchseite ausgetauscht. Dieser Sonderfall von DNS hijacking wird auch als NXDOMAIN hijacking bezeichnet.

Das führt schließlich dazu, dass Chromium bei Providern, die das einsetzen, für jeden Suchbegriff diese Hinweismeldung anzeigt.

... mit pragmatischen Lösungen

Nun setzen die Chromium-Entwickler seit 2010 auf eine eher unkonventionelle Technik, um solche Netzwerke mit eingesetzem DNS hijacking zu erkennen. Werfen wir dazu einen Blick in den Quelltext:

for (size_t i = 0; i < 3; ++i) {
    std::string url_string("http://");
    // We generate a random hostname with between 7 and 15 characters.
    const int num_chars = base::RandInt(7, 15);
    for (int j = 0; j < num_chars; ++j)
      url_string += ('a' + base::RandInt(0, 'z' - 'a'));
    GURL random_url(url_string + '/');
    // ...
}

Chromium generiert hierbei drei Testadressen, die im Grunde genommen keinen Sinn ergeben – und auch möglichst zu einer NXDOMAIN-Antwort führen sollen. Geschieht dies auch, so werden höchstwahrscheinlich alle unbekannten DNS-Anfragen nicht im Stil eines DNS Catch-All umgeleitet und es kann auf die DNS-Antworten für die Hinweisleiste vertraut werden.

Das Problem für die DNS-Root-Server

Jetzt kommen allerdings die DNS-Root-Server ins Spiel. Diese werden in der Regel bei unbekannten Adressen als erstes angefragt, da DNS-Root-Server Auskunft über die DNS-Server der Top-Level-Domains geben können. Soll also der Domainname von beispielsweise v-gar.de aufgelöst werden, wird ein DNS-Server seine Anfrage zuerst an die voreingestellten Root-Server richten und sie fragen, ob Sie bei der Adresse weiterhelfen können. Sie können zwar nicht die IP-Adresse direkt zurückgeben, aber mit der Adresse des DNS-Servers für ".de" weiterhelfen. Diese Server kennen dann den DNS-Server für "v-gar.de" und dieser kann schlussendlich sagen, ob für "v-gar.de" ein Eintrag existiert und wenn ja, welche IP-Adresse zugewiesen wurde. Das DNS ist somit hierarchisch aufgebaut.

Wir können also nun sehen, dass sich speziell bei den DNS-Root-Servern diese Anfragen anhäufen. Mich überrascht es auch, dass es 51 % des gesamten DNS-Anfrageaufkommens sind. Das ist enorm und wird konkret im erwähnten Blogartikel genauer mit Statistiken erörtert.

Ein kritischer Blick

Um nicht voreilige Schlüsse zu ziehen, sollten wir uns vor Augen führen, dass ein solcher Traffic nicht zwangsläufig durch Chromium entstehen muss. So wird auch in den Kommentaren erwähnt, dass eine ähnliche Technik von Malware verwendet wird, um zu erkennen, ob gerade versucht wird, diese zu analysieren.

Trotzdem lässt sich an diesem Beispiel gut vorführen, wie sehr eine jede Codezeile mit Bedacht gewählt werden muss. Die Einführung der Funktion war zu einer Zeit, als Chromium noch einen Marktanteil von gut 10 % hatte. In den nächsten Jahren hat sich der Code durch die Popularität des Chromes und Forks anderer Browser massiv verbreitet, sodass die Funktion auch nicht mehr einfach aus der Welt geschafft werden kann. Die Befürchtungen wurden zwar bereits im Rahmen des Codereviews geäußert, die Funktionalität war aus UI-Gründen allerdings nötig.

Auch der ursprüngliche Autor des Codes hat sich im Blogartikel mit Verständnis geäußert und erklärt, dass die Problematik besonders durch den Einsatz des DNS hijackings durch die Provider erschwert wird und mehrere Versuche seitens der Provider unternommen wurden, die Erkennung zu umgehen.

Alternativen

Aber aus heutiger Sicht gibt es verschiedene Möglichkeiten: so nennt Thomas im Blogpost unter anderem die RFCs 8020 und 7816, die darauf abzielen, NXDOMAIN-Antworten klarer zu gestalten und somit die Anzahl der nötigen Anfragen zu senken. Eine Schwierigkeit dabei ist allerdings, dass alle Beteiligten hier zuarbeiten müssen, damit die angesprochenen Aspekte so umgesetzt werden können.

Eine weitere interessante Variante lässt sich in der RFC 8806 finden, denn hier wird vorgeschlagen, gleich lokal selber einen der genannten DNS-Root-Server zu betreiben, indem man die Root-Zonen, in denen die DNS-Einträge organisiert werden, spiegelt. Hiermit ist in gewisser Weise Hilfe zur Selbsthilfe gegeben, wenn man selber die Last von den DNS-Root-Servern weglenken möchte und Erfahrung im Betrieb von DNS-Servern hat. Entscheidend hierbei: die IANA stellt die notwendigen Zonen-Dateien für den Betrieb eines DNS-Root-Servers auf deren Homepage direkt bereit, alternativ ist es sogar möglich, von ausgewählten DNS-Root-Servern wie b.root-servers.net einen direkten AXFR-Zonen-Transfer über TCP nach der RFC 5936 durchzuführen, sodass man sich ähnlich wie ein Secondary-Nameserver an die Zonen hängt. Ein entscheidender Punkt bei dieser Lösung ist nämlich, dass, wenn wir DNS-Suchdomänen außen vor lassen, die gestellten Anfragen vom Chromium allesamt Top-Level-Domains (TLDs wie .de) sind und die wenigsten dabei zu den von der ICANN zugelassenen TLDs gehören. Ein eigener Root-Server mit den Zoneninformationen kann also diese Entscheidung, ob die TLD gültig ist, also schon im eigenen Netzwerk treffen und möglicherweise schon mit NXDOMAIN antworten. Ausschließlich Anfragen mit gültiger TLD werden dann im öffentlichen Internet weiter bei den Nameservern angefragt. Auch aus Sicht des Datenschutzes eine interessante Lösung.

Hier arbeitet man allerdings in ersten Linie an den Syptomen eines anderen Problems: dem Abweichen vom DNS-Standard. Denn all dieser Aufwand ist ja ursprünglich nur notwendig, da dieses vom Standard abweichende Verhalten zu falsch positiven Abfragen führt.

Und das ist sicherlich ein weiteres Argument für DNS-over-HTTP. Ich selber bin noch nicht ganz davon überzeugt, am Betriebssystem vorbei alle Namensanfragen zur Auflösung von Domains über das HTTP(S)-Protokoll abzuwickeln, aber das ist ein Thema für einen anderen Blogpost. Solche Umstände sind jedenfalls Wasser auf die Mühlen der DoH-Verfechter.

Zusammenfassung

Ressourcen müssen auch in der IT sinnvoll eingesetzt werden. Dies ist nicht nur aus ökonomischer Sicht zu sehen, da diese sicherlich vermeidbaren DNS-Anfragen Traffic verursachen, der bei vielen Providern durch kostenpflichtiges Peering, etc. ins Geld geht. Ressourcen sollten auch sinnvoll genutzt werden, damit Innovation sich proportional zu den Fortschritten der Hardware entwickeln kann – und nicht durch unvorhergesehene Ereignisse Engpässe zustande kommen.

Ressourcen sinnvoll zu nutzen bedeutet allerdings auch, sich an vielen weiteren Stellen Gedanken bei der Entscheidungsfindung zu machen. Wer durch DNS hijacking für eine erzwungene „Komfortfunktion“ andere dazu zwingt, weitere ärgerliche Workarounds zu implementieren, kann dadurch ein Eigentor verursachen, wenn der resultierende Traffic auf Kosten der eigenen Infrastruktur geht.