Der Chromium-Browser, der florierende Open-Source-Elternteil von Google Chrome und dem neuen Microsoft Edge, hat erhebliche negative Aufmerksamkeit für eine Funktion erhalten, die mit guten Absichten gedacht war: Er prüft, ob der ISP des Benutzers nicht vorhandene Domain-Abfrageergebnisse „stiehlt“. .
, das gefälschte Abfragen für zufällige „Domänen“ erstellt, deren Existenz statistisch unwahrscheinlich ist, ist für etwa die Hälfte des gesamten Datenverkehrs verantwortlich, der weltweit von Root-DNS-Servern empfangen wird. Der Verisign-Ingenieur Matt Thomas hat einen ausführlichen Artikel geschrieben auf dem APNIC-Blog, in dem das Problem beschrieben und sein Ausmaß beurteilt wird.
Wie die DNS-Auflösung normalerweise durchgeführt wird
Diese Server sind die höchste Autorität, an die Sie sich wenden sollten, um .com, .net usw. aufzulösen, damit sie Ihnen mitteilen, dass frglxrtmpuf keine Top-Level-Domain (TLD) ist.
DNS oder Domain Name System ist ein System, mit dem Computer einprägsame Domänennamen wie arstechnica.com in weniger benutzerfreundliche IP-Adressen wie 3.128.236.93 auflösen können. Ohne DNS gäbe es das Internet nicht in einer für Menschen nutzbaren Form, sodass eine unnötige Belastung der übergeordneten Infrastruktur ein echtes Problem darstellt.
Das Laden einer einzelnen modernen Webseite kann eine unglaubliche Anzahl von DNS-Suchvorgängen erfordern. Als wir beispielsweise die Homepage von ESPN analysierten, zählten wir 93 verschiedene Domainnamen, die von a.espncdn.com bis z.motads.com reichten. Sie alle sind notwendig, damit die Seite vollständig geladen werden kann!
Um diese Art von Arbeitsbelastung für eine Suchmaschine zu bewältigen, die die ganze Welt bedienen muss, ist das DNS als mehrstufige Hierarchie konzipiert. An der Spitze dieser Pyramide stehen die Root-Server – jede Top-Level-Domain, wie z. B. .com, verfügt über eine eigene Serverfamilie, die die höchste Autorität für jede darunter liegende Domain hat. Einen Schritt nach oben diese Server sind die Root-Server selbst, von a.root-servers.net auf m.root-servers.net.
Wie oft kommt das vor?
Dank der mehrstufigen Caching-Hierarchie der DNS-Infrastruktur erreicht ein sehr kleiner Prozentsatz der weltweiten DNS-Anfragen die Root-Server. Die meisten Leute erhalten ihre DNS-Resolver-Informationen direkt von ihrem ISP. Wenn das Gerät eines Benutzers wissen muss, wie es zu einer bestimmten Website gelangt, wird zunächst eine Anfrage an einen DNS-Server gesendet, der von diesem lokalen Anbieter verwaltet wird. Kennt der lokale DNS-Server die Antwort nicht, leitet er die Anfrage an seine eigenen „Forwarder“ (sofern angegeben) weiter.
Wenn weder der DNS-Server des lokalen Anbieters noch die in seiner Konfiguration angegebenen „Weiterleitungsserver“ über eine zwischengespeicherte Antwort verfügen, wird die Anfrage direkt an den autorisierenden Domänenserver gestellt oben diejenige, die Sie konvertieren möchten. Im Fall von домен.com Dies bedeutet, dass die Anfrage an die autorisierenden Server der Domäne selbst gesendet wird com, die sich in befinden gtld-servers.net.
System gtld-servers, an den die Anfrage gestellt wurde, antwortet mit einer Liste autoritativer Nameserver für die Domain domain.com sowie mindestens einem Link-Datensatz, der die IP-Adresse eines solchen Nameservers enthält. Als nächstes bewegen sich die Antworten in der Kette nach unten – jeder Weiterleiter leitet diese Antworten an den Server weiter, der sie angefordert hat, bis die Antwort schließlich den Server des lokalen Anbieters und den Computer des Benutzers erreicht. Sie alle speichern diese Antwort zwischen, um übergeordnete Systeme nicht unnötig zu stören.
In den meisten Fällen werden Nameserver-Datensätze für domain.com wird bereits auf einem dieser Forwarder zwischengespeichert, sodass die Root-Server nicht gestört werden. Im Moment sprechen wir jedoch über die Art von URL, die wir kennen – diejenige, die in eine normale Website umgewandelt wird. Chrome-Anfragen sind auf Augenhöhe oben dies auf der Stufe der Cluster selbst root-servers.net.
Chromium- und NXDomain-Diebstahlprüfung
Chromium prüft: „Täuscht mich dieser DNS-Server?“ machen fast die Hälfte des gesamten Datenverkehrs aus, der den Root-DNS-Server-Cluster von Verisign erreicht.
Der Chromium-Browser, das übergeordnete Projekt von Google Chrome, dem neuen Microsoft Edge und unzähligen weniger bekannten Browsern, möchte Benutzern die einfache Suche in einer einzigen Box, manchmal auch „Omnibox“ genannt, ermöglichen. Mit anderen Worten: Der Benutzer gibt sowohl echte URLs als auch Suchmaschinenanfragen in dasselbe Textfeld oben im Browserfenster ein. Dies stellt einen weiteren Schritt in Richtung Vereinfachung dar und zwingt den Benutzer auch nicht dazu, einen Teil der URL einzugeben http:// oder https://.
So praktisch dies auch ist, erfordert dieser Ansatz, dass der Browser versteht, was als URL und was als Suchanfrage zu betrachten ist. In den meisten Fällen ist dies ziemlich offensichtlich – beispielsweise kann eine Zeichenfolge mit Leerzeichen keine URL sein. Schwieriger kann es jedoch werden, wenn man Intranets in Betracht zieht – private Netzwerke, die auch private Top-Level-Domains verwenden können, um echte Websites aufzulösen.
Wenn ein Benutzer im Intranet seines Unternehmens „Marketing“ eingibt und das Intranet des Unternehmens über eine interne Website mit demselben Namen verfügt, zeigt Chromium ein Informationsfeld an, in dem der Benutzer gefragt wird, ob er nach „Marketing“ suchen oder zu gehen möchte https://marketing. Dies ist möglicherweise nicht der Fall, aber viele ISPs und öffentliche WLAN-Anbieter „kapern“ jede falsch geschriebene URL und leiten den Benutzer auf eine mit Bannern gefüllte Seite weiter.
Zufällige Generation
Die Chromium-Entwickler wollten nicht, dass Benutzer in normalen Netzwerken jedes Mal, wenn sie nach einem einzelnen Wort suchen, ein Informationsfeld sehen, in dem sie gefragt werden, was sie meinen, und haben daher einen Test implementiert: Wenn sie einen Browser starten oder das Netzwerk wechseln, führt Chromium drei DNS-Suchen durch Zufällig generierte „Domains“ der obersten Ebene, sieben bis fünfzehn Zeichen lang. Wenn zwei dieser Anfragen mit derselben IP-Adresse zurückkommen, geht Chromium davon aus, dass das lokale Netzwerk die Fehler „kapert“. NXDOMAIN, die er erhalten soll, sodass der Browser bis auf Weiteres alle eingegebenen Einzelwortanfragen als Suchversuche betrachtet.
Leider ist das in Netzwerken so nicht Wenn es darum geht, die Ergebnisse von DNS-Abfragen zu stehlen, gelangen diese drei Vorgänge normalerweise ganz nach oben, bis hin zu den Root-Nameservern selbst: Der lokale Server weiß nicht, wie er auflösen soll qwajuixk, leitet diese Anfrage also an seinen Weiterleiter weiter, der das Gleiche tut, bis schließlich a.root-servers.net oder einer seiner „Brüder“ wird nicht gezwungen sein zu sagen: „Tut mir leid, aber das ist keine Domäne.“
Da es ungefähr 1,67*10^21 mögliche gefälschte Domainnamen mit einer Länge von sieben bis fünfzehn Zeichen gibt, ist dies die häufigste jeder Von diesen im „ehrlichen“ Netzwerk durchgeführten Tests gelangt es zum Root-Server. Das ist genau so viel die Hälfte der Gesamtlast auf dem Root-DNS aus, wie aus den Statistiken dieses Teils der Cluster hervorgeht root-servers.net, die Verisign gehören.
Die Geschichte wiederholt sich
Dies ist nicht das erste Mal, dass ein Projekt mit den besten Absichten erstellt wurde oder eine öffentliche Ressource beinahe mit unnötigem Datenverkehr überschwemmt hätte – das erinnerte uns sofort an die lange und traurige Geschichte des NTP-Servers (Network Time Protocol) von D-Link und Poul-Henning Kamp Mitte der 2000er Jahre.
Im Jahr 2005 erhielt der FreeBSD-Entwickler Poul-Henning, der auch Dänemarks einzigen Stratum 1 Network Time Protocol-Server besaß, eine unerwartete und hohe Rechnung für übertragenen Datenverkehr. Kurz gesagt, der Grund dafür war, dass D-Link-Entwickler die Adressen von Stratum 1 NTP-Servern, einschließlich des Kampa-Servers, in die Firmware der Switches, Router und Access Points des Unternehmens geschrieben haben. Dadurch erhöhte sich Kampas Serververkehr sofort um das Neunfache, was dazu führte, dass der Danish Internet Exchange (Dänemarks Internet Exchange Point) seinen Tarif von „Kostenlos“ auf „9 US-Dollar pro Jahr“ änderte.
Das Problem bestand nicht darin, dass es zu viele D-Link-Router gab, sondern darin, dass sie „aus dem Rahmen fielen“. Ähnlich wie DNS muss NTP in einer hierarchischen Form arbeiten – Stratum-0-Server leiten Informationen an Stratum-1-Server weiter, diese wiederum an Stratum-2-Server und so weiter in der Hierarchie. Ein typischer Heimrouter, Switch oder Access Point wie der, den D-Link mit NTP-Serveradressen programmiert hat, sendet Anfragen an den Stratum 2- oder Stratum 3-Server.
Das Chromium-Projekt hat, wahrscheinlich mit den besten Absichten, das NTP-Problem im DNS-Problem nachgebildet und die Root-Server des Internets mit Anfragen belastet, die sie nie verarbeiten sollten.
Es besteht Hoffnung auf eine schnelle Lösung
Das Chromium-Projekt ist Open Source , wodurch der Intranet-Redirect-Detektor standardmäßig deaktiviert werden muss, um dieses Problem zu beheben. Wir müssen dem Chromium-Projekt Anerkennung zollen: Der Fehler wurde gefunden davorwie ihm Matt Thomas von Verisign viel Aufmerksamkeit verschaffte auf dem APNIC-Blog. Der Fehler wurde im Juni entdeckt, blieb aber bis zu Thomas‘ Beitrag vergessen; Nach dem Fasten begann er unter strenger Aufsicht zu stehen.
Es besteht die Hoffnung, dass das Problem bald gelöst wird und Root-DNS-Server nicht mehr täglich auf die geschätzten 60 Milliarden gefälschten Anfragen antworten müssen.
Über die Rechte der Werbung
Epische Server - Das oder Linux mit leistungsstarken Prozessoren der AMD EPYC-Familie und sehr schnellen Intel NVMe-Laufwerken. Beeilen Sie sich mit der Bestellung!
Source: habr.com