Eine der Funktionen von Chromium belastet die Wurzel-DNS-Server erheblich.

Der Browser Chromium, ein aktiv entwickeltes Open-Source-Gegenstück von Google Chrome und dem neuen Microsoft Edge, hat aufgrund einer Funktion, die mit besten Absichten konzipiert wurde, ernsthafte negative Aufmerksamkeit auf sich gezogen: Sie prüft, ob der Anbieter des Nutzers nicht nicht existierende Domain-Anfragen "entführt".

Intranet Redirect Detector, der gefälschte Anfragen an zufällige "Domains" generiert, deren Existenz statistisch unwahrscheinlich ist, ist für etwa die Hälfte des gesamten Traffics verantwortlich, der von den root-DNS-Servern weltweit erhalten wird. Der Ingenieur von Verisign, Matt Thomas, veröffentlichte einen ausführlichen Post in dem APNIC-Blog, der das Problem beschreibt und dessen Umfang bewertet.

Wie eine DNS-Umsetzung normalerweise erfolgt

Diese Server sind die oberste Instanz, an die man sich wenden sollte, um .com, .net usw. aufzulösen, damit sie einem mitteilen, dass frglxrtmpuf keine Top-Level-Domain (TLD) ist.

DNS oder Domain Name System ist das System, das es Computern ermöglicht, einprägsame Domainnamen wie arstechnica.com in viel weniger benutzerfreundliche IP-Adressen wie 3.128.236.93 zu übersetzen. Ohne DNS könnte das Internet nicht in einer für Menschen benutzbaren Form existieren, was bedeutet, dass die unnötige Belastung der Infrastruktur auf höchster Ebene ein echtes Problem darstellt.

Für das Laden einer einzigen modernen Webseite kann eine unvorstellbare Anzahl von DNS-Abfragen erforderlich sein. Zum Beispiel, als wir die Startseite von ESPN analysierten, zählten wir 93 unterschiedliche Domainnamen, von a.espncdn.com bis z.motads.com. Alle sind notwendig, um die Seite vollständig zu laden!

Damit ein System mit dieser Belastung umgehen kann, das die gesamte Welt bedienen muss, wurde DNS als mehrstufige Hierarchie entworfen. An der Spitze dieser Pyramide stehen die root-Server – jede Top-Level-Domain wie .com hat ihre eigene Familie von Servern, die die oberste Instanz für jede darunterliegende Domain darstellen. Eine Stufe höher stehen diese Server selbst, von a.root-servers.net bis m.root-servers.net.

Wie oft geschieht das?

Dank der mehrstufigen Cache-Hierarchie der DNS-Infrastruktur erreichen nur sehr wenige Prozent der weltweiten DNS-Anfragen die Root-Server. Die meisten Menschen erhalten Informationen vom DNS-Resolver direkt von ihrem Anbieter. Wenn ein Gerät des Benutzers herausfinden möchte, wie man eine bestimmte Website erreicht, wird die Anfrage zunächst an den vom lokalen Anbieter verwalteten DNS-Server gesendet. Wenn der lokale DNS-Server die Antwort nicht kennt, leitet er die Anfrage an seine eigenen "Weiterleitungsserver" weiter (sofern diese angegeben sind).

Wenn weder der lokale DNS-Server des Providers noch die in seiner Konfiguration festgelegten "Weiterleitungsserver" eine zwischengespeicherte Antwort haben, wird die Anfrage direkt an den autoritativen Server der Domain weitergeleitet. über den, den Sie umzuwandeln versuchen. Im Falle domain.com bedeutet dies, dass die Anfrage an die autoritativen Server der Domain selbst gesendet wird. com, die sich an der Adresse gtld-servers.net.

Das System gtld-servers, an das die Anfrage gesendet wurde, antwortet mit einer Liste von autoritativen Nameservern für die Domain domain.com sowie mindestens einem Verknüpfungseintrag, der die IP-Adresse eines solchen Nameservers enthält. Die Antworten werden dann in einer Kettenreaktion weitergegeben – jeder Weiterleitungsserver übermittelt diese Antworten an den Server, der sie angefordert hat, bis die Antwort schließlich den Server des lokalen Anbieters und den Computer des Benutzers erreicht. Alle cachen diese Antwort, um nicht unnötig die Systeme höherer Ebenen zu beantragen.

In den meisten Fällen werden die Einträge der Nameserver für domain.com bereits auf einem dieser Weiterleitungsserver zwischengespeichert sein, sodass die Root-Server nicht betroffen sind. Aber solange wir über die uns vertraute Art von URL sprechen – die, die in eine reguläre Website umgewandelt wird. Anfragen in Chrome betreffen die Ebene über dieser, auf der Stufe der Cluster selbst root-servers.net.

Chromium und die Überprüfung der NXDomain-Entführung

Die Prüfungen von Chromium "Verwirrt dieser DNS-Server mich?" machen fast die Hälfte des gesamten Traffics aus, der das Cluster der Root-DNS-Server von Verisign erreicht.

Der Chromium-Browser, das Elternprojekt von Google Chrome, dem neuen Microsoft Edge und einer Vielzahl weniger bekannter Browser, möchte den Nutzern eine einfache Suche in einem Feld bieten, das manchmal als „Omnibox“ bezeichnet wird. Mit anderen Worten, der Benutzer gibt sowohl echte URLs als auch Suchanfragen in dasselbe Textfeld oben im Browserfenster ein. Um es noch einfacher zu machen, verlangt es auch nicht von den Benutzern, einen Teil der URL einzugeben, http:// oder https://.

So praktisch es auch sein mag, dieser Ansatz erfordert, dass der Browser versteht, was als URL und was als Suchanfrage zu betrachten ist. In den meisten Fällen ist das recht offensichtlich – zum Beispiel kann eine Zeichenfolge mit Leerzeichen keine URL sein. Aber es kann komplizierter werden, wenn man Intranets berücksichtigt – private Netzwerke, die ebenfalls private Top-Level-Domains zur Auflösung echter Websites verwenden können.

Wenn ein Benutzer im Intranet seines Unternehmens „marketing“ eingibt und im Intranet des Unternehmens eine interne Website mit diesem Namen existiert, zeigt Chromium ein Dialogfeld an, in dem der Benutzer gefragt wird, ob er nach „marketing“ suchen oder zu https://marketing. Das ist noch akzeptabel, aber viele Internetanbieter und Anbieter öffentlicher Wi-Fi-Netzwerke „stehlen“ jede versehentlich eingegebene URL, indem sie den Benutzer auf eine mit Werbebannern überladene Seite umleiten.

Zufällige Generierung

Die Entwickler von Chromium wollten nicht, dass Benutzer in normalen Netzwerken bei jeder Suche nach einem einzelnen Wort ein Dialogfeld sehen, das fragt, was sie meinten, also implementierten sie einen Test: Beim Starten des Browsers oder beim Wechsel des Netzwerks führt Chromium DNS-Anfragen für drei zufällig generierte Top-Level-Domains mit einer Länge von sieben bis fünfzehn Zeichen durch. Wenn zwei dieser Anfragen mit derselben IP-Adresse zurückgegeben werden, geht Chromium davon aus, dass das lokale Netzwerk Fehler stiehlt, NXDOMAIN, die es erhalten sollte, daher betrachtet der Browser bis auf weiteres alle eingegebenen Anfragen aus einem Wort als Suchversuche.

Leider, in Netzwerken, die nicht die DNS-Anfrageergebnisse stehlen, landen diese drei Operationen normalerweise ganz oben, bei den Root-Nameservern: Der lokale Server weiß nicht, wie er qwajuixk, daher leitet er diese Anfrage an seinen Weiterleitungsserver weiter, der dasselbe tut, bis schließlich, a.root-servers.net oder einer seiner "Brüder" gezwungen wird zu sagen: "Es tut mir leid, aber das ist nicht der Domainname."

Da es ungefähr 1,67*10^21 mögliche gefälschte Domainnamen mit einer Länge von sieben bis fünfzehn Zeichen gibt, meistens erreicht jede dieser Tests, die in einem "fairen" Netzwerk durchgeführt wurden, den Root-Server. Das macht bereits die Hälfte der gesamten Last auf den Root-DNS, wenn man den Statistiken jener Cluster glaubt, root-servers.net, die der Firma Verisign gehören.

Die Geschichte wiederholt sich.

Das ist nicht der erste Fall, in dem ein Projekt, das mit den besten Absichten ins Leben gerufen wurde, einen oder beinahe einen öffentlichen Service mit unnötigem Traffic überlastet hat – das erinnert uns sofort an die lange und traurige Geschichte von D-Link und dem NTP-Server (Network Time Protocol) von Poul-Henning Kamp aus den frühen 2000er Jahren.

Im Jahr 2005 erhielt der FreeBSD-Entwickler Poul-Henning, der auch den einzigen NTP-Server der Stratum-1-Klasse in Dänemark betrieb, eine unerwartete und hohe Rechnung für den übertragenen Traffic. Kurz gesagt, der Grund war, dass die Entwickler von D-Link die Adressen der Stratum-1-NTP-Server, einschließlich Kamps Server, in die Firmware einer Reihe von Switches, Routern und Access Points des Unternehmens eintrugen. Dies erhöhte den Traffic von Kamps Server sofort um das Neunfache, weshalb Danish Internet Exchange (der Internet-Traffic-Exchange-Punkt Dänemarks) seinen Tarif von "Kostenlos" auf "9.000 Dollar pro Jahr" änderte.

Das Problem lag nicht darin, dass es zu viele D-Link-Router gab, sondern darin, dass sie "die Hierarchie verletzten". Fast wie bei DNS sollten NTP-Server hierarchisch arbeiten – Stratum-0-Server übermitteln Informationen an Stratum-1-Server, die Informationen an Stratum-2-Server weitergeben und so weiter, hinunter durch die Hierarchie. Ein gewöhnlicher Heimrouter, Switch oder Access Point, wie die, in die D-Link die NTP-Serveradressen programmiert hat, hätte Anfragen an einen Stratum-2- oder Stratum-3-Server senden sollen.

Das Chromium-Projekt hat wahrscheinlich mit den besten Absichten das NTP-Problem im DNS-Projekt wiederholt, indem es die Root-Server des Internets mit Anfragen überflutete, die sie niemals bearbeiten sollten.

Es gibt Hoffnung auf eine baldige Lösung.

Im Chromium-Projekt gibt es ein offenes Fehler, der zur Behebung dieses Problems die standardmäßige Deaktivierung des Intranet Redirect Detectors erfordert. Man muss dem Chromium-Projekt Anerkennung zollen: Der Bug wurde entdeckt bevor, Matt Thomas von Verisign massive Aufmerksamkeit auf ihn lenkte mit seinem Post im APNIC-Blog. Der Bug wurde im Juni gemeldet, blieb jedoch bis zu Thomas' Post weitgehend unbeachtet; danach begann er, unter genauer Beobachtung zu stehen.

Es besteht die Hoffnung, dass das Problem bald behoben wird und die root DNS-Server nicht mehr täglich auf etwa 60 Milliarden falsche Anfragen reagieren müssen.

Als Werbung

Epische Server sind Windows VPS oder Linux mit leistungsstarken Prozessoren der AMD EPYC-Familie und sehr schnellen NVMe-Disks von Intel. Beeilen Sie sich, Ihre Bestellung aufzugeben!

Quelle: habr.com