В Chrome 78 ще започнат експерименти с внедряване на DNS-over-HTTPS

Следвайки Mozilla компанията Google съобщи за намерението си да извърши експеримент за проверка на реализираното за браузъра Chrome решение «DNS върху HTTPS» (DoH, DNS over HTTPS). В версията Chrome 78, планирана за 22 октомври, някои категории потребители по подразбиране преведени ще бъдат на използване на DoH. В експеримента по активиране на DoH ще участват само потребители, при текущите системни настройки на които са указани определени DNS доставчици, признати за съвместими с DoH.

В бял списък на DNS доставчиците са включени услуги 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) и DNS.SB (185.222.222.222, 185.184.222.222). Ако в настройките на DNS у потребителя е указан един от гореспоменатите DNS сървъри, DoH в Chrome ще бъде активиран по подразбиране. За тези, които използват предоставени от местния интернет доставчик DNS сървъри, всичко ще остане без промяна и за DNS запитванията ще продължи да се използва системният резолвер.

Важно отличие от внедряването на DoH в Firefox, където постепенното включване на DoH по подразбиране ще започне вече в края на септември, е отсъствието на обвързаност с един DoH доставчик. Ако в Firefox по подразбиране се използва DNS сървър е CloudFlare, в Chrome просто ще се актуализира методът за работа с DNS на еквивалентна услуга, без смяна на DNS доставчика. Например, ако у потребителя в системните настройки е указан DNS 8.8.8.8, в Chrome ще бъде бъде активиран DoH услугата на Google («https://dns.google.com/dns-query»), ако DNS е 1.1.1.1, то DoH услугата на Cloudflare («https://cloudflare-dns.com/dns-query») и и т.н.

При желание потребителят ще може да включи или изключи DoH чрез настройката «chrome://flags/#dns-over-https». Поддържат се три режима на работа «secure», «automatic» и «off». В режим «secure» хостовете се определят само на базата на предходно кеширани безопасни стойности (получени чрез защитена връзка) и запитвания чрез DoH, обратно на обикновения DNS не се прилага. В режим «automatic», ако DoH и защитеният кеш не са налични, се допуска получаване на данни от небезопасния кеш и обаждане чрез традиционния DNS. В режим «off» първо се проверява общият кеш и ако данни няма, запитването се изпраща чрез системния DNS. Режимът се задава чрез настройката kDnsOverHttpsMode, а шаблонът за съпоставяне на сървърите чрез kDnsOverHttpsTemplates.

Експериментът по активиране на DoH ще се проведе на всички поддържани платформи в Chrome, с изключение на Linux и iOS поради нетривиалността на анализа на настройките на резолвера и ограничен достъп до системните DNS настройки. В случай че след активирането на DoH се появят проблеми с изпращането на заявки към DoH сървър (например, заради блокиране, нарушение на мрежовата свързаност или авария), браузърът автоматично ще възвърне системните DNS настройки.

Целта на експеримента е финална проверка на реализацията на DoH и изучаване на влиянието на прилагането на DoH върху производителността. Следва да се отбележи, че всъщност поддръжката на DoH е е добавена била включена в кодовата база на Chrome още през февруари, но за настройка и активиране на DoH е било необходимо стартиране на Chrome с специален флаг и неочевиден набор от опции.

Напомняме, че DoH може да бъде полезен за предотвратяване на изтичане на информация за търсените имената на хостове през DNS-сървърите на доставчиците, борба с MITM атаки и подмяна на DNS трафика (например, при свързване към публични Wi-Fi мрежи), противодействие на DNS блокировки (DoH не може да замести VPN в контекста на заобикаляне на блокировки, реализирани на ниво DPI) или за организиране на работа в случаи, когато не е възможно директно свързване с DNS-сървъри (например, при работа през прокси). Докато в обикновена ситуация DNS заявките се изпращат директно до определени в конфигурацията системни DNS-сървъри, в случай на DoH заявката за определяне на IP адреса на хоста е инкапсулирана в HTTPS трафик и се изпраща на HTTP сървър, където резолверът обработва заявките чрез Web API. Съществуващият стандарт DNSSEC използва криптиране само за удостоверяване на клиента и сървъра, но не защитава трафика от прихващане и не гарантира конфиденциалността на заявките.

Източник: opennet.ru