Desarrolladores de Firefox
Después de activar DoH, se muestra una advertencia al usuario que le permite, si lo desea, negarse a contactar con los servidores DNS centralizados de DoH y volver al esquema tradicional de enviar consultas no cifradas al servidor DNS del proveedor. En lugar de una infraestructura distribuida de solucionadores de DNS, DoH utiliza un enlace a un servicio DoH específico, que puede considerarse un punto único de falla. Actualmente, el trabajo se ofrece a través de dos proveedores de DNS: CloudFlare (predeterminado) y
Cambiar de proveedor o desactivar DoH
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.
Para seleccionar los proveedores de DoH ofrecidos en Firefox,
DoH debe usarse con precaución. Por ejemplo, en la Federación de Rusia, las direcciones IP 104.16.248.249 y 104.16.249.249 asociadas con el servidor DoH predeterminado mozilla.cloudflare-dns.com que se ofrece en Firefox,
El DoH también puede causar problemas en áreas como los sistemas de control parental, el acceso a espacios de nombres internos en los sistemas corporativos, la selección de rutas en los sistemas de optimización de la entrega de contenidos y el cumplimiento de órdenes judiciales en el ámbito de la lucha contra la distribución de contenidos ilegales y la explotación de menores. Para evitar estos problemas, se ha implementado y probado un sistema de verificación que desactiva automáticamente el DoH bajo ciertas condiciones.
Para identificar los solucionadores empresariales, se verifican los dominios de primer nivel (TLD) atípicos y el solucionador del sistema devuelve direcciones de intranet. Para determinar si los controles parentales están habilitados, se intenta resolver el nombre exampleadultsite.com y si el resultado no coincide con la IP real, se considera que el bloqueo de contenido para adultos está activo a nivel de DNS. Las direcciones IP de Google y YouTube también se verifican como señales para ver si han sido reemplazadas por restrict.youtube.com, forcesafesearch.google.com y restrictmoderate.youtube.com. Estas comprobaciones permiten a los atacantes que controlan el funcionamiento del solucionador o que son capaces de interferir con el tráfico simular dicho comportamiento para desactivar el cifrado del tráfico DNS.
Trabajar a través de un único servicio DoH también puede generar problemas con la optimización del tráfico en las redes de entrega de contenido que equilibran el tráfico mediante DNS (el servidor DNS de la red CDN genera una respuesta teniendo en cuenta la dirección de resolución y proporciona el host más cercano para recibir el contenido). Enviar una consulta de DNS desde el solucionador más cercano al usuario en dichas CDN da como resultado que se devuelva la dirección del host más cercano al usuario, pero enviar una consulta de DNS desde un solucionador centralizado devolverá la dirección del host más cercana al servidor DNS sobre HTTPS. . Las pruebas en la práctica mostraron que el uso de DNS sobre HTTP cuando se utiliza una CDN prácticamente no provocó retrasos antes del inicio de la transferencia de contenido (para conexiones rápidas, los retrasos no superaron los 10 milisegundos, y se observó un rendimiento aún más rápido en canales de comunicación lentos). ). También se consideró el uso de la extensión EDNS Client Subnet para proporcionar información de ubicación del cliente al solucionador CDN.
Fuente: opennet.ru