Following Google company about its intention to conduct an experiment to test the implementation of 'DNS over HTTPS' (DoH) being developed for the Chrome browser. In the release of Chrome 78, scheduled for October 22, some user categories will use DoH by default. In the experiment to enable DoH, only users whose current system settings specify certain DNS providers recognized as compatible with DoH will participate.
The whitelist of DNS providers includes Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168, 185.228.169.168), and DNS.SB (185.222.222.222, 185.184.222.222). If a user has one of the aforementioned DNS servers in their DNS settings, DoH will be activated by default in Chrome. For those using DNS servers provided by their local internet service provider, everything will remain unchanged, and system resolver will continue to be used for DNS queries.
An important difference from the implementation of DoH in Firefox, where the phased enabling of DoH by default already at the end of September, is the lack of binding to a single DoH service. While in Firefox the default DNS server is CloudFlare, in Chrome only the method of working with DNS will be updated to an equivalent service without changing the DNS provider. For example, if a user has the DNS 8.8.8.8 specified in system settings, then Chrome will use Google’s DoH service ('https://dns.google.com/dns-query'), if the DNS is 1.1.1.1, then the DoH service from Cloudflare ('https://cloudflare-dns.com/dns-query') will be used.
If desired, a user can enable or disable DoH using the setting 'chrome://flags/#dns-over-https'. There are three operational modes supported: 'secure', 'automatic', and 'off'. In 'secure' mode, hosts are determined based solely on previously cached secure values (obtained through a secure connection) and requests through DoH, with no fallback to regular DNS. In 'automatic' mode, if DoH and the secure cache are not available, obtaining data from an insecure cache and accessing traditional DNS is allowed. In 'off' mode, the overall cache is checked first, and if no data is found, the request is sent through system DNS. The mode is set through kDnsOverHttpsMode, and the server matching template through kDnsOverHttpsTemplates.
The experiment to enable DoH will be conducted on all platforms supported in Chrome, except for Linux and iOS due to the complexity of parsing resolver settings and limitations in accessing system DNS settings. In the event that issues arise after enabling DoH with requests to the DoH server (e.g., due to its blockage, network connectivity disruptions, or outages), the browser will automatically revert to the system DNS settings.
The aim of the experiment is to conduct a final verification of the DoH implementation and to study its impact on performance. It is worth noting that support for DoH was actually added to the Chrome codebase back in February, but enabling and configuring DoH launching Chrome with a special flag and a non-obvious set of options.
It is important to remember that DoH can be beneficial in preventing leaks of information about requested hostnames through provider DNS servers, combating MITM attacks, and DNS traffic spoofing (for instance, when connecting to public Wi-Fi), resisting DNS-level blocks (DoH cannot replace VPNs when it comes to bypassing restrictions implemented at the DPI level), or for enabling functionality in situations where direct access to DNS servers is not possible (e.g., when working through a proxy). While in a regular situation, DNS requests are sent directly to the DNS servers specified in the system configuration, with DoH, the request to determine the host's IP address is encapsulated in HTTPS traffic and sent to an HTTP server, where the resolver processes the requests through a Web API. The existing DNSSEC standard only uses encryption for client and server authentication, but does not protect traffic from interception and does not guarantee the confidentiality of requests.
Source: opennet.ru
