The Chromium browser which is known for being the open-source parent to both Google Chrome and the new Microsoft Edge is under severe criticism as one of the well-intentioned features in the browser - which is based on checking if the user’s ISP is “hijacking” any non-existent domain results- seems to go the wrong way.
Going by the facts first, the Intranet Redirect Detector stands responsible for receiving almost half of the total traffic coming from the world’s roots DNS servers. And to explain the problem in detail, Verisign engineer Matt Thomas has shed light on the following parts below.
Once you load a single modern-day webpage, there comes a dizzying number of DNS lookups. So in order to keep the load manageable, the DNS is then designed to work in a hierarchy system. At the top, there are root servers for top-level domains, that have .com in the end, as they also have a family of servers which also provide authority for every domain beneath it. Above them also are the root servers, a.root-servers.net through m.root-servers.net.
So, if a device wants to reach wikipedia.com, the first query is sent to the local ISP DNS server and if it doesn’t answer then its own “forwarders” come to help - if any are defined in particular. In case if none of them answers the cache, the query then directly goes to the authoritative servers which are com itself, at gtld-servers.net.
The gtld-servers system then responds to the query with a list of authoritative nameservers for the wikipedia.com domain and one of them will have one "glue" record that contains the IP address for one such nameserver.
Now, the answers go back to the chain—every forward passes the answer down to the server that has forwarded the query and then the final answer reaches both the local ISP server and the user's computer.
A large majority of queries are cached at one of the forwarding servers and it is rare chance that root servers are used for the answer. But so far we have been talking about the normal URLs - one associated to the normal website. The queries of Chrome can hit a level above that to the actual root-servers.net clustering themselves.
To explain this case in a better way, if someone types in “networking” on a company’s intranet and their system have an internal website with the same name, Chromium then shows up an info bar which then asks the user whether they have searched for networking or want it to redirect the user to https://networking. While it may be good for the majority of scenarios, many ISPs and shared WiFi providers still hijack any and every mistyped URL - which of course takes the user to a landing page.
Chromium's authors never wanted "did you mean" infobars to appear on every search in those common environments, so to propose a solution they implemented a test. On startup or change of network, Chromium starts to issue DNS lookups for three randomly generated seven-to-15-character top-level "domains."
If two of the requests respond back with the same IP address, Chromium then automatically considers that the local network is hijacking the NXDOMAIN errors which it would be receiving by now. Hence, as a result, it starts to just treat all single-word entries as search attempts till further notice is given.
But if you are unlucky and the network isn’t hijacking any DNS query results, then those three lookups go all the way up to the root nameservers: as the local server won’t know how to resolve qwajuixk and the query will only continue to be forwarded till the time a.root-servers.net or one of its siblings come up with a notification that "Sorry, that's not a domain."
As there is a 1.67*10^21 possibility of seven-to-15-character fake domain names, majority of the probes that are issued on an honest network end up bothering a root server eventually. This further adds up the whopping half of the total load on the root DNS servers, if the statistics from Verisign's portion of the root-servers.net clusters are to be true.
For the good part, there is already an open bug in the Chromium project that is already requesting the Intranet Redirect Detector to be disabled by default in order to solve this issue and that also means that the bug was already opened before Verisign's Matt Thomas could draw attention towards it - the bug was practically opened in June but it received daily attention after the APNIC blog post by Thomas.
Nevertheless, the hopes are high for the issue to be resolved and as a result the world’s root DNS servers won’t have to answer 60 billion useless queries every day anymore.
Read next: Google is bringing new productivity tools for tab grouping, filling out PDF files and saving them in the Chrome browser
Going by the facts first, the Intranet Redirect Detector stands responsible for receiving almost half of the total traffic coming from the world’s roots DNS servers. And to explain the problem in detail, Verisign engineer Matt Thomas has shed light on the following parts below.
The Working of DNS Resolution
The Domain Name System works to translate and remember more complex domain names like wikipedia.org as a simpler IP address like 208.80.154.224. If DNS wasn’t there, the internet couldn’t have existed in the form that is now easier for humans to understand and use. But that also means because of it there is an unnecessary load on the top-level infrastructure and it causes problems as well.Once you load a single modern-day webpage, there comes a dizzying number of DNS lookups. So in order to keep the load manageable, the DNS is then designed to work in a hierarchy system. At the top, there are root servers for top-level domains, that have .com in the end, as they also have a family of servers which also provide authority for every domain beneath it. Above them also are the root servers, a.root-servers.net through m.root-servers.net.
How Often The Problem Occurs?
There is very small ratio of DNS queries that reach the root DNS servers because of the structure’s hierarchy. Majority of the DNS resolver information is taken directly from the ISP.So, if a device wants to reach wikipedia.com, the first query is sent to the local ISP DNS server and if it doesn’t answer then its own “forwarders” come to help - if any are defined in particular. In case if none of them answers the cache, the query then directly goes to the authoritative servers which are com itself, at gtld-servers.net.
The gtld-servers system then responds to the query with a list of authoritative nameservers for the wikipedia.com domain and one of them will have one "glue" record that contains the IP address for one such nameserver.
Now, the answers go back to the chain—every forward passes the answer down to the server that has forwarded the query and then the final answer reaches both the local ISP server and the user's computer.
A large majority of queries are cached at one of the forwarding servers and it is rare chance that root servers are used for the answer. But so far we have been talking about the normal URLs - one associated to the normal website. The queries of Chrome can hit a level above that to the actual root-servers.net clustering themselves.
Chromium & NXDomain Hijack Test
The Chromium browsers is on a mission to offer users a single-box search option, known as the “Omnibox” - the one that allows users to basically type a real URL and search engine query in the same small text box the top of the browser. It also offers users the ease to not type http:// or https:// part of the URL. But with all the ease, this approach forces the browser to understand on its own the difference between a URL and a search query. One might think that this is obvious as one entry with spaces would obviously not be a URL but the case becomes tricky when intranet is involved.To explain this case in a better way, if someone types in “networking” on a company’s intranet and their system have an internal website with the same name, Chromium then shows up an info bar which then asks the user whether they have searched for networking or want it to redirect the user to https://networking. While it may be good for the majority of scenarios, many ISPs and shared WiFi providers still hijack any and every mistyped URL - which of course takes the user to a landing page.
Chromium's authors never wanted "did you mean" infobars to appear on every search in those common environments, so to propose a solution they implemented a test. On startup or change of network, Chromium starts to issue DNS lookups for three randomly generated seven-to-15-character top-level "domains."
If two of the requests respond back with the same IP address, Chromium then automatically considers that the local network is hijacking the NXDOMAIN errors which it would be receiving by now. Hence, as a result, it starts to just treat all single-word entries as search attempts till further notice is given.
But if you are unlucky and the network isn’t hijacking any DNS query results, then those three lookups go all the way up to the root nameservers: as the local server won’t know how to resolve qwajuixk and the query will only continue to be forwarded till the time a.root-servers.net or one of its siblings come up with a notification that "Sorry, that's not a domain."
As there is a 1.67*10^21 possibility of seven-to-15-character fake domain names, majority of the probes that are issued on an honest network end up bothering a root server eventually. This further adds up the whopping half of the total load on the root DNS servers, if the statistics from Verisign's portion of the root-servers.net clusters are to be true.
But Resolution Coming Soon!
This isn’t one of the first instances where a well-made project has swamped a public resource with unnecessary traffic as there already exists a sad story of D-Link and Poul-Henning Kamp's NTP (Network Time Protocol) server, from the mid-2000s.For the good part, there is already an open bug in the Chromium project that is already requesting the Intranet Redirect Detector to be disabled by default in order to solve this issue and that also means that the bug was already opened before Verisign's Matt Thomas could draw attention towards it - the bug was practically opened in June but it received daily attention after the APNIC blog post by Thomas.
Nevertheless, the hopes are high for the issue to be resolved and as a result the world’s root DNS servers won’t have to answer 60 billion useless queries every day anymore.
Read next: Google is bringing new productivity tools for tab grouping, filling out PDF files and saving them in the Chrome browser
