Siguiente empresa google sobre la intención de realizar un experimento para probar la implementación “DNS sobre HTTPS” (DoH, DNS sobre HTTPS) que se está desarrollando para el navegador Chrome. Chrome 78, previsto para el 22 de octubre, tendrá algunas categorías de usuarios por defecto para utilizar DoH. Solo los usuarios cuya configuración actual del sistema especifique ciertos proveedores de DNS reconocidos como compatibles con DoH participarán en el experimento para habilitar 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, 185.222.222.222) y DNS.SB (185.184.222.222, XNUMX). Si la configuración DNS del usuario especifica uno de los servidores DNS mencionados anteriormente, DoH en Chrome se habilitará de forma predeterminada. Para aquellos que utilizan servidores DNS proporcionados por su proveedor de Internet local, todo permanecerá sin cambios y el solucionador del sistema seguirá utilizándose para consultas DNS.
Una diferencia importante con la implementación de DoH en Firefox, que gradualmente habilitó DoH de forma predeterminada ya a finales de septiembre, es la falta de vinculación a un servicio DoH. Si está en Firefox por defecto servidor DNS CloudFlare, Chrome solo actualizará el método de trabajo con DNS a un servicio equivalente, sin cambiar el proveedor de DNS. Por ejemplo, si el usuario tiene DNS 8.8.8.8 especificado en la configuración del sistema, Chrome Servicio Google DoH (“https://dns.google.com/dns-query”), si DNS es 1.1.1.1, entonces servicio Cloudflare DoH (“https://cloudflare-dns.com/dns-query”) Y
Si lo desea, el usuario puede habilitar o deshabilitar DoH usando la configuración “chrome://flags/#dns-over-https”. Se admiten tres modos de funcionamiento: seguro, automático y apagado. En el modo "seguro", los hosts se determinan únicamente en función de valores seguros previamente almacenados en caché (recibidos a través de una conexión segura) y solicitudes a través de DoH; no se aplica el respaldo al DNS normal. En el modo "automático", si DoH y el caché seguro no están disponibles, los datos se pueden recuperar del caché inseguro y acceder a ellos a través del DNS tradicional. En modo “off”, primero se verifica el caché compartido y si no hay datos, la solicitud se envía a través del DNS del sistema. El modo se establece mediante kDnsOverHttpsMode y la plantilla de asignación del servidor a través de kDnsOverHttpsTemplates.
El experimento para habilitar DoH se llevará a cabo en todas las plataformas compatibles con Chrome, con la excepción de Linux e iOS debido a la naturaleza no trivial de analizar la configuración del solucionador y restringir el acceso a la configuración DNS del sistema. Si, después de habilitar DoH, hay problemas para enviar solicitudes al servidor DoH (por ejemplo, debido a su bloqueo, conectividad de red o falla), el navegador devolverá automáticamente la configuración DNS del sistema.
El propósito del experimento es probar finalmente la implementación de DoH y estudiar el impacto del uso de DoH en el rendimiento. Cabe señalar que, de hecho, el apoyo del Departamento de Salud fue en el código base de Chrome en febrero, pero para configurar y habilitar DoH iniciar Chrome con una bandera especial y un conjunto de opciones no obvio.
Recordemos que DoH puede resultar útil para prevenir la filtración de información sobre los nombres de host solicitados a través de los servidores DNS de los proveedores, combatir los ataques MITM y la suplantación de tráfico DNS (por ejemplo, al conectarse a una red Wi-Fi pública), contrarrestar el bloqueo en el DNS nivel (DoH no puede reemplazar una VPN en el área de eludir el bloqueo implementado en el nivel DPI) o para organizar el trabajo si es imposible acceder directamente a los servidores DNS (por ejemplo, cuando se trabaja a través de un proxy). Si en una situación normal las solicitudes DNS se envían directamente a los servidores DNS definidos en la configuración del sistema, entonces, en el caso de DoH, la solicitud para determinar la dirección IP del host se encapsula en el tráfico HTTPS y se envía al servidor HTTP, donde el solucionador procesa solicitudes a través de la API web. El estándar DNSSEC existente utiliza cifrado sólo para autenticar al cliente y al servidor, pero no protege el tráfico contra la interceptación y no garantiza la confidencialidad de las solicitudes.
Fuente: opennet.ru