Followed by Google about the intention to conduct an experiment to test the implementation of βDNS over HTTPSβ (DoH, DNS over HTTPS) being developed for the Chrome browser. Chrome 78 release scheduled for October 22nd will have some user categories by default to use DoH. The experiment to enable DoH will be limited to users whose current system settings list certain DNS providers that are recognized as DoH compliant.
Whitelisted DNS providers included 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, 185.222.222.222) and DNS.SB (185.184.222.222, XNUMX). If one of the above DNS servers is specified in the user's DNS settings, DoH in Chrome will be activated by default. For those who use the DNS servers provided by the local ISP, everything will remain unchanged and the system resolver will continue to be used for DNS queries.
An important difference from Firefox's implementation of DoH, in which DoH is incrementally enabled by default already at the end of September, is the lack of binding to a single DoH service. If in Firefox by default CloudFlare DNS server, then Chrome will only update the method of working with DNS to an equivalent service, without changing the DNS provider. For example, if the user has DNS 8.8.8.8 specified in the system settings, then Chrome will Google DoH service ("https://dns.google.com/dns-query"), if DNS is 1.1.1.1 then Cloudflare DoH service ("https://cloudflare-dns.com/dns-query") And
If desired, the user will be able to enable or disable DoH using the "chrome://flags/#dns-over-https" setting. Three operating modes are supported "secure", "automatic" and "off". In "secure" mode, hosts are determined only based on previously cached secure values ββ(obtained over a secure connection) and requests via DoH, fallback to regular DNS is not applied. In the "automatic" mode, if DoH and the secure cache are not available, data can be retrieved from the insecure cache and accessed through traditional DNS. In the "off" mode, the shared cache is first checked and if there is no data, the request is sent through the system DNS. The mode is set via kDnsOverHttpsMode , and the server mapping template via kDnsOverHttpsTemplates.
The experiment to enable DoH will be carried out on all platforms supported in Chrome, with the exception of Linux and iOS due to the non-triviality of parsing resolver settings and restricting access to DNS system settings. If, after enabling DoH, there are failures to send requests to the DoH server (for example, due to its blocking, network connectivity failure, or failure), the browser will automatically return the DNS system settings.
The purpose of the experiment is to finally test the implementation of DoH and to study the impact of applying DoH on performance. It should be noted that the actual DoH support was to the Chrome codebase back in February, but to configure and enable DoH launching Chrome with a special flag and a non-obvious set of options.
Recall that DoH can be useful for preventing leaks of information about requested host names through the DNS servers of providers, combating MITM attacks and DNS traffic spoofing (for example, when connecting to public Wi-Fi), countering blocking at the DNS level (DoH cannot replace VPN in the area of ββbypassing blocking implemented at the DPI level) or for organizing work in case it is impossible to directly access DNS servers (for example, when working through a proxy). While normally DNS requests are sent directly to the DNS servers defined in the system configuration, in the case of DoH, the request to determine the host IP address is encapsulated in HTTPS traffic and sent to the HTTP server, on which the resolver processes requests via the Web API. The current DNSSEC standard uses encryption only to authenticate the client and server, but does not protect traffic from interception and does not guarantee the confidentiality of requests.
Source: opennet.ru