Der Chromium-Browser, das schnell wachsende Open-Source-übergeordnete Element von Google Chrome und das neue Microsoft Edge, hat ernsthafte negative Aufmerksamkeit für eine gut gemeinte Funktion erhalten, mit der überprüft wird, ob der ISP eines Benutzers nicht vorhandene Domain-Abfrageergebnisse stiehlt.
Der Intranet Redirect Detector , der gefälschte Abfragen für zufällige "Domänen" erstellt, deren Existenz statistisch unwahrscheinlich ist, ist für etwa die Hälfte des gesamten von Root-DNS-Servern weltweit empfangenen Datenverkehrs verantwortlich. Verisign-Ingenieur Matt Thomas schrieb einen langen Beitrag im APNIC-Blog, in dem er das Problem beschrieb und dessen Umfang bewertete.
Wie DNS-Lookups normalerweise durchgeführt werden
Diese Server sind die ultimative Autorität, die zum Auflösen von .com, .net usw. kontaktiert werden muss, damit Sie erfahren, dass frglxrtmpuf keine Top-Level-Domain (TLD) ist.
DNS oder Domain Name System ist ein System, mit dem Computer einprägsame Domainnamen wie arstechnica.com in weniger bequeme IP-Adressen wie 3.128.236.93 übersetzen können. Ohne DNS wäre das Internet nicht in der Lage, menschenfreundlich zu sein, was bedeutet, dass eine unnötige Belastung der Infrastruktur auf höchster Ebene ein echtes Problem darstellt.
Das Laden einer einzelnen modernen Webseite kann eine unvorstellbare Anzahl von DNS-Suchvorgängen erfordern. Bei der Analyse der ESPN-Homepage haben wir beispielsweise 93 separate Domainnamen gezählt, die von a.espncdn.com bis z.motads.com reichen. Alle sind für das Laden der ganzen Seite erforderlich!
DNS ist als mehrstufige Hierarchie konzipiert, um diese Art von Arbeitslast zu bewältigen, die für die ganze Welt erforderlich ist. An der Spitze dieser Pyramide befinden sich Stammserver. Jede Top-Level-Domain, z. B. .com, verfügt über eine eigene Serverfamilie, die die ultimative Autorität für jede Domain unter ihnen darstellt. Eine Kerbe über diesen Servern befinden sich die Root-Server selbst von
a.root-servers.netbis m.root-servers.net.
Wie oft passiert das?
Aufgrund der abgestuften Caching-Hierarchie der DNS-Infrastruktur erreicht ein sehr kleiner Prozentsatz der weltweiten DNS-Abfragen die Stammserver. Die meisten Benutzer erhalten ihre DNS-Resolver-Informationen direkt von ihrem ISP. Wenn das Gerät eines Benutzers wissen muss, wie er zu einer bestimmten Site gelangt, wird zuerst eine Anforderung an einen DNS-Server gesendet, der von diesem lokalen Anbieter verwaltet wird. Wenn der lokale DNS-Server die Antwort nicht kennt, leitet er die Anfrage an seine eigenen "Weiterleitungen" weiter (falls angegeben).
Wenn weder der DNS-Server des lokalen Internetdienstanbieters noch die konfigurierten "Weiterleitungen" eine zwischengespeicherte Antwort haben, wird die Anforderung direkt an den autorisierenden Server in der Domäne weitergeleitet, die über derjenige liegt, die Sie auflösen möchten . Im Fall von
.comDies bedeutet, dass die Anforderung an die autorisierenden Server der Domäne selbst gesendet wird com, die sich unter befinden gtld-servers.net.
Das System,
gtld-serversan das die Anforderung gestellt wurde, antwortet mit einer Liste autorisierter Nameserver für die Domain domain.com sowie mindestens einem Klebedatensatz, der die IP-Adresse eines solchen Nameservers enthält. Dann gehen die Antworten die Kette entlang - jeder Spediteur sendet 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. Gleichzeitig zwischenspeichern alle diese Antwort, um übergeordnete Systeme nicht unnötig zu stören.
In den meisten Fällen zeichnet der Nameserver für domain.com aufwird bereits auf einer dieser Weiterleitungen zwischengespeichert, damit die Root-Server nicht gestört werden. Im Moment sprechen wir jedoch von der üblichen Form einer URL, die in eine reguläre Website umgewandelt wird. Chrome - Abfragen sind auf einem Niveau oberhalb dass an der Sprosse des Cluster selbst
root-servers.net.
Diebstahlprüfung für Chrom und NXDomain
Chromium prüft "Täuscht mich dieser DNS-Server?" machen fast die Hälfte des gesamten Datenverkehrs aus, der den Verisign DNS Root Server Cluster erreicht.
Der Chromium-Browser, das übergeordnete Projekt von Google Chrome, der neue Microsoft Edge und unzählige weniger bekannte Browser möchten den Benutzern die einfache Suche in einem einzigen Feld ermöglichen, das manchmal als "Omnibox" bezeichnet wird. Mit anderen Worten, der Benutzer gibt sowohl echte URLs als auch Suchmaschinenabfragen in dasselbe Textfeld oben im Browserfenster ein. Wenn Sie einen Schritt weiter in Richtung Vereinfachung gehen, wird der Benutzer auch nicht gezwungen, einen Teil der URL mit
http://oder einzugeben https://.
So bequem es auch sein mag, bei diesem Ansatz muss der Browser verstehen, was als URL und was als Suchabfrage zu zählen ist. In den meisten Fällen ist dies ziemlich offensichtlich - beispielsweise kann eine Zeichenfolge mit Leerzeichen keine URL sein. Bei Intranets kann es jedoch schwieriger werden - 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 seines 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 aufrufen möchte
https://marketing... Es ist in Ordnung, aber viele ISPs und öffentliche Wi-Fi-Anbieter "entführen" jede falsch geschriebene URL und leiten den Benutzer auf eine Seite voller Bannerwerbung weiter.
Zufällige Generierung
Die Chromium-Entwickler wollten nicht, dass Benutzer in regulären Netzwerken bei jeder Suche nach einem Wort ein Informationsfenster sehen und nach ihrer Bedeutung fragen. Daher führten sie einen Test durch: Beim Starten des Browsers oder beim Ändern des Netzwerks führt Chromium DNS-Suchvorgänge für drei zufällig generierte "Domänen" durch. Top-Level, sieben bis fünfzehn Zeichen lang. Wenn zwei dieser Anforderungen mit derselben IP-Adresse zurückgegeben werden, geht Chromium davon aus, dass das lokale Netzwerk
NXDOMAINdie empfangenen Fehler "stiehlt" , sodass der Browser bis auf weiteres alle eingegebenen Abfragen aus demselben Wort wie Suchversuche berücksichtigt.
Leider in Netzwerken, die nicht sindWenn Sie die Ergebnisse von DNS-Abfragen stehlen, gehen diese drei Vorgänge normalerweise ganz nach oben, zu den Root-Nameservern selbst: Der lokale Server weiß nicht, wie
qwajuixker aufgelöst werden soll, und leitet diese Anforderung an seine Weiterleitung weiter, die das Gleiche tut, bis schließlich a.root-servers.netoder an eine von Seine "Brüder" werden nicht gezwungen sein zu sagen "Entschuldigung, aber dies ist keine Domäne."
Da es ungefähr 1,67 * 10 ^ 21 mögliche gefälschte Domainnamen gibt, die sieben bis fünfzehn Zeichen lang sind, ist es üblich, dass jeder dieser Tests, die in einem "fairen" Netzwerk durchgeführt werden, zum Root-Server gelangt. Dies entspricht laut Statistiken des Teils der Cluster, die Verisign gehören, der Hälfte der Gesamtlast des Root-DNS
root-servers.net.
Geschichte wiederholt sich
Dies ist nicht das erste Mal, dass ein gut gemeintes Projekt eine öffentliche Ressource mit unnötigem Verkehr überflutet oder fast überflutet hat - es erinnerte uns sofort an die lange und traurige Geschichte von D-Link und dem NTP-Server des Pole-Henning-Lagers Mitte der 2000er Jahre. x.
Im Jahr 2005 erhielt der FreeBSD-Entwickler Poul-Henning, dem auch Dänemarks einziger Stratum 1 Network Time Protocol-Server gehörte, eine unerwartete und hohe Rechnung für den übertragenen Verkehr. Kurz gesagt, der Grund war, dass die D-Link-Entwickler die Adressen der Stratum 1-NTP-Server, einschließlich des Campa-Servers, in der Firmware der Switches, Router und Access Points des Unternehmens registrierten. Dies erhöhte den Datenverkehr des Kampa-Servers sofort um das Neunfache, was dazu führte, dass Danish Internet Exchange (Dänemarks Internet-Austauschstelle) seinen Tarif von "Kostenlos" auf "9.000 Dollar pro Jahr" änderte.
Das Problem war nicht, dass es zu viele D-Link-Router gab, sondern dass sie "die Befehlskette verletzt" haben. Ähnlich wie DNS sollte NTP hierarchisch funktionieren - Stratum 0-Server leiten Informationen an Stratum 1-Server weiter, die Informationen an Stratum 2-Server weiterleiten, und so weiter in der Hierarchie. Ein gewöhnlicher Heimrouter, Switch oder Access Point, wie der D-Link, der nach NTP-Serveradressen gefragt wurde, musste Anforderungen an den Stratum 2- oder Stratum 3-Server senden.
Das Chromium-Projekt wiederholte wahrscheinlich mit den besten Absichten das NTP-Problem im DNS durch Laden der Root-Server des Internets mit Abfragen, die sie niemals bearbeiten sollten.
Es besteht Hoffnung auf eine schnelle Lösung
Es gibt einen offenen Fehler im Chromium-Projekt , bei dem der Standard-Intranet-Redirect-Detektor deaktiviert werden muss, um dieses Problem zu beheben. Wir müssen Tribut an das Projekt Chromium zahlen: ein Fehler gefunden wurde , vor , Matt Thomas von Verisign zog zu seiner großen Aufmerksamkeit auf seine Post im APNIC Blog. Der Fehler wurde im Juni entdeckt, blieb aber bis zu Thomas 'Posten in Vergessenheit; Nach dem Fasten wurde er genau beobachtet.
Es ist zu hoffen, dass das Problem bald behoben wird und die Root-DNS-Server nicht mehr täglich auf etwa 60 Milliarden falsche Anfragen antworten müssen.
Werbung
Epic Server sind Windows- oder Linux-VPS mit leistungsstarken AMD EPYC-Prozessoren und sehr schnellen Intel NVMe-Laufwerken. Beeilen Sie sich zu bestellen!
