Chromium?s impact on root DNS traffic | APNIC Blog

Since its introduction in 2008, Chromium-based browsers have risen steadily in popularity and today comprise approximately 70% of the market share.Chromium has, since its early days, included a feature known as the omnibox, which allows users to enter either a website name, URL, or search terms. Chromium treats it as a search term but also displays an infobar that says something like “did you mean http://marketing/?” if a background DNS lookup for the name results in an IP address.At this point, a new issue arises. single-label domain name, as shown in Figure 1 below.This code results in three URL fetches — such as http://rociwefoie/, http://uawfkfrefre/ and http://awoimveroi/ — and these, in turn, result in three DNS lookups for the random hostnames. tabulated queries based on the following attributes:Figure 2 shows a classification of data from a.root-servers.net on 13 May 2020. This small sliver represents either false positives or Chromium probe queries that have been subject to domain suffix search appending by stub resolvers or end-user applications.Of the 51% observed fewer than four times, all characters, which can increase the query count to above our threshold of three.Next, we turned our attention to the analysis of how the total root traffic percentage of Chromium-like queries has changed over time. We used two data sets in this analysis: data from DNS-OARC’s “Day In The Life” (DITL) collections, and Verisign’s data for a.root-servers.net and j.root-servers.net.Figure 3 shows the results of the long-term analysis. Chromium-like queries observed in the DITL data before the introduction of the directing them away from the root servers towards the browser’s infrastructure.While technical solutions such as Aggressive NSEC Caching (RFC 8198), Qname Minimization (RFC 7816), and NXDomain Cut (RFC 8020) could also significantly reduce probe queries to the root server system, these solutions require action by recursive resolver operators, who have limited incentive to deploy and support these technologies.Contributors: Duane WesselsMatt Thomas is a Principal Engineer in Verisign’s CSO Applied Research division.The views expressed by the authors of this blog are their own Usually sufficiently ineptly that I even get results for domains the spec “guarantees” will never be valid.“The intranet redirect detector functions are executed each time the browser starts up, each time the system/device’s IP address changes, and each time the system/device’s DNS configuration changes.”I wonder if it wouldn’t be fully sufficient to just test when the IP address or DNS changes and not at startup.