Vervolgens het bedrijf Google heeft aangekondigd een experiment uit te voeren om de implementatie van «DNS over HTTPS» (DoH, DNS over HTTPS) voor de browser Chrome te testen. In versie Chrome 78, gepland voor 22 oktober, zullen bepaalde categorieën gebruikers standaard overgezet naar het gebruik van DoH. Bij het experiment om DoH in te schakelen, zullen alleen gebruikers deelnemen wiens huidige systeeminstellingen bepaalde DNS-providers bevatten die als compatibel met DoH worden erkend.
Op de witte lijst van DNS-providers staan 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) en DNS.SB (185.222.222.222, 185.184.222.222). Als in de DNS-instellingen van de gebruiker een van de bovenstaande DNS-servers is opgegeven, zal DoH in Chrome standaard worden geactiveerd. Voor degenen die de door hun lokale internetprovider geleverde DNS-servers gebruiken, blijft alles ongemoeid en blijft de systeemresolver worden gebruikt voor DNS-aanvragen.
Een belangrijk verschil met de implementatie van DoH in Firefox, waarbij de gefaseerde standaardinschakeling van DoH al eind september, is het ontbreken van een binding aan één DoH-service. Terwijl in Firefox standaard de DoH-service van Google («https://dns.google.com/dns-query») worden geactiveerd, als de DNS — 1.1.1.1 is, dan de DoH-service van Cloudflare («https://cloudflare-dns.com/dns-query») en Indien gewenst kan de gebruiker DoH in- of uitschakelen via de instelling «chrome://flags/#dns-over-https». Drie werkmodi worden ondersteund: «secure», «automatic» en «off». In de «secure»-modus worden hosts alleen bepaald op basis van eerder gecachede veilige waarden (verkregen via een beveiligde verbinding) en verzoeken via DoH, terugval naar de reguliere DNS vindt niet plaats. In de «automatic»-modus is het toegestaan om gegevens uit de onveilige cache te ontvangen en via de traditionele DNS te communiceren als DoH en de beveiligde cache niet beschikbaar zijn. In de «off»-modus wordt eerst de algemene cache gecontroleerd en als er geen gegevens zijn, wordt het verzoek via de systeem-DNS verzonden. De modus wordt ingesteld via
kDnsOverHttpsMode, en het server-matching sjabloon via kDnsOverHttpsTemplates. kDnsOverHttpsTemplates.
Het experiment voor het inschakelen van DoH zal worden uitgevoerd op alle ondersteunde platforms in Chrome, met uitzondering van Linux en iOS vanwege de complexiteit van het verwerken van de instellingen van de resolver en de beperkingen voor toegang tot systeeminstellingen voor DNS. In het geval dat er na het inschakelen van DoH problemen optreden met het verzenden van verzoeken naar de DoH-server (bijvoorbeeld door blokkering, netwerkproblemen of uitval), zal de browser automatisch de systeeminstellingen voor DNS terugzetten.
Het doel van het experiment is de definitieve controle van de implementatie van DoH en het bestuderen van de invloed van het toepassen van DoH op de prestaties. Het is vermeldenswaard dat de ondersteuning voor DoH feitelijk al in de codebase van Chrome in februari is toegevoegd, maar voor het instellen en inschakelen van DoH dat Chrome werd gestart met een speciale vlag en een niet voor de hand liggend aantal opties.
Ter herinnering, DoH kan nuttig zijn om lekken van informatie over aangevraagde hostnamen via de DNS-servers van providers te voorkomen, om MITM-aanvallen en vervalsing van DNS-verkeer te bestrijden (bijvoorbeeld wanneer je verbinding maakt met openbare Wi-Fi), en om blokkades op DNS-niveau te omzeilen (DoH kan VPN niet vervangen in termen van het omzeilen van blokkades die zijn geïmplementeerd op DPI-niveau) of om het werk te organiseren in geval directe toegang tot DNS-servers niet mogelijk is (bijvoorbeeld bij gebruik van een proxy). Terwijl in een normale situatie DNS-verzoeken rechtstreeks naar de in het systeem geconfigureerde DNS-servers worden verzonden, wordt in het geval van DoH het verzoek om het IP-adres van de host ingekapseld in HTTPS-verkeer en verzonden naar een HTTP-server, waar de resolver de verzoeken verwerkt via een Web API. De bestaande standaard DNSSEC gebruikt encryptie alleen voor authenticatie van de client en de server, maar beschermt het verkeer niet tegen onderschepping en garandeert geen vertrouwelijkheid van de verzoeken.
Bron: opennet.ru
