Google Chrome
Después de Mozilla, Google anunció su intención de realizar un experimento para probar la implementación del navegador de Chrome con «DNS sobre HTTPS» (DoH, DNS sobre HTTPS). Con el lanzamiento de Chrome 78, prevista para el 22 de octubre.
Algunas categorías de usuarios por defecto podrán participar en el experimento para habilitar DoH, solo los usuarios participarán en la configuración actual del sistema, de la cual se reconocen ciertos proveedores de DNS que son compatibles con DoH.
La lista blanca de proveedores de DNS incluye servicios de Google, Cloudflare, OpenDNS, Quad9, Cleanbrowsing y DNS.SB. Si la configuración de DNS del usuario especifica uno de los servidores DNS anteriores, DoH en Chrome se activará de manera predeterminada.
Para aquellos que usan los servidores DNS proporcionados por el proveedor local de servicios de Internet, todo permanecerá sin cambios y la resolución del sistema continuará usándose para consultas DNS.
Una diferencia importante con respecto a la implementación de DoH en Firefox, en la que la inclusión gradual del DoH predeterminado comenzará a fines de septiembre, es la falta de vinculación a un único servicio DoH.
Si Firefox usa el servidor DNS CloudFlare de manera predeterminada, Chrome solo actualizará el método de trabajar con DNS a un servicio equivalente, sin cambiar el proveedor de DNS.
Si lo desea, el usuario puede habilitar o deshabilitar DoH utilizando la configuración «chrome://flags/ #dns-over-https». Además se admiten tres modos de funcionamiento «seguro», «automático» y «apagado».
- En el modo «seguro», los hosts se determinan solo en función de los valores seguros previamente almacenados en caché (recibidos a través de una conexión segura) y las solicitudes a través de DoH, no se aplica la reversión al DNS normal.
- En el modo «automático», si DoH y el caché seguro no están disponibles, es posible recibir datos de un caché inseguro y acceder a través del DNS tradicional.
- En el modo «apagado», el caché general se verifica primero y, si no hay datos, la solicitud se envía a través del DNS del sistema. El modo se establece a través de la configuración de kDnsOverHttpsMode y la plantilla de mapeo del servidor a través de kDnsOverHttpsTemplates.
El experimento para habilitar DoH se llevará a cabo en todas las plataformas compatibles en Chrome, con la excepción de Linux e iOS, debido a la naturaleza no trivial del análisis de la configuración del resolutor y el acceso limitado a la configuración del sistema DNS.
En el caso de que después de habilitar DoH haya fallas al enviar solicitudes al servidor DoH (por ejemplo, debido a su bloqueo, falla o falla de conectividad de red), el navegador devolverá automáticamente la configuración del sistema DNS.
El propósito del experimento es finalizar la implementación de DoH y examinar el impacto de la aplicación DoH en el rendimiento.
Cabe señalar que, de hecho, el soporte DoH se agregó a la base de código de Chrome en febrero, pero para configurar y habilitar DoH , Chrome debía lanzarse con un indicador especial y un conjunto de opciones no obvio.
Es importante saber que DoH puede ser útil para eliminar fugas de información sobre los nombres de host solicitados a través de los servidores DNS de los proveedores, combatir los ataques MITM y reemplazar el tráfico DNS (por ejemplo, cuando se conecta a Wi-Fi público) y oponerse al bloqueo de nivel DNS (DoH) no puede reemplazar una VPN en el área de evitar bloqueos implementados 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 situaciones normales, las consultas 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 en el que el resolutor procesa las solicitudes a través de la API web.
El estándar DNSSEC existente usa encriptación solo para la autenticación de clientes y servidores.