Chrome 78 sāks eksperimentus ar DNS-over-HTTPS ieviešanu

Pēc tam, kad Mozilla kompānija Google ziņoja par nodomu veikt eksperimentu, lai pārbaudītu izstrādāto piedāvājumu pārlūkprogrammai Chrome par "DNS virs HTTPS" (DoH, DNS over HTTPS). Versijā Chrome 78, kas plānota iznākšanai 22. oktobrī, daži lietotāji grupi tiks iestatīti pēc noklusējuma pārvērstas uz DoH izmantošanu. Eksperimentā par DoH iesaistīsies tikai tie lietotāji, kuru pašreizējās sistēmas iestatījumos ir norādīti noteikti DNS pakalpojumu sniedzēji, kas atzīti par DoH saderīgiem.

Lietotāju sarakstā ir iekļauti pakalpojumi 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) un DNS.SB (185.222.222.222, 185.184.222.222). Ja lietotāja DNS iestatījumos ir norādīti kāds no iepriekš minētajiem DNS serveriem, DoH Chrome tiks aktivizēts pēc noklusējuma. Lietotājiem, kas izmanto vietējo interneta pakalpojumu sniedzēja DNS serverus, viss paliks nemainīgs, un DNS pieprasījumiem turpinās izmantot sistēmas rezolveri.

Svarīga atšķirība no DoH ieviešanas Firefox, kurā pakāpeniska DoH aktivizēšana pēc noklusējuma sākas jau septembra beigās, ir saistīta ar to, ka nav piesaistes vienam DoH pakalpojumu sniedzējam. Ja Firefox pēc noklusējuma tiek izmantota izmanto Cloudflare DNS serveri, tad Chrome tikai atjauninās matēriju DNS apstrādē uz ekvivalentu pakalpojumu, nesniedzot DNS pakalpojumu sniedzēja maiņu. Piemēram, ja lietotāja sistēmas iestatījumos ir norādīts DNS 8.8.8.8, tad Chrome izmantos ir aktivizēts DoH pakalpojumu Google ("https://dns.google.com/dns-query"), ja DNS ir 1.1.1.1, tad DoH pakalpojums Cloudflare ("https://cloudflare-dns.com/dns-query") un utt.

Ja nepieciešams, lietotājs var aktivizēt vai deaktivizēt DoH, izmantojot iestatījumu "chrome://flags/#dns-over-https". Ir atbalstīti trīs darbības režīmi: "secure", "automatic" un "off". Režīmā "secure" resursi tiek noteikti tikai balstoties uz iepriekš kešētām drošām vērtībām (iegūtām caur drošu savienojumu) un pieprasījumiem caur DoH, atgriešanās uz parasto DNS netiek veikta. Režīmā "automatic", ja DoH un drošais kešs nav pieejami, ir atļauts iegūt datus no nedroša keša un pieslēgties caur tradicionālo DNS. Režīmā "off" vispirms tiek pārbaudīts kopējais kešs, un, ja nav datu, pieprasījums tiek nosūtīts caur sistēmas DNS. Režīmu nosaka caur iestatījumu kDnsOverHttpsMode, un serveru saskaņošanas šablons ir caur kDnsOverHttpsTemplates.

Eksperiments par DoH aktivizēšanu tiks veikts visās Chrome atbalstītajās platformās, izņemot Linux un iOS, jo ir sarežģīti analizēt resolveru iestatījumus un ierobežots piekļuves līmenis sistēmas DNS iestatījumiem. Ja pēc DoH aktivizēšanas rastos problēmas ar pieprasījumu nosūtīšanu uz DoH serveri (piemēram, tā bloķēšanas, tīkla savienojamības pārtraukuma vai kļūmes dēļ), pārlūks automātiski atgriezīsies pie sistēmas DNS iestatījumiem.

Eksperimenta mērķis ir galīgā DoH īstenošanas pārbaude un DoH ietekmes uz veiktspēju izpēte. Jāatzīmē, ka faktiskā DoH atbalsts pievienots iekļauta Chrome koda bāzē jau februārī, taču DoH aktīvas lietošanas sākšanai bija nepieciešama Chrome palaišana ar īpašu karogu un neskaidru opciju kopumu.

Atgādinām, ka DoH var būt noderīgs, lai novērstu informācijas noplūdes par pieprasītajiem resursdatoru nosaukumiem caur pakalpojumu sniedzēju DNS serveriem, cīņā pret MITM uzbrukumiem un DNS satiksmes viltošanu (piemēram, pieslēdzoties publiskam Wi-Fi), kā arī, lai pretrunētu DNS līmeņa bloķēšanai (DoH nevar aizvietot VPN bloķēšanas apiet spējās, kas īstenotas DPI līmenī) vai, lai organizētu darbību gadījumā, ja nav iespējams tieši sazināties ar DNS serveriem (piemēram, strādājot caur starpniekserveri). Parastā situācijā DNS pieprasījumi tiek tieši nosūtīti uz sistēmas konfigurācijā noteiktiem DNS serveriem, bet DoH gadījumā pieprasījums par resursdatora IP adreses noteikšanu tiek inkapsulēts HTTPS satiksmē un nosūtīts uz HTTP serveri, kur rezolvētājs apstrādā pieprasījumus caur Web API. Esošais DNSSEC standarts izmanto šifrēšanu tikai klienta un servera autentifikācijai, bet nepasargā satiksmi no noklausīšanās un garantē privātumu pieprasījumos.

Avots: opennet.lv