Siguiendo a la empresa Google sobre su intención de llevar a cabo un experimento para verificar la implementación de «DNS sobre HTTPS» (DoH, DNS over HTTPS) desarrollada para el navegador Chrome. En la versión Chrome 78, programada para el 22 de octubre, algunas categorías de usuarios utilizarán DoH de forma predeterminada. En el experimento de habilitación de DoH, solo participarán los usuarios cuyos ajustes de sistema actuales indiquen ciertos proveedores de DNS reconocidos como compatibles con DoH.
La lista blanca de proveedores de DNS incluye 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) y DNS.SB (185.222.222.222, 185.184.222.222). Si uno de los servidores DNS mencionados está indicado en la configuración de DNS del usuario, DoH se activará por défaut en Chrome. Para aquellos que utilizan servidores DNS proporcionados por su proveedor de internet local, todo permanecerá sin cambios y se seguirá utilizando el resolvedor de sistema para las consultas DNS.
Una diferencia importante en la implementación de DoH en Firefox, donde la habilitación gradual de DoH por defecto a finales de septiembre, es la ausencia de vinculación a un solo servicio de DoH. Si en Firefox se utiliza por defecto el servidor DNS de CloudFlare, en Chrome solo se actualizará el método de trabajo con DNS a un servicio equivalente, sin cambiar al proveedor de DNS. Por ejemplo, si un usuario tiene configurado el DNS 8.8.8.8 en sus ajustes, en Chrome se utilizará el servicio DoH de Google («https://dns.google.com/dns-query»), si el DNS es 1.1.1.1, el servicio DoH será Cloudflare («https://cloudflare-dns.com/dns-query») y
Si lo desea, el usuario podrá habilitar o deshabilitar DoH mediante la configuración «chrome://flags/#dns-over-https». Se admiten tres modos de operación: «secure», «automatic» y «off». En el modo «secure», los hosts se determinan únicamente en base a valores seguros previamente almacenados en caché (obtenidos a través de una conexión segura) y consultas mediante DoH, sin aplicar reversión a DNS convencional. En el modo «automatic», si DoH y la caché segura no están disponibles, se permite obtener datos de la caché insegura y realizar consultas a través de DNS tradicional. En el modo «off», primero se verifica la caché general y si no hay datos, la consulta se envía a través de DNS del sistema. El modo se establece mediante kDnsOverHttpsMode, y el patrón de coincidencia de servidores a través de kDnsOverHttpsTemplates.
El experimento para activar DoH se realizará en todas las plataformas compatibles con Chrome, excepto Linux e iOS debido a la complejidad de procesar la configuración del resolutor y a la limitación del acceso a la configuración del DNS del sistema. En caso de que tras activar DoH se produzcan fallos al enviar solicitudes al servidor DoH (por ejemplo, debido a bloqueos, pérdida de conectividad de red o fallos), el navegador volverá automáticamente a la configuración DNS del sistema.
El objetivo de este experimento es realizar una verificación final de la implementación de DoH y estudiar el impacto del uso de DoH en el rendimiento. Cabe señalar que el soporte para DoH había sido integrado en el código base de Chrome desde febrero, pero se requería Recordemos que DoH puede ser útil para evitar fugas de información sobre los nombres de host solicitados a través de los servidores DNS de los proveedores, combatir ataques MITM y la suplantación del tráfico DNS (por ejemplo, al conectarse a Wi-Fi público), contra los bloqueos a nivel de DNS (DoH no puede reemplazar a un VPN en eludir bloqueos implementados a nivel de DPI) o para facilitar el trabajo cuando no se puede acceder directamente a los servidores DNS (por ejemplo, al trabajar a través de un proxy). En situaciones normales, las consultas DNS se envían directamente a los servidores DNS configurados en el sistema, pero en el caso de DoH, la consulta para determinar la dirección IP del host se encapsula en el tráfico HTTPS y se envía a un servidor HTTP, donde el resolutor procesa las solicitudes a través de la API Web. El estándar existente DNSSEC utiliza cifrado solo para autenticar al cliente y al servidor, pero no protege el tráfico contra la interceptación ni garantiza la confidencialidad de las solicitudes.
A continuación, la empresa Google
Fuente: opennet.ru
