Efter firmaet Google om planen om at gennemføre et eksperiment for at teste implementeringen af "DNS over HTTPS" (DoH, DNS over HTTPS) udviklet til browseren Chrome. I udgivelsen af Chrome 78, der er planlagt til 22. oktober, vil nogle brugergrupper som standard til at bruge DoH. Eksperimentet med aktivering af DoH vil kun inkludere brugere, hvis nuværende systemindstillinger angiver bestemte DNS-udbydere, der er anerkendt som kompatible med DoH.
De DNS-udbydere, der er inkluderet på hvidlisten, er 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 en af de nævnte DNS-servere er angivet i brugerens DNS-indstillinger, aktiveres DoH i Chrome som standard. For dem, der bruger DNS-servere leveret af lokale internetudbydere, forbliver alt uændret, og systemresolveren fortsætter med at blive brugt til DNS-forespørgsler.
En vigtig forskel fra implementeringen af DoH i Firefox, hvor den gradvise aktivering af DoH som standard allerede i slutningen af september, er fraværet af binding til en enkelt DoH-tjeneste. I Firefox er CloudFlare DNS-serveren som standard, mens Chrome kun vil opdatere metoden til at arbejde med DNS til en ækvivalent tjeneste uden at ændre DNS-udbyderen. For eksempel, hvis brugeren har angivet DNS 8.8.8.8 i systemindstillingerne, vil Chrome aktiverer Googles DoH-service ("https://dns.google.com/dns-query"), mens hvis DNS er 1.1.1.1, aktiverer DoH-tjenesten fra Cloudflare ("https://cloudflare-dns.com/dns-query") og
Brugeren kan efter eget ønske aktivere eller deaktivere DoH ved hjælp af indstillingen "chrome://flags/#dns-over-https". Der understøttes tre driftsformer: "secure", "automatic" og "off". I "secure"-tilstand identificeres værter udelukkende baseret på tidligere cachede sikre værdier (fået gennem en sikker forbindelse) og forespørgsler via DoH; tilbagevenden til almindelig DNS anvendes ikke. I "automatic"-tilstand, hvis DoH og den sikre cache ikke er tilgængelige, er det tilladt at hente data fra en usikker cache og at anmode via traditionel DNS. I "off"-tilstand kontrolleres den almindelige cache først, og hvis der ikke findes nogen data, sendes forespørgslen gennem system-DNS. Driftsformen angives gennem kDnsOverHttpsMode, og server-matching skabelonen via kDnsOverHttpsTemplates.
Eksperimentet med at aktivere DoH vil blive udført på alle understøttede platforme i Chrome, undtagen Linux og iOS på grund af kompleksiteten i at analysere resolver-indstillingerne og begrænsninger i adgangen til systemindstillingerne for DNS. Hvis der opstår problemer med at sende anmodninger til DoH-serveren efter aktivering af DoH (for eksempel på grund af dens blokering, netværksproblemer eller nedbrud), vil browseren automatisk returnere de systemmæssige DNS-indstillinger.
Formålet med eksperimentet er den endelige kontrol af implementeringen af DoH og undersøgelsen af indflydelsen af DoH på ydeevnen. Det skal bemærkes, at støtten til DoH faktisk blev tilføjet til Chrome-kodebasen allerede i februar, men aktivering og indstilling af DoH start af Chrome med et særligt flag og en uklar samling af indstillinger.
Lad os minde om, at DoH kan være nyttigt til at undgå lækager af informationer om de anmodede værtens navne gennem DNS-servere fra udbydere, bekæmpelse af MITM-angreb og DNS-trafikmanipulation (for eksempel når man tilslutter sig offentlige Wi-Fi), modvirke blokeringer på DNS-niveau (DoH kan ikke erstatte VPN i forhold til at omgå blokeringer, der er implementeret på DPI-niveau) eller til at organisere arbejdet i tilfælde af, at direkte adgang til DNS-servere ikke er mulig (for eksempel ved brug af proxy). I normale situationer sendes DNS-anmodninger direkte til de DNS-servere, der er angivet i systemkonfigurationen, mens med DoH, indkapsles anmodningen om at bestemme IP-adressen i HTTPS-trafikken og sendes til HTTP-serveren, hvor resolveren behandler anmodningerne via Web API. Den eksisterende standard DNSSEC bruger kryptering kun til at autentificere klienten og serveren, men beskytter ikke trafikken mod aflytning og garanterer ikke fortroligheden af anmodningerne.
Kilde: opennet.ru
