News: 1598041490

  ARM Give a man a fire and he's warm for a day, but set fire to him and he's warm for the rest of his life (Terry Pratchett, Jingo)

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

(2020/08/21)


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 [1]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.

C++ still rules the Chromium roost though Rust has caught our eye, say browser devs [2]READ MORE

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 [3]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. ®

Get our [4]Tech Resources



[1] https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/

[2] https://www.theregister.com/2020/08/19/c_plus_plus_chromium_rust/

[3] https://chromium.googlesource.com/chromium/src/+/master/chrome/browser/intranet_redirect_detector.cc

[4] https://whitepapers.theregister.com/

Alister

classic example of the law of unintended consequences.

Out of interest then...

Martin an gof

Just how does Firefox detect domain hijacking, if it doesn't do it the same way as Chrome?

M.

Number6

I would like to see browsers have a config option so that they didn't automatically assume a search if they didn't think what I just typed was a resolvable address. If I want to search it's the work of moments to bring up a search engine.

batfastad

Exactly. What I type in the address bar is what I want to visit... or probably my history will match after the first few letters. Sadly Firefox copied this omnibar-shambles.

In Firefox if I want to search then I simply ctrl+? (formerly ctrl+k, or whatever search provider and shortcut combo I had created before the search box customisation was borged to become like Chromium).

Which is why

prouton

I avoid NXDomain hijacks entirely by turning off search via the address bar. Using a browser on a wide screen monitor, there's no problem keeping separate address and search fields available at all times. Plus, if I have any doubt about what the domain name is, I do a search on it first and select from the google results that look most legitimate.

Oh, and I change the DNS servers at the router level away from my ISP's servers.

Read the original

Deadlock

Probably best to read the actual post as that's where Google have responded in the comments (Peter Kasting's comment). https://blog.apnic.net/2020/08/21/chromiums-impact-on-root-dns-traffic/

OR we could fix the root of the problem

Gene Cash

Can we turn domain hijacking into a privacy issue or something? Something we can sue ISPs over?

The only really good place to buy lumber is at a store where the lumber has
already been cut and attached together in the form of furniture, finished,
and put inside boxes.
-- Dave Barry, "The Taming of the Screw"