Nastąpiła firma Google o planach przeprowadzenia eksperymentu mającego na celu sprawdzenie wdrażanej w przeglądarce Chrome implementacji „DNS przez HTTPS” (DoH, DNS over HTTPS). W wydaniu Chrome 78, zaplanowanym na 22 października, niektóre grupy użytkowników będą domyślnie używać DoH. W eksperymencie wdrożenia DoH wezmą udział tylko użytkownicy, którzy w swoich aktualnych ustawieniach systemowych mają wskazanych określonych dostawców DNS, uznanych za zgodne z DoH.
Na białą listę dostawców DNS włączono 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) oraz DNS.SB (185.222.222.222, 185.184.222.222). Jeśli w ustawieniach DNS użytkownika znajdzie się jeden z wymienionych serwerów DNS, DoH w Chrome zostanie aktywowane domyślnie. Dla tych, którzy korzystają z dostarczonych przez lokalnego dostawcę internetu serwerów DNS, wszystko pozostanie bez zmian i do zapytań DNS nadal będzie używany systemowy resolver.
Ważną różnicą w porównaniu do wdrożenia DoH w Firefox, gdzie stopniowe domyślne włączenie DoH już pod koniec września, jest brak związku z jednym dostawcą DoH. Jeśli w Firefox domyślnie serwer DNS Cloudflare jest określony, to w Chrome dokonane zostanie jedynie zaktualizowanie metody obsługi DNS na równoważny serwis, bez zmiany dostawcy DNS. Na przykład, jeśli użytkownik w ustawieniach systemowych ma określone DNS 8.8.8.8, to w Chrome usługa DoH Google („https://dns.google.com/dns-query”), jeśli DNS to 1.1.1.1, to usługa DoH Cloudflare („https://cloudflare-dns.com/dns-query”) i
W razie potrzeby użytkownik będzie mógł włączyć lub wyłączyć DoH za pomocą ustawienia „chrome://flags/#dns-over-https”. Obsługiwane są trzy tryby pracy: „secure”, „automatic” i „off”. W trybie „secure” hosty są określane wyłącznie na podstawie wcześniej buforowanych bezpiecznych wartości (uzyskanych przez bezpieczne połączenie) oraz zapytań przez DoH, powrót do standardowego DNS nie ma miejsca. W trybie „automatic”, jeśli DoH i bezpieczny cache są niedostępne, dopuszcza się uzyskiwanie danych z niebezpiecznego cache oraz korzystanie z tradycyjnego DNS. W trybie „off” najpierw sprawdzany jest ogólny cache, a jeśli danych nie ma, zapytanie jest wysyłane przez systemowy DNS. Tryb jest ustawiany za pomocą kDnsOverHttpsMode, a szablon do dopasowania serwerów za pomocą kDnsOverHttpsTemplates.
Eksperyment dotyczący włączenia DoH będzie przeprowadzony na wszystkich wspieranych platformach w Chrome, z wyjątkiem Linuxa i iOS ze względu na złożoność analizy ustawień resolvera oraz ograniczony dostęp do systemowych ustawień DNS. W przypadku wystąpienia problemów z wysyłaniem zapytań do serwera DoH (na przykład z powodu jego zablokowania, utraty łączności sieciowej lub awarii), przeglądarka automatycznie przywróci systemowe ustawienia DNS.
Celem przeprowadzenia eksperymentu jest ostateczna weryfikacja implementacji DoH oraz badanie wpływu stosowania DoH na wydajność. Należy zauważyć, że faktycznie wsparcie dla DoH zostało dodane do bazy kodu Chrome już w lutym, ale do konfiguracji i włączenia DoH uruchomienie Chrome z specjalnym flagiem i nieoczywistym zestawem opcji.
Przypomnijmy, że DoH może być przydatne do eliminacji wycieków informacji o żądanych nazwach hostów przez serwery DNS dostawców, walki z atakami MITM oraz fałszowaniem ruchu DNS (na przykład podczas łączenia z publicznymi Wi-Fi), przeciwdziałania blokadom na poziomie DNS (DoH nie może zastąpić VPN w zakresie omijania blokad wprowadzonych na poziomie DPI) lub do organizowania pracy w przypadku braku możliwości bezpośredniego kontaktu z serwerami DNS (na przykład podczas pracy przez proxy). W zwykłych warunkach zapytania DNS są bezpośrednio wysyłane do określonych w konfiguracji systemu serwerów DNS, natomiast w przypadku DoH zapytanie o określenie adresu IP hosta jest enkapsulowane w ruchu HTTPS i wysyłane do serwera HTTP, na którym resolver obsługuje zapytania przez Web API. Istniejący standard DNSSEC stosuje szyfrowanie głównie do uwierzytelniania klienta i serwera, ale nie chroni ruchu przed przechwyceniem i nie gwarantuje poufności zapytań.
Źródło: opennet.ru
