Seguindo empresa Google sobre a intención de realizar un experimento para probar a implementación "DNS over HTTPS" (DoH, DNS over HTTPS) que se está a desenvolver para o navegador Chrome. Chrome 78, programado para o 22 de outubro, terá algunhas categorías de usuarios por defecto para usar DoH. Só os usuarios cuxa configuración actual do sistema especifique determinados provedores de DNS recoñecidos como compatibles con DoH participarán no experimento para activar o DoH.
A lista branca de provedores de DNS inclúe 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), Limpeza Quad185.228.168.168. 185.228.169.168, 185.222.222.222) e DNS.SB (185.184.222.222, XNUMX). Se a configuración de DNS do usuario especifica un dos servidores DNS mencionados anteriormente, DoH en Chrome activarase de forma predeterminada. Para aqueles que usan servidores DNS proporcionados polo seu provedor de Internet local, todo permanecerá inalterado e o resolvedor do sistema seguirá utilizándose para as consultas de DNS.
Unha diferenza importante coa implementación de DoH en Firefox, que gradualmente habilitou DoH por defecto xa a finais de setembro, é a falta de vinculación a un servizo de DoH. Se está en Firefox por defecto Servidor DNS de CloudFlare, entón Chrome só actualizará o método de traballo con DNS a un servizo equivalente, sen cambiar o provedor de DNS. Por exemplo, se o usuario ten especificado o DNS 8.8.8.8 na configuración do sistema, Chrome o fará Servizo de Google DoH ("https://dns.google.com/dns-query"), se o DNS é 1.1.1.1, entón o servizo de Cloudflare DoH ("https://cloudflare-dns.com/dns-query") e
Se o desexa, o usuario pode activar ou desactivar DoH mediante a configuración "chrome://flags/#dns-over-https". Admítense tres modos de funcionamento: seguro, automático e desactivado. No modo "seguro", os anfitrións determínanse só en función de valores seguros previamente almacenados na memoria caché (recibidos mediante unha conexión segura) e solicitudes a través de DoH; non se aplica a alternativa ao DNS normal. No modo "automático", se o DoH e a caché segura non están dispoñibles, os datos pódense recuperar da caché insegura e acceder a través do DNS tradicional. No modo "desactivado", compróbase primeiro a caché compartida e, se non hai datos, a solicitude envíase a través do DNS do sistema. O modo establécese mediante kDnsOverHttpsMode e o modelo de asignación do servidor a través de kDnsOverHttpsTemplates.
O experimento para habilitar DoH levarase a cabo en todas as plataformas compatibles con Chrome, a excepción de Linux e iOS debido á natureza non trivial de analizar a configuración do resolutor e restrinxir o acceso á configuración de DNS do sistema. Se, despois de habilitar DoH, hai problemas para enviar solicitudes ao servidor DoH (por exemplo, debido ao seu bloqueo, conexión de rede ou fallo), o navegador devolverá automaticamente a configuración DNS do sistema.
O propósito do experimento é probar finalmente a implementación do DoH e estudar o impacto do uso do DoH no rendemento. Cómpre sinalar que, de feito, o apoio DoH foi no código base de Chrome en febreiro, pero para configurar e habilitar DoH iniciar Chrome cunha bandeira especial e un conxunto de opcións non obvias.
Lembremos que DoH pode ser útil para evitar filtracións de información sobre os nomes de host solicitados a través dos servidores DNS dos provedores, combater ataques MITM e suplantación de tráfico DNS (por exemplo, cando se conecta a wifi pública), contrarrestar o bloqueo no DNS. nivel (DoH non pode substituír unha VPN na área de evitar o bloqueo implementado a nivel de DPI) ou para organizar o traballo se é imposible acceder directamente aos servidores DNS (por exemplo, cando se traballa a través dun proxy). Se nunha situación normal as solicitudes de DNS envíanse directamente aos servidores DNS definidos na configuración do sistema, entón no caso de DoH, a solicitude para determinar o enderezo IP do host encápsulase no tráfico HTTPS e envíase ao servidor HTTP, onde o resolutor procesa. solicitudes a través da API web. O estándar DNSSEC existente usa o cifrado só para autenticar o cliente e o servidor, pero non protexe o tráfico da intercepción e non garante a confidencialidade das solicitudes.
Fonte: opennet.ru