Sekvante Guglo-firmao pri la intenco fari eksperimenton por testi la efektivigon "DNS over HTTPS" (DoH, DNS over HTTPS) evoluantan por la retumilo Chrome. Chrome 78, planita por la 22-a de oktobro, havos kelkajn uzantkategoriojn defaŭlte uzi DoH. Nur uzantoj, kies nunaj sistemaj agordoj specifas iujn DNS-provizantojn agnoskitajn kiel kongruajn kun DoH, partoprenos la eksperimenton por ebligi DoH.
La blanka listo de DNS-provizantoj inkluzivas Guglo (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), Quad185.228.168.168 (185.228.169.168, 185.222.222.222. 185.184.222.222, XNUMX) kaj DNS.SB (XNUMX, XNUMX). Se la DNS-agordoj de la uzanto specifas unu el la supre menciitaj DNS-serviloj, DoH en Chrome estos aktivigita defaŭlte. Por tiuj, kiuj uzas DNS-servilojn provizitajn de sia loka interreta provizanto, ĉio restos senŝanĝa kaj la sistema solvilo daŭre estos uzata por DNS-demandoj.
Grava diferenco de la efektivigo de DoH en Fajrovulpo, kiu iom post iom ebligis DoH defaŭlte jam fine de septembro, estas la manko de ligado al unu DoH-servo. Se en Firefox defaŭlte CloudFlare DNS-servilo, tiam Chrome nur ĝisdatigos la metodon labori kun DNS al ekvivalenta servo, sen ŝanĝi la DNS-provizanton. Ekzemple, se la uzanto havas DNS 8.8.8.8 specifita en la sistemaj agordoj, tiam Chrome faros Google DoH-servo ("https://dns.google.com/dns-query"), se DNS estas 1.1.1.1, tiam Cloudflare DoH-servo ("https://cloudflare-dns.com/dns-query") Kaj
Se vi deziras, la uzanto povas ebligi aŭ malŝalti DoH uzante la agordon "chrome://flags/#dns-over-https". Tri operaciumoj estas subtenataj: sekura, aŭtomata kaj malŝaltita. En "sekura" reĝimo, gastigantoj estas determinitaj nur surbaze de antaŭe konservitaj sekuraj valoroj (ricevitaj per sekura konekto) kaj petoj per DoH; restarigo al regula DNS ne estas aplikata. En la "aŭtomata" reĝimo, se DoH kaj la sekura kaŝmemoro estas neatingeblaj, datumoj povas esti prenitaj de la nesekura kaŝmemoro kaj alireblaj per tradicia DNS. En "for" reĝimo, la komuna kaŝmemoro unue estas kontrolita kaj se ne estas datumoj, la peto estas sendita per la sistemo DNS. La reĝimo estas agordita per kDnsOverHttpsMode , kaj la servila mapa ŝablono per kDnsOverHttpsTemplates.
La eksperimento por ebligi DoH estos efektivigita sur ĉiuj platformoj subtenataj en Chrome, kun la escepto de Linukso kaj iOS pro la ne-triviala naturo de analizado de solvigaj agordoj kaj limigado de aliro al sistemaj DNS-agordoj. Se, post ebligo de DoH, estas problemoj sendi petojn al la DoH-servilo (ekzemple pro ĝia blokado, reto-konekto aŭ malsukceso), la retumilo aŭtomate resendos la sistemajn DNS-agordojn.
La celo de la eksperimento estas finfine testi la efektivigon de DoH kaj studi la efikon de uzado de DoH sur efikeco. Oni devas rimarki, ke fakte DoH-subteno estis en la Chrome-kodbazon en februaro, sed por agordi kaj ebligi DoH lanĉante Chrome kun speciala flago kaj nekomprenebla aro de opcioj.
Ni rememoru, ke DoH povas esti utila por malhelpi likojn de informoj pri la petitaj gastigantnomoj tra la DNS-serviloj de provizantoj, kontraŭbatali MITM-atakojn kaj DNS-trafikan falsigon (ekzemple, kiam li konektas al publika Wi-Fi), kontraŭbatali blokadon ĉe la DNS. nivelo (DoH ne povas anstataŭigi VPN en la areo de preterpasi blokadon efektivigita ĉe la DPI-nivelo) aŭ por organizi laboron se estas neeble rekte aliri DNS-servilojn (ekzemple, kiam vi laboras per prokurilo). Se en normala situacio DNS-petoj estas rekte senditaj al DNS-serviloj difinitaj en la sistema agordo, tiam en la kazo de DoH, la peto por determini la IP-adreson de la gastiganto estas enkapsuligita en HTTPS-trafiko kaj sendita al la HTTP-servilo, kie la solvilo procesas. petoj per la Reta API. La ekzistanta DNSSEC-normo uzas ĉifradon nur por aŭtentikigi la klienton kaj servilon, sed ne protektas trafikon kontraŭ interkapto kaj ne garantias la konfidencon de petoj.
fonto: opennet.ru