FYI: Chromium's network probing accounts for about half DNS root server traffic, says APNIC

Detecting ISP shenanigans has led to a constant deluge of packets

The Google Chromium team's effort to detect when ISPs are trying to hijack domain name typos has led to a lot of network load: the browser's query response testing routine now accounts for about half of all DNS root server traffic according to a new study.

In a post published Friday to the blog of APNIC, the Regional Internet Registry for the Asia-Pacific region, Verisign principal engineer Matthew Thomas looked at the consequences of the Chromium team's decision to combine the browser's search input box with its address input box back in 2008.

The Chromium omnibox can accept either URLs, which lead to websites, or search queries, which lead to a search results page – probably Google's – full of links pointing to websites. Determining what a browser user wants when the text input is a single word isn't always straightforward – the word could be a search term or a reference to an intranet domain.

Chrome will try to resolve the input as if it were a domain name and if name resolution fails, the browser receives an NXDOMAIN error message indicating that the DNS resolver can't turn the name into an IP address.

Google's Chrome browser, and other Chromium-based browsers, take the error as an indication that the omnibox input is a search term.

But, as Thomas explains, some network service providers capture error response messages so the browser doesn't receive them. They're essentially trying to monetize typos – mistyped or non-existent domain queries – to offer a response linked to their own services, a practice known as NXDomain hijacking.

"Users on such networks might be shown the 'did you mean' infobar on every single-term search," said Thomas. "To work around this, Chromium needs to know if it can trust the network to provide non-intercepted DNS responses."

To check whether it can trust the network, Chromium includes code that probes how the network responds to randomly generated single-word domain names. Its "Intranet Redirector Code" generates three random hostname with between seven and 15 characters.

"This component sends requests to three randomly generated, and thus likely nonexistent, hostnames," a Google developer's code comment explains. "If at least two redirect to the same hostname, this suggests the ISP is hijacking NXDOMAIN, and the omnibox should treat similar redirected navigations as 'failed' when deciding whether to prompt the user with a 'did you mean to navigate' infobar for certain search inputs."

This happens whenever the browser starts up and after system or device IP or DNS changes. Given the prevalence of Chrome and other Chromium-based browsers, it happens increasingly often.

"[I]n the 10+ years since the feature was added, we now find that half of the DNS root server traffic is very likely due to Chromium’s probes," Thomas says. "That equates to about 60 billion queries to the root server system on a typical day."

Thomas said the DNS root system is designed to handle large volumes of traffic and likened Chromium's behavior to an ongoing DDoS attack. He mused whether Chromium might be able to adopt a more resource-efficient approach along the lines of Firefox, which implements a different captive portal test that doesn't rely on DNS root servers.

“The DNS is robust and the additional traffic caused by these queries does not cause concern,” a Verisign spokesperson told The Register in an email. “However, reducing root server traffic would be good DNS operator hygiene.”

The Register asked Google whether any such changes are being considered. We've not heard back. ®