Google Chrome
After Mozilla, Google announced its intention to conduct an experiment to test Chrome browser implementation with «DNS over HTTPS » (DoH, DNS over HTTPS). With the release of Chrome 78, scheduled for October 22.
Some categories of users by default will be able to participate in the experiment To enable DoH, only users will participate in the current system configuration, which is recognized by certain DNS providers that support DoH.
The DNS provider whitelist includes services Google, Cloudflare, OpenDNS, Quad9, Cleanbrowsing and DNS.SB. If the user's DNS settings specify one of the above DNS servers, DoH in Chrome will be enabled by default.
For those using the DNS servers provided by the local Internet service provider, everything will remain unchanged and the system resolution will continue to be used for DNS queries.
An important difference from DoH implementation in Firefox, in which the gradual inclusion of the default DoH will begin at the end of September, it is the lack of linking to a single DoH service.
If Firefox uses the CloudFlare DNS server by default, Chrome will only update the method of working with DNS to an equivalent service, without changing the DNS provider.
If desired, user can enable or disable DoH using the "chrome: // flags / # dns-over-https" setting. What's more three modes of operation are supported "Safe", "automatic" and "off".
- In "safe" mode, hosts are determined only based on previously cached safe values (received over a secure connection) and requests through DoH, rollback to normal DNS is not applied.
- In "automatic" mode, if DoH and the secure cache are not available, it is possible to receive data from an insecure cache and access it through traditional DNS.
- In "off" mode, the general cache is checked first and, if there is no data, the request is sent through the system's DNS. The mode is set through kDnsOverHttpsMode settings and the server mapping template through kDnsOverHttpsTemplates.
The experiment to enable DoH will be carried out on all supported platforms in Chrome, with the exception of Linux and iOS, due to the non-trivial nature of the resolver configuration analysis and limited access to the DNS system configuration.
In the event that after enabling DoH there are failures to send requests to the DoH server (for example, due to network connectivity crash, failure or failure), the browser will automatically return the DNS system settings.
The purpose of the experiment is to finalize the DoH implementation and examine the impact of the DoH application on performance.
It should be noted that, in fact, DoH support was added to the Chrome codebase in February, but to configure and enable DoH, Chrome had to launch with a special flag and a non-obvious set of options.
Importantly, DoH can be helpful in eliminating hostname information leaks requested through the DNS servers of the providers, combat MITM attacks and replace DNS traffic (for example, when connecting to public Wi-Fi) and opposing DNS-level blocking (DoH) cannot replace a VPN in the area of avoiding implemented blocks at the DPI level) or to organize work if it is impossible to access directly to DNS servers (for example, when working through a proxy).
If in normal situations, DNS queries are sent directly to the DNS servers defined in the system configuration, then in the case of DoH, the request to determine the host's IP address is encapsulated in the HTTPS traffic and sent to the server HTTP in which the resolver processes requests through the web API.
The existing DNSSEC standard uses encryption only for client and server authentication.