Als vervolg op Google-bedrijf over het voornemen om een experiment uit te voeren om de “DNS over HTTPS” (DoH, DNS over HTTPS)-implementatie te testen die wordt ontwikkeld voor de Chrome-browser. Chrome 78, gepland voor 22 oktober, zal standaard enkele gebruikerscategorieën hebben DoH gebruiken. Alleen gebruikers van wie de huidige systeeminstellingen bepaalde DNS-providers specificeren die als compatibel met DoH worden erkend, zullen deelnemen aan het experiment om DoH in te schakelen.
Inclusief DNS-providers op de witte lijst 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 , 185.222.222.222) en DNS.SB (185.184.222.222, XNUMX). Als de DNS-instellingen van de gebruiker een van de bovengenoemde DNS-servers specificeren, wordt DoH in Chrome standaard ingeschakeld. Voor degenen die DNS-servers van hun lokale internetprovider gebruiken, blijft alles ongewijzigd en blijft de systeemresolver gebruikt voor DNS-query's.
Een belangrijk verschil met de implementatie van DoH in Firefox, waarbij DoH geleidelijk standaard werd ingeschakeld al eind september is er geen sprake meer van binding aan één DoH-dienst. Als het standaard in Firefox is CloudFlare DNS-server, dan zal Chrome de manier van werken met DNS alleen updaten naar een gelijkwaardige dienst, zonder de DNS-provider te wijzigen. Als de gebruiker bijvoorbeeld DNS 8.8.8.8 heeft opgegeven in de systeeminstellingen, zal Chrome dat doen Google DoH-service (“https://dns.google.com/dns-query”), als DNS 1.1.1.1 is, dan Cloudflare DoH-service (“https://cloudflare-dns.com/dns-query”) En
Indien gewenst kan de gebruiker DoH in- of uitschakelen met behulp van de instelling “chrome://flags/#dns-over-https”. Er worden drie bedrijfsmodi ondersteund: veilig, automatisch en uit. In de “beveiligde” modus worden hosts alleen bepaald op basis van eerder in de cache opgeslagen veilige waarden (ontvangen via een beveiligde verbinding) en verzoeken via DoH; er wordt niet teruggevallen op reguliere DNS. In de “automatische” modus, als DoH en de beveiligde cache niet beschikbaar zijn, kunnen gegevens uit de onveilige cache worden opgehaald en toegankelijk worden gemaakt via traditionele DNS. In de “uit”-modus wordt eerst de gedeelde cache gecontroleerd en als er geen gegevens zijn, wordt het verzoek via de systeem-DNS verzonden. De modus wordt ingesteld via kDnsOverHttpsMode en de servertoewijzingssjabloon via kDnsOverHttpsTemplates.
Het experiment om DoH mogelijk te maken zal worden uitgevoerd op alle platforms die in Chrome worden ondersteund, met uitzondering van Linux en iOS vanwege de niet-triviale aard van het parseren van de resolutie-instellingen en het beperken van de toegang tot de DNS-instellingen van het systeem. Als er na het inschakelen van DoH problemen optreden bij het verzenden van verzoeken naar de DoH-server (bijvoorbeeld vanwege blokkering, netwerkconnectiviteit of storing), retourneert de browser automatisch de DNS-instellingen van het systeem.
Het doel van het experiment is om de implementatie van DoH definitief te testen en de impact van het gebruik van DoH op de prestaties te bestuderen. Opgemerkt moet worden dat DoH in feite steun verleende in de Chrome-codebase in februari, maar om DoH te configureren en in te schakelen Chrome lanceren met een speciale vlag en een niet voor de hand liggende reeks opties.
Laten we niet vergeten dat DoH nuttig kan zijn voor het voorkomen van het lekken van informatie over de opgevraagde hostnamen via de DNS-servers van providers, het tegengaan van MITM-aanvallen en spoofing van DNS-verkeer (bijvoorbeeld bij verbinding met openbare Wi-Fi), het tegengaan van blokkering bij de DNS niveau (DoH kan een VPN niet vervangen op het gebied van het omzeilen van blokkeringen geïmplementeerd op DPI-niveau) of voor het organiseren van werk als het onmogelijk is om rechtstreeks toegang te krijgen tot DNS-servers (bijvoorbeeld bij het werken via een proxy). Als in een normale situatie DNS-verzoeken rechtstreeks naar de DNS-servers worden verzonden die in de systeemconfiguratie zijn gedefinieerd, wordt in het geval van DoH het verzoek om het IP-adres van de host te bepalen ingekapseld in HTTPS-verkeer en naar de HTTP-server gestuurd, waar de oplosser de processen verwerkt. aanvragen via de Web API. De bestaande DNSSEC-standaard gebruikt alleen encryptie om de client en server te authenticeren, maar beschermt het verkeer niet tegen onderschepping en garandeert niet de vertrouwelijkheid van verzoeken.
Bron: opennet.ru