I Chrome 78 vil eksperimenter med DNS-over-HTTPS begynne

Følger etter Mozilla Google meldte om intensjonen om å gjennomføre et eksperiment for å teste implementeringen av «DNS over HTTPS» (DoH, DNS over HTTPS) som utvikles for nettleseren Chrome. I utgaven av Chrome 78, som er planlagt for 22. oktober, vil noen brukergrupper bli aktivert som standard oversatt til bruk av DoH. Bare brukere med spesifikke DNS-leverandører som er anerkjent som kompatible med DoH, vil delta i eksperimentet for å aktivere DoH.

DNS-leverandører på hvitelisten inkluderer tjenester 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) og DNS.SB (185.222.222.222, 185.184.222.222). Hvis brukeren har en av de nevnte DNS-serverne i DNS-innstillingene, vil DoH aktiveres som standard i Chrome. For de som bruker DNS-servere fra lokale internettleverandører, vil alt forbli uendret, og systemoppløseren vil fortsatt bli brukt for DNS-forespørslene.

En viktig forskjell fra implementeringen av DoH i Firefox, der DoH blir aktivert gradvis som standard starter allerede mot slutten av september, er den manglende koblingen til én DoH-tjeneste. I Firefox er DNS-serveren CloudFlare satt som standard, mens Chrome bare vil oppdatere metoden for å håndtere DNS til en ekvivalent tjeneste, uten å bytte DNS-leverandør. For eksempel, hvis brukeren har DNS 8.8.8.8 i systeminnstillingene, vil Chrome blir utnyttet aktivere DoH-tjenesten Google («https://dns.google.com/dns-query»), hvis DNS er 1.1.1.1, så DoH-tjenesten Cloudflare («https://cloudflare-dns.com/dns-query») og slike ting. Hvis ønskelig, kan brukeren aktivere eller deaktivere DoH ved hjelp av innstillingen «chrome://flags/#dns-over-https». Det støttes tre driftsmodi: «secure», «automatic» og «off». I «secure»-modus bestemmes vertsnavn kun basert på tidligere bufrede sikre verdier (erhentet via en sikker forbindelse) og forespørslene via DoH; tilbake til vanlig DNS brukes ikke. I «automatic»-modus, hvis DoH og den sikre bufferen ikke er tilgjengelig, tillates det å hente data fra usikret buffer og forespørsel via tradisjonell DNS. I «off»-modus blir den generelle bufferen først sjekket, og hvis ingen data finnes, sendes forespørselen via system-DNS. Modus angis ved hjelp av

innstillingen kDnsOverHttpsMode, og mønsteret for servermetning gjennom kDnsOverHttpsTemplates. kDnsOverHttpsMode, og mal for servermatching via kDnsOverHttpsTemplates.

Eksperimentet med implementering av DoH vil bli gjennomført på alle plattformer som støttes av Chrome, unntatt Linux og iOS på grunn av kompleksiteten ved å håndtere innstillinger for resolveren og begrenset tilgang til systeminnstillinger for DNS. Hvis det oppstår problemer med å sende forespørslene til DoH-serveren (for eksempel på grunn av blokkering, nettverksproblemer eller serverfeil) etter aktivering av DoH, vil nettleseren automatisk bruke systeminnstillinger for DNS.

Målet med eksperimentet er å gjøre en endelig sjekk av implementeringen av DoH og å studere effekten av bruken av DoH på ytelsen. Det bør bemerkes at støtten for DoH faktisk ble lagt er det lagt til til kodebasen i Chrome tilbake i februar, men for å konfigurere og aktivere DoH var det nødvendig å starte Chrome med et spesialflagg og en ikke-innlysende sett med alternativer.

Vi minner om at DoH kan være nyttig for å unngå lekkasjer av informasjon om forespurte vertsnavn gjennom DNS-serverne til leverandørene, bekjempe MITM-angrep og forfalskning av DNS-trafikk (for eksempel når man kobler seg til offentlige Wi-Fi-nettverk), motstå blokkering på DNS-nivå (DoH kan ikke erstatte VPN når det gjelder å omgå blokkeringer implementert på DPI-nivå) eller for å organisere drift når direkte tilgang til DNS-servere ikke er mulig (for eksempel ved bruk av proxy). I en vanlig situasjon sendes DNS-forespørslene direkte til de spesifiserte DNS-serverne i systemkonfigurasjonen, mens i tilfelle av DoH blir forespørselen for å bestemme IP-adressen til verten innkapslet i HTTPS-trafikk og sendt til en HTTP-server, hvor resolveren håndterer forespørslene via Web API. Den eksisterende standarden DNSSEC bruker kryptering kun for autentisering av klient og server, men beskytter ikke trafikken mot avlytting og garanterer ikke konfidensialitet for forespørslene.

Kilde: opennet.ru