Nearly half of traffic to root DNS servers is caused by Chromium activity

APNIC Registrar, responsible for allocating IP addresses in the Asia-Pacific region, ΠΎΠΏΡƒΠ±Π»ΠΈΠΊΠΎΠ²Π°Π» results of traffic distribution analysis on one of the root DNS servers a.root-servers.net. 45.80% of requests to the root server turned out to be related to checks performed by browsers based on the Chromium engine. Thus, almost half of the resources of the root DNS servers are spent on performing Chromium diagnostic checks, and not processing queries from DNS servers when determining root zones. With Chrome accounting for 70% of the web browser market, this diagnostic activity results in about 60 billion requests to root servers per day.

Diagnostic checks are used in Chromium to determine if service providers are using services that redirect requests for non-existent names to their handlers. Similar systems are implemented by some providers to direct traffic to themselves for domain names entered with an error - as a rule, for non-existent domains, pages are shown with an error warning, a list of likely correct names and advertising. At the same time, such activity completely destroys the logic of determining intranet hosts in the browser.

When processing a search query entered in the address bar, if only one word without dots is entered, the browser will first is trying define this word in DNS, assuming that the user may be trying to access an intranet site on the internal network, rather than submitting a query to a search engine. If the provider redirects queries to non-existent domain names, users have a problem - any one-word search queries entered in the address bar begin to be redirected to the provider's pages, and not sent to the search engine.

To solve the problem, Chromium developers added to the browser additional checks, which, if redirects are detected, change the logic for processing requests in the address bar.
Every time you start, change your DNS settings, or change your IP address, the browser sends three DNS queries with random top-level domain names that most likely do not exist. Names include from 7 to 15 Latin letters (without periods) and are used to detect redirection of non-existent domain names by the provider to its host. If, when processing three HTTP requests with random names for two, a redirect to the same page is received, then Chromium considers that the user has been redirected to a third-party page.

As signs for highlighting Chromium activity from the general flow of requests on the root DNS server, atypical sizes of the first-level domain (from 7 to 15 letters) and a request repeatability factor (names were generated randomly each time and did not repeat) were used.
The log first filtered out requests for non-existent domains (78.09%), then highlighted requests that were repeated no more than three times (51.41%), and then filtered out domains that included from 7 to 15 letters (45.80%). Interestingly, only 21.91% of requests to the root servers turned out to be related to the definition of existing domains.

Nearly half of traffic to root DNS servers is caused by Chromium activity

The study also examined how the load on the a.root-servers.net and j.root-servers.net root servers depended on the growing popularity of Chrome.

Nearly half of traffic to root DNS servers is caused by Chromium activity

Firefox redirect checks via DNS are limited defining redirects to authentication pages (captive portal) and implemented с using fixed subdomain "detectportal.firefox.com", without requesting first level domain names. This behavior does not create additional load on the root DNS servers, but can potentially be considered as leaking sensitive data about the user's IP address (requesting the page "detectportal.firefox.com/success.txt" on every launch). Firefox has a "network.captive-portal-service.enabled" setting to disable the check, which can be changed on the "about:config" page.

Source: opennet.ru

Add a comment