Los desarrolladores del servidor DNS BIND anunciaron la incorporación de soporte de servidor para las tecnologías DNS sobre HTTPS (DoH, DNS sobre HTTPS) y DNS sobre TLS (DoT, DNS sobre TLS), así como el mecanismo XFR sobre TLS para seguridad. transferir el contenido de las zonas DNS entre servidores. DoH está disponible para pruebas en la versión 9.17 y la compatibilidad con DoT ha estado presente desde la versión 9.17.10. Después de la estabilización, la compatibilidad con DoT y DoH se trasladará a la rama estable 9.17.7.
La implementación del protocolo HTTP/2 utilizado en DoH se basa en el uso de la biblioteca nghttp2, que se incluye entre las dependencias del ensamblador (en el futuro, se planea transferir la biblioteca a una serie de dependencias opcionales). Se admiten conexiones HTTP/2 cifradas (TLS) y no cifradas. Con la configuración adecuada, un proceso con un solo nombre ahora puede atender no solo consultas DNS tradicionales, sino también consultas enviadas mediante DoH (DNS sobre HTTPS) y DoT (DNS sobre TLS). La compatibilidad con HTTPS en el lado del cliente (dig) aún no está implementada. La compatibilidad con XFR-over-TLS está disponible para solicitudes entrantes y salientes.
El procesamiento de solicitudes mediante DoH y DoT se habilita agregando las opciones http y tls a la directiva de escucha. Para admitir DNS sobre HTTP sin cifrar, debe especificar "tls none" en la configuración. Las claves se definen en la sección "tls". Los puertos de red predeterminados 853 para DoT, 443 para DoH y 80 para DNS sobre HTTP se pueden anular mediante los parámetros tls-port, https-port y http-port. Por ejemplo: tls local-tls { archivo-clave "/ruta/a/priv_key.pem"; archivo-cert "/ruta/a/cert_chain.pem"; }; http servidor-http local {puntos finales { "/dns-query"; }; }; opciones { https-puerto 443; puerto de escucha 443 tls local-tls http myserver {cualquiera;}; }
Entre las características de la implementación de DoH en BIND, se destaca la integración como un transporte general, que se puede utilizar no solo para procesar solicitudes de clientes al resolutor, sino también al intercambiar datos entre servidores, al transferir zonas mediante un servidor DNS autorizado y al procesar cualquier solicitud respaldada por otros transportes DNS.
Otra característica es la capacidad de mover operaciones de cifrado para TLS a otro servidor, lo que puede ser necesario en condiciones en las que los certificados TLS se almacenan en otro sistema (por ejemplo, en una infraestructura con servidores web) y son mantenidos por otro personal. Se implementa soporte para DNS sobre HTTP no cifrado para simplificar la depuración y como una capa para el reenvío en la red interna, sobre la base de la cual se puede organizar el cifrado en otro servidor. En un servidor remoto, nginx se puede utilizar para generar tráfico TLS, de forma similar a cómo se organiza el enlace HTTPS para los sitios web.
Recordemos que DNS-over-HTTPS puede ser útil para prevenir 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 de tráfico DNS (por ejemplo, al conectarse a una red Wi-Fi pública), contrarrestar bloquear a nivel DNS (DNS-over-HTTPS no puede reemplazar una VPN para evitar el bloqueo implementado a nivel DPI) o para organizar el trabajo cuando 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 DNS sobre HTTPS, 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 API web.
"DNS sobre TLS" se diferencia de "DNS sobre HTTPS" en el uso del protocolo DNS estándar (normalmente se utiliza el puerto de red 853), envuelto en un canal de comunicación cifrado organizado utilizando el protocolo TLS con verificación de validez del host a través de certificados TLS/SSL certificados. por una autoridad de certificación. 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