Los desarrolladores del servidor DNS BIND han anunciado la incorporación en la rama experimental 9.17 de la implementación de soporte del servidor para las tecnologías «DNS sobre HTTPS» (DoH, DNS over HTTPS) y DNS sobre TLS (DoT, DNS over TLS), así como el mecanismo XFR-over-TLS para la transmisión segura del contenido de las zonas DNS entre servidores. DoH está disponible para pruebas en la versión 9.17.10, y el soporte para DoT está presente desde la versión 9.17.7. Una vez estabilizado, el soporte para DoT y DoH será regresado a la rama estable 9.16.
La implementación del protocolo HTTP/2, utilizado en DoH, se basa en el uso de la biblioteca nghttp2, que está incluida entre las dependencias de construcción (más adelante, se planea trasladar la biblioteca a las dependencias opcionales). Se admiten tanto conexiones cifradas (TLS) como no cifradas a través de HTTP/2. Con la configuración adecuada, un proceso named ahora puede atender no solo solicitudes DNS tradicionales, sino también solicitudes enviadas utilizando DoH (DNS-over-HTTPS) y DoT (DNS-over-TLS). El soporte para HTTPS del lado del cliente (dig) aún no está implementado. El soporte para XFR-over-TLS está disponible tanto para solicitudes entrantes como salientes.
El procesamiento de solicitudes utilizando DoH y DoT se activa mediante la adición de las opciones http y tls en la directiva listen-on. Para soportar DNS-over-HTTP no cifrado, en la configuración se debe especificar «tls none». Las claves se definen en la sección «tls». Los puertos de red estándar 853 para DoT, 443 para DoH y 80 para DNS-over-HTTP pueden ser redefinidos a través de los parámetros tls-port, https-port y http-port. Por ejemplo: tls local-tls { key-file «/path/to/priv_key.pem»; cert-file «/path/to/cert_chain.pem»; }; http local-http-server { endpoints { «/dns-query»; }; }; options { https-port 443; listen-on port 443 tls local-tls http myserver {any;}; }
De las características de la implementación de DoH en BIND, se destaca la integración como un transporte común que puede ser utilizado no solo para el procesamiento de solicitudes de clientes al resolutor, sino también durante el intercambio de datos entre servidores, al transferir zonas a través del servidor DNS autoritativo y al procesar cualquier solicitud admitida por otros transportes DNS.
Otra característica es la posibilidad de externalizar las operaciones de cifrado para TLS en otro servidor, lo que puede ser necesario en situaciones donde los certificados TLS se almacenan en otro sistema (por ejemplo, en infraestructura con servidores web) y son gestionados por otro personal. Se ha implementado soporte para DNS sin cifrar sobre HTTP para facilitar la depuración y como un nivel para el reenvío en la red interna, sobre el cual se puede organizar la encriptación en otro servidor. En el servidor externo para la generación de tráfico TLS se puede utilizar nginx, de manera similar a cómo se organiza el encapsulamiento HTTPS para los sitios.
Recordemos que DNS-over-HTTPS puede ser útil para evitar fugas de información sobre los nombres de host solicitados a través de los servidores DNS de los proveedores, luchar contra ataques MITM y la suplantación de tráfico DNS (por ejemplo, al conectarse a Wi-Fi público), y enfrentar bloqueos a nivel de DNS (DNS-over-HTTPS no puede reemplazar VPN en el ámbito de eludir bloqueos, implementados a nivel de DPI) o para organizar el funcionamiento en caso de que no se pueda acceder directamente a los servidores DNS (por ejemplo, al trabajar a través de un proxy). Si en situaciones normales las solicitudes DNS se envían directamente a los servidores DNS especificados en la configuración del sistema, en el caso de DNS-over-HTTPS la solicitud para resolver IP el host se encapsula en el tráfico HTTPS y se envía a un servidor HTTP, donde el resolvedor maneja las solicitudes a través de Web API.
«DNS over TLS» se diferencia de «DNS over HTTPS» por la aplicación del protocolo DNS estándar (generalmente se utiliza el puerto de red 853), envuelto en un canal de comunicación cifrada, organizado mediante el protocolo TLS con verificación de validez del host a través de certificados TLS/SSL, firmados por una autoridad certificadora. El estándar existente DNSSEC utiliza cifrado solo para la autenticación del cliente y del servidor, pero no protege el tráfico de la intercepción y no garantiza la confidencialidad de las solicitudes.
Fuente: opennet.ru
