Fast die Hälfte des Traffics auf die Root-DNS-Server wird durch Aktivitäten von Chromium verursacht.

Der Registrar APNIC, der für die Verteilung von IP-Adressen in der Asien-Pazifik-Region zuständig ist, veröffentlichte ergebnisse der Analyse des Verkehrsaufkommens auf einem der Root-DNS-Server a.root-servers.net. 45,80 % der Anfragen an den Root-Server standen im Zusammenhang mit Prüfungen, die von Browsern auf Basis der Chromium-Engine durchgeführt wurden. Somit entfallen fast die Hälfte der Ressourcen der Root-DNS-Server auf die Ausführung diagnostischer Prüfungen von Chromium anstelle der Bearbeitung von Anfragen von DNS-Servern zur Bestimmung der Root-Zonen. Angesichts der Tatsache, dass Chrome 70 % des Marktes für Webbrowser ausmacht, führt diese diagnostische Aktivität dazu, dass täglich etwa 60 Milliarden Anfragen an die Root-Server gesendet werden.

Diagnosetests werden in Chromium verwendet, um zu erkennen, ob Anbieter von Diensten, die Anfragen an nicht existierende Namen umleiten, ihre eigenen Handler verwenden. Solche Systeme werden von einigen Anbietern implementiert, um den Verkehr zu ihren eigenen Seiten bei falsch eingegebenen Domainnamen zu lenken – in der Regel werden für nicht existierende Domains Fehlerseiten angezeigt, die eine Warnung ausgeben und eine Liste möglicherweise korrekter Namen sowie Werbung bieten. Diese Aktivitäten untergraben die Logik der Erkennung von Intranet-Hosts im Browser vollständig.

Bei der Verarbeitung einer Suchanfrage, die in die Adresszeile eingegeben wurde, wenn nur ein Wort ohne Punkte eingegeben wurde, versucht der Browser zuerst zu Diese Wörter im DNS identifizieren, mit der Annahme, dass der Benutzer möglicherweise versucht, auf eine Intranet-Website im internen Netzwerk zuzugreifen, anstatt eine Anfrage an eine Suchmaschine zu senden. Wenn der Anbieter Anfragen an nicht existierenden Domainnamen auf sich umleitet, entsteht für die Nutzer ein Problem: Alle Suchanfragen aus einem Wort, die in die Adresszeile eingegeben werden, werden auf die Seiten des Anbieters umgeleitet, anstatt an die Suchmaschine weitergeleitet zu werden.

Um dieses Problem zu lösen, haben die Entwickler von Chromium zusätzliche Überprüfungen in den Browser integriert, die im Falle von Redirects die Logik der Anfrageverarbeitung in der Adresszeile ändern..
Bei jedem Start, jeder Änderung der DNS-Einstellungen oder einem Wechsel der IP-Adresse sendet der Browser drei DNS-Abfragen mit zufälligen Domainnamen der ersten Ebene, die mit hoher Wahrscheinlichkeit nicht existieren. Die Namen bestehen aus 7 bis 15 lateinischen Buchstaben (ohne Punkte) und werden verwendet, um die Umleitung nicht existierender Domainnamen durch den Provider auf sein Hosting zu identifizieren. Wenn bei der Verarbeitung von drei HTTP-Anfragen mit zufälligen Namen zwei auf die gleiche Seite umgeleitet werden, betrachtet Chromium dies als Umleitung des Nutzers auf eine externe Seite.

Für die Identifikation der Aktivitäten von Chromium im allgemeinen Anfragefluss auf dem Root-DNS-Server wurden untypische Größen von Domainnamen der ersten Ebene (von 7 bis 15 Buchstaben) und der Faktor der Wiederholbarkeit der Anfragen verwendet (die Namen wurden jedes Mal zufällig generiert und wiederholten sich nicht).
Zu Beginn wurden im Log nicht existierende Domainanfragen (78,09 %) gefiltert, gefolgt von Anfragen, die nicht mehr als dreimal wiederholt wurden (51,41 %), und anschließend wurden Domains mit 7 bis 15 Buchstaben (45,80 %) gefiltert. Interessanterweise standen nur 21,91 % der Anfragen an die Root-Server mit der Bestimmung bestehender Domains in Zusammenhang.

Im Rahmen der Studie wurde auch die Abhängigkeit des Anstiegs der Last auf den Root-Servern a.root-servers.net und j.root-servers.net von der steigenden Beliebtheit von Chrome untersucht.

In Firefox werden DNS-Umleitungsprüfungen eingeschränkt durch die Bestimmung der Umleitung auf Authentifizierungsseiten (Captive Portal) und werden umgesetzt mit durch die Verwendung von der festen Subdomain „detectportal.firefox.com“, ohne Anfragen an Domains der ersten Ebene. Ein solches Verhalten erzeugt keine zusätzliche Last auf den Root-DNS-Servern, könnte jedoch als potenzielle Leckage vertraulicher Daten über die IP-Adresse des Nutzers angesehen werden (bei jedem Start wird die Seite „detectportal.firefox.com/success.txt“ angefordert). Um die Überprüfung in Firefox zu deaktivieren, gibt es die Einstellung „network.captive-portal-service.enabled“, die auf der Seite „about:config“ geändert werden kann. wie das Leck vertraulicher Daten über die IP-Adresse des Nutzers (bei jedem Start wird die Seite „detectportal.firefox.com/success.txt“ angefordert). Um die Überprüfung in Firefox zu deaktivieren, gibt es eine Einstellung „network.captive-portal-service.enabled“, die auf der Seite „about:config“ geändert werden kann.

Quelle: opennet.ru