Volgende Google maatskappy oor die voorneme om 'n eksperiment uit te voer om die "DNS oor HTTPS" (DoH, DNS oor HTTPS) implementering te toets wat vir die Chrome-blaaier ontwikkel word. Chrome 78, wat vir 22 Oktober geskeduleer is, sal by verstek sekere gebruikerskategorieë hê om DoH te gebruik. Slegs gebruikers wie se huidige stelselinstellings sekere DNS-verskaffers spesifiseer wat erken word as versoenbaar met DoH, sal aan die eksperiment deelneem om DoH te aktiveer.
Die wit lys van DNS-verskaffers sluit in 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), skoonmaak (185.228.168.168. 185.228.169.168, 185.222.222.222) en DNS.SB (185.184.222.222, XNUMX). As die gebruiker se DNS-instellings een van die bogenoemde DNS-bedieners spesifiseer, sal DoH in Chrome by verstek geaktiveer word. Vir diegene wat DNS-bedieners gebruik wat deur hul plaaslike internetverskaffer verskaf word, sal alles onveranderd bly en die stelseloplosser sal voortgaan om vir DNS-navrae gebruik te word.
'n Belangrike verskil van die implementering van DoH in Firefox, wat DoH by verstek geleidelik geaktiveer het reeds aan die einde van September, is die gebrek aan binding aan een DoH-diens. As dit by verstek in Firefox is CloudFlare DNS-bediener, dan sal Chrome slegs die metode om met DNS te werk opdateer na 'n ekwivalente diens, sonder om die DNS-verskaffer te verander. Byvoorbeeld, as die gebruiker DNS 8.8.8.8 het wat in die stelselinstellings gespesifiseer is, dan sal Chrome Google DoH-diens (“https://dns.google.com/dns-query”), as DNS 1.1.1.1 is, dan Cloudflare DoH-diens (“https://cloudflare-dns.com/dns-query”) En
As jy wil, kan die gebruiker DoH aktiveer of deaktiveer deur die “chrome://flags/#dns-over-https”-instelling te gebruik. Drie bedryfsmodusse word ondersteun: veilig, outomaties en af. In "veilige" modus word gashere slegs bepaal op grond van voorheen gekas veilige waardes (ontvang via 'n veilige verbinding) en versoeke via DoH; terugval na gewone DNS word nie toegepas nie. In die "outomatiese" modus, as DoH en die veilige kas nie beskikbaar is nie, kan data uit die onveilige kas herwin word en deur tradisionele DNS verkry word. In die "af"-modus word die gedeelde kas eers nagegaan en as daar geen data is nie, word die versoek deur die stelsel DNS gestuur. Die modus word ingestel via kDnsOverHttpsMode , en die bedienerkartering sjabloon deur kDnsOverHttpsTemplates.
Die eksperiment om DoH in staat te stel, sal uitgevoer word op alle platforms wat in Chrome ondersteun word, met die uitsondering van Linux en iOS as gevolg van die nie-triviale aard van die ontleding van resolver-instellings en die beperking van toegang tot stelsel DNS-instellings. As daar, nadat DoH geaktiveer is, probleme is om versoeke na die DoH-bediener te stuur (byvoorbeeld as gevolg van die blokkering, netwerkverbinding of mislukking), sal die blaaier outomaties die stelsel DNS-instellings terugstuur.
Die doel van die eksperiment is om die implementering van DoH finaal te toets en die impak van die gebruik van DoH op prestasie te bestudeer. Daar moet kennis geneem word dat DoH-ondersteuning in werklikheid was in die Chrome-kodebasis terug in Februarie, maar om DoH op te stel en te aktiveer begin Chrome met 'n spesiale vlag en 'n nie-vanselfsprekende stel opsies.
Laat ons onthou dat DoH nuttig kan wees om lekkasies van inligting oor die aangevraagde gasheername deur die DNS-bedieners van verskaffers te voorkom, MITM-aanvalle en DNS-verkeerspoofing te bekamp (byvoorbeeld wanneer u aan openbare Wi-Fi koppel), blokkering by die DNS teenwerk. vlak (DoH kan nie 'n Skynprivaatnetwerk vervang op die gebied van blokkering wat op die DPI-vlak geïmplementeer is omseil nie) of om werk te organiseer as dit onmoontlik is om direk toegang tot DNS-bedieners te verkry (byvoorbeeld wanneer u deur 'n instaanbediener werk). As DNS-versoeke in 'n normale situasie direk na DNS-bedieners gestuur word wat in die stelselkonfigurasie gedefinieer word, dan in die geval van DoH, word die versoek om die gasheer se IP-adres te bepaal in HTTPS-verkeer ingekapsuleer en na die HTTP-bediener gestuur, waar die oplosser prosesseer versoeke via die Web API. Die bestaande DNSSEC-standaard gebruik enkripsie slegs om die kliënt en bediener te verifieer, maar beskerm nie verkeer teen onderskepping nie en waarborg nie die vertroulikheid van versoeke nie.
Bron: opennet.ru