Eine der Funktionen von Chromium belastet stark die Root-DNS-Server.

Der Browser Chromium, der als Open-Source-Vorläufer von Google Chrome und dem neuen Microsoft Edge aktiv weiterentwickelt wird, hat aufgrund einer Funktion, die mit besten Absichten eingeführt wurde, ernsthafte negative Aufmerksamkeit erregt: Sie überprüft, ob der Anbieter des Nutzers gefälschte Ergebnisse für nicht existierende Domainanfragen zurückgibt.

Intranet Redirect Detector, der gefälschte Anfragen an zufällige "Domains" erzeugt, deren Existenz statistisch unwahrscheinlich ist, ist für etwa die Hälfte des gesamten Traffics verantwortlich, der von den Root-DNS-Servern weltweit empfangen wird. Der Ingenieur von Verisign, Matt Thomas, hat einen ausführlichen Beitrag Blogbeitrag bei APNIC verfasst, in dem er das Problem und den Umfang beschreibt.

Wie normalerweise eine DNS-Umwandlung durchgeführt wird

Diese Server sind die höchste Instanz, die zur Auflösung von .com, .net und ähnlichen Domains kontaktiert werden sollte, um zu erfahren, dass frglxrtmpuf keine Top-Level-Domain (TLD) ist.

DNS, oder das Domain Name System ("Namenssystem für Domains") ist ein System, das es Computern ermöglicht, einprägsame Domainnamen wie arstechnica.com in viel weniger benutzerfreundliche IP-Adressen wie 3.128.236.93 umzuwandeln. Ohne DNS könnte das Internet nicht in einer für Menschen nutzbaren Form existieren, weshalb die unnötige Belastung der Infrastruktur auf der obersten Ebene ein ernsthaftes Problem darstellt.

Für das Laden einer einzigen modernen Webseite kann eine unvorstellbare Anzahl von DNS-Abfragen erforderlich sein. Zum Beispiel haben wir bei der Analyse der Homepage von ESPN 93 verschiedene Domainnamen gezählt, von a.espncdn.com bis z.motads.com. Alle sind notwendig, um die Seite vollständig zu laden!

Damit ein solches System die Belastung bewältigen kann, das die gesamte Welt bedienen muss, ist DNS als mehrstufige Hierarchie konzipiert. An der Spitze dieser Pyramide stehen die Root-Server – jede Top-Level-Domain, wie .com, hat ihre eigene Familie von Servern, die die höchste Instanz für jede darunterliegende Domain darstellen. Eine Stufe höher stehen diese Server, von a.root-servers.net bis zu m.root-servers.net.

Wie oft passiert das?

Dank der mehrstufigen Cache-Hierarchie der DNS-Infrastruktur erreichen nur sehr wenige DNS-Anfragen weltweit die Root-Server. Die meisten Nutzer beziehen die Informationen vom DNS-Resolver direkt von ihrem Anbieter. Wenn ein Gerät des Nutzers herausfinden möchte, wie es zu einer bestimmten Website gelangt, wird die Anfrage zunächst an den DNS-Server gesendet, der von diesem lokalen Anbieter verwaltet wird. Falls der lokale DNS-Server keine Antwort hat, leitet er die Anfrage an seine eigenen "Weiterleitungsserver" weiter (sofern diese angegeben sind).

Wenn weder der DNS-Server des lokalen Anbieters noch die in dessen Konfiguration angegebenen "Weiterleitungsserver" eine gecachte Antwort haben, wird die Anfrage direkt an den autoritativen Server des Domänennamens gesendet, oben den Sie zu konvertieren versuchen. Im Falle von domain.com bedeutet dies, dass die Anfrage an die autoritativen Server der Domäne selbst gesendet wird, comdie unter der Adresse zu finden sind gtld-servers.net.

System gtld-servers, auf den die Anfrage gerichtet war, gibt eine Liste der autorisierten Nameserver für die Domain domain.com zurück, sowie mindestens einen Verweis mit der IP-Adresse eines solchen Nameservers. Dann werden die Antworten weitergereicht - 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 die Systeme höherer Ebenen nicht unnötig zu belästigen.

In den meisten Fällen sind die Einträge der Nameserver für domain.com bereits auf einem dieser Weiterleitungsserver gecached, weshalb die Root-Server nicht gestört werden. Wenn wir jedoch über die uns vertraute Form der URL sprechen - die in eine normale Webseite umgewandelt wird. Die Anfragen von Chrome betreffen die Ebene oben dieses, auf der Ebene der Cluster selbst root-servers.net.

Chromium und die Überprüfung von NXDomain-Entführungen

Die Prüfungen in Chromium „Täuscht mir dieser DNS-Server?“ machen fast die Hälfte des gesamten Datenverkehrs aus, der das Cluster der Root-DNS-Server von Verisign erreicht.

Der Chromium-Browser, das Basisprojekt von Google Chrome, dem neuen Microsoft Edge und zahllosen weniger bekannten Browsern, möchte den Nutzern die Suche in einem einzigen Feld, oft als „Omnibox“ bezeichnet, erleichtern. Anders ausgedrückt: Der Nutzer kann sowohl echte URLs als auch Suchanfragen in dasselbe Textfeld oben im Browserfenster eingeben. Um die Benutzerfreundlichkeit weiter zu verbessern, fordert er den Benutzer nicht auf, einen Teil der URL einzugeben. http:// oder https://.

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

Wenn ein Nutzer in dem Intranet seines Unternehmens „marketing“ eingibt und es in diesem Intranet eine interne Webseite mit diesem Namen gibt, zeigt Chromium ein Informationsfenster an, in dem der Nutzer gefragt wird, ob er nach „marketing“ suchen oder zu https://marketing. Das ist schon akzeptabel, aber viele Internetanbieter und Betreiber öffentlicher WLAN-Netze »entführen« jede durch Schreibfehler falsche URL und leiten den Benutzer auf eine mit Werbebannern überladene Seite um.

Zufallsgenierung

Die Entwickler von Chromium wollten nicht, dass Benutzer in normalen Netzwerken bei jeder Suche eines einzelnen Begriffs ein Informationsfenster sehen, das fragt, was sie gemeint haben, weshalb sie einen Test implementiert haben: beim Starten des Browsers oder beim Wechseln des Netzwerks führt Chromium DNS-Abfragen 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ückkommen, geht Chromium davon aus, dass das lokale Netzwerk die Fehler »entführt« NXDOMAIN, die er erhalten sollte, weshalb der Browser bis auf weiteres alle eingegebenen Anfragen aus einem Wort als Suchversuche betrachtet.

Leider in Netzen, die nicht die DNS-Abfrageergebnisse entführen, werden diese drei Operationen normalerweise bis ganz nach oben zu den eigentlichen Root-Nameservern gehoben: der lokale Server weiß nicht, wie man qwajuixk, daher leitet es diese Anforderung an seinen Weiterleitungsserver weiter, der dasselbe tut, bis schließlich, a.root-servers.net oder einer seiner „Brüder“ gezwungen wird zu sagen: „Entschuldigung, aber das ist keine Domain“.

Da es ungefähr 1,67*10^21 mögliche gefälschte Domainnamen mit einer Länge von sieben bis fünfzehn Zeichen gibt, am häufigsten schafft es jeder dieser Tests, die in einem „ehrlichen“ Netzwerk durchgeführt werden, bis zum Root-Server. Das macht fast die Hälfte der gesamten Last auf den Root-DNS aus, sofern die Statistik von jenen Teilen der Cluster stammt, root-servers.netdie der Firma Verisign gehören.

Die Geschichte wiederholt sich.

Dies ist nicht der erste Fall, in dem ein mit den besten Absichten geschaffenes Projekt gescheitert ist oder fast gescheitert ist und öffentliche Ressourcen mit unnötigem Traffic belastet 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 zudem den einzigen Stratum-1 Network Time Protocol (NTP) Server in Dänemark betrieb, eine unerwartet hohe Rechnung für den übertragenen Datenverkehr. Kurz gesagt, die Ursache lag darin, dass die Entwickler von D-Link die Adressen der Stratum-1 NTP-Server, einschließlich des Servers Kampa, in die Firmware ihrer Switches, Router und Access Points integriert hatten. Dies führte sofort zu einer neunfachen Erhöhung des Datenverkehrs auf dem Server Kampa, was dazu führte, dass die Danish Internet Exchange (Dänische Internet-Traffic Exchange) den Tarif von „Kostenlos“ auf „9.000 Dollar pro Jahr“ umstellte.

Das Problem war nicht, dass es zu viele D-Link-Router gab, sondern dass sie die Subordination verletzt hatten. Ähnlich wie bei DNS müssen NTP-Server hierarchisch arbeiten – Stratum-0-Server übermitteln Informationen an Stratum-1-Server, die diese an Stratum-2-Server weitergeben, und so weiter, bis zur untersten Ebene der Hierarchie. Ein typischer Heimrouter, Switch oder Access Point wie die von D-Link, die die Adressen der NTP-Server integriert hatten, hätte Anfragen an Stratum-2- oder Stratum-3-Server senden sollen.

Das Chromium-Projekt hat, vermutlich mit den besten Absichten, das NTP-Problem im Zusammenhang mit DNS wiederholt, indem es die Root-Server des Internets mit Anfragen überflutet hat, die sie niemals hätten bearbeiten sollen.

Es gibt Hoffnung auf eine schnelle Lösung.

Im Chromium-Projekt gibt es ein offenes Fehler, das zur Behebung dieses Problems die standardmäßige Deaktivierung des Intranet Redirect Detectors erfordert. Man muss dem Chromium-Projekt Anerkennung zollen: Der Fehler wurde erkannt bevorMatt Thomas von Verisign durch seinen einzelnen Blogbeitrag bei APNIC große Aufmerksamkeit darauf lenkte. Der Fehler wurde im Juni entdeckt, blieb jedoch bis zu Thomas' Beitrag unbeachtet; danach stand er unter genauer Beobachtung.

Es besteht Hoffnung, dass das Problem bald gelöst wird, sodass die Root-DNS-Server nicht mehr täglich auf etwa 60 Milliarden gefälschte Anfragen reagieren müssen.

Im Auftrag der Werbung

Epische Server — ist Windows VPS oder Linux mit leistungsstarken AMD EPYC-Prozessoren und extrem schnellen Intel NVMe-Laufwerken. Bestellen Sie jetzt!

Quelle: habr.com