DNS sobre HTTPS está habilitado de forma predeterminada en Firefox para usuarios de EE. UU.

Desarrolladores de Firefox ellos proclamaron sobre cómo habilitar el modo DNS sobre HTTPS (DoH, DNS sobre HTTPS) de forma predeterminada para usuarios de EE. UU. El cifrado del tráfico DNS se considera un factor de fundamental importancia para proteger a los usuarios. A partir de hoy, todas las instalaciones nuevas realizadas por usuarios de EE. UU. tendrán DoH habilitado de forma predeterminada. Está previsto que los usuarios actuales de EE. UU. pasen al DoH en unas pocas semanas. En la Unión Europea y otros países, activar DoH por defecto por ahora no planees.

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 NextDNS.

DNS sobre HTTPS está habilitado de forma predeterminada en Firefox para usuarios de EE. UU.

Cambiar de proveedor o desactivar DoH uno puede en la configuración de conexión de red. Por ejemplo, puede especificar un servidor DoH alternativo “https://dns.google/dns-query” para acceder a los servidores de Google, “https://dns.quad9.net/dns-query” - Quad9 y “https:/ /doh.opendns.com/dns-query" - OpenDNS. About:config también proporciona la configuración network.trr.mode, a través de la cual puede cambiar el modo de funcionamiento de DoH: un valor de 0 desactiva completamente DoH; 1 - Se utiliza DNS o DoH, lo que sea más rápido; 2: DoH se utiliza de forma predeterminada y DNS se utiliza como opción alternativa; 3 - sólo se utiliza DoH; 4 - modo de duplicación en el que se utilizan DoH y DNS en paralelo.

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, requisitos a solucionadores de DNS confiables, según los cuales el operador de DNS puede utilizar los datos recibidos para la resolución solo para garantizar el funcionamiento del servicio, no debe almacenar registros durante más de 24 horas, no puede transferir datos a terceros y está obligado a revelar información sobre métodos de procesamiento de datos. El servicio también debe comprometerse a no censurar, filtrar, interferir o bloquear el tráfico DNS, excepto en las situaciones previstas por la ley.

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, listado в listas bloqueo Roskomnadzor a solicitud del tribunal de Stavropol de 10.06.2013 de junio de XNUMX.

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

Añadir un comentario