Después de dos años de desarrollo, el consorcio ISC ha presentado la primera versión estable de la nueva y significativa rama del servidor DNS BIND 9.18. El soporte para la rama 9.18 se mantendrá durante tres años, hasta el segundo trimestre de 2025, como parte de un ciclo de soporte ampliado. El soporte para la rama 9.11 finalizará en marzo, y el de la rama 9.16 a mediados de 2023. Para el desarrollo de la funcionalidad de la próxima versión estable de BIND, se ha formado una rama experimental BIND 9.19.0.
El lanzamiento de BIND 9.18.0 es notable por la implementación del soporte para tecnologías de «DNS sobre HTTPS» (DoH, DNS over HTTPS) y DNS sobre TLS (DoT, DNS over TLS), así como el mecanismo XoT (XFR-over-TLS) para la transmisión segura de contenido de zonas DNS entre servidores (se admite tanto la entrega como la recepción de zonas a través de XoT). Con las configuraciones adecuadas, un proceso named ahora puede manejar no solo consultas DNS tradicionales, sino también consultas enviadas utilizando DNS-over-HTTPS y DNS-over-TLS. El soporte del cliente para DNS-over-TLS está integrado en la utilidad dig, que puede utilizarse para enviar consultas sobre TLS especificando el flag «+tls».
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 de construcción opcionales. Los certificados para DoH y DoT pueden ser proporcionados por el usuario o generados automáticamente al iniciar.
El procesamiento de consultas utilizando DoH y DoT se activa agregando las opciones «http» y «tls» en la directiva listen-on. Para admitir DNS sin cifrado sobre HTTP, 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 sobre HTTP pueden ser sobreescritos 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;}; }
Entre las características de la implementación de DoH en BIND se destaca la posibilidad de delegar las operaciones de cifrado para TLS a otro servidor, lo que puede ser necesario en situaciones donde los certificados TLS se almacenan en otro sistema (por ejemplo, en una infraestructura con servidores web) y son gestionados por otro personal. El soporte de DNS-over-HTTP no cifrado se ha implementado para facilitar la depuración y como un nivel para redirigir a otro servidor en la red interna (para delegar el cifrado a un servidor separado). En el servidor delegado, se puede utilizar nginx para generar tráfico TLS, similar a cómo se organiza la envoltura HTTPS para los sitios.
Otra característica es la integración de DoH como un transporte común, que puede aplicarse no solo para manejar las solicitudes de los clientes al resolutor, sino también en el intercambio de datos entre servidores, durante la transferencia de zonas por parte del servidor DNS autoritativo y al manejar cualquier solicitud admitida por otros transportes DNS.
Entre las desventajas que se pueden compensar deshabilitando la compilación con DoH/DoT o delegando el cifrado a otro servidor, se destaca la complejidad general de la base del código: se añade un servidor HTTP embebido y una biblioteca TLS, que potencialmente pueden contener vulnerabilidades y servir como vectores adicionales para ataques. Además, el uso de DoH incrementa el tráfico.
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.
Algunas otras novedades:
- Se añadieron configuraciones para tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer y udp-send-buffer para establecer los tamaños de los buffers utilizados al enviar y recibir solicitudes por TCP y UDP. En servidores con alta carga, aumentar los buffers de entrada ayudará a evitar la pérdida de paquetes durante picos de tráfico, mientras que reducirlos ayudará a eliminar la congestión de memoria con solicitudes antiguas.
- Se añadió una nueva categoría de registros ‘rpz-passthru’, que permite registrar por separado las acciones de redirección de RPZ (Zonas de Políticas de Respuesta).
- En la sección de política de respuesta se agregó la opción ‘nsdname-wait-recurse’, que al establecerse en ‘no’ aplica las reglas de RPZ NSDNAME solamente si se encuentran servidores de nombres autoritativos en caché para la solicitud; de lo contrario, la regla RPZ NSDNAME se ignora, pero la información se extrae en segundo plano y se aplica a las solicitudes posteriores.
- Se ha implementado el manejo de la sección ‘ADDITIONAL’ para registros de tipos HTTPS y SVCB.
- Se han agregado tipos de reglas personalizables update-policy: krb5-subdomain-self-rhs y ms-subdomain-self-rhs, que permiten restringir la actualización de registros SRV y PTR. También se ha añadido la capacidad de establecer límites en el número de registros por tipo en los bloques de update-policy.
- Se han añadido detalles sobre el protocolo de transporte (UDP, TCP, TLS, HTTPS) y los prefijos DNS64 en la salida de la utilidad dig. Para fines de depuración, se ha agregado la opción de especificar un identificador de solicitud concreto (dig +qid=).
- Se ha añadido soporte para la biblioteca OpenSSL 3.0.
- Para resolver problemas de fragmentación de IP al procesar mensajes DNS grandes, marcados por la iniciativa DNS Flag Day 2020, se ha eliminado del resolvedor el código que ajustaba el tamaño del búfer EDNS en caso de no recibir respuesta a la consulta. El tamaño del búfer EDNS ahora se establece de forma constante (edns-udp-size) para todas las consultas salientes.
- El sistema de compilación se ha trasladado a usar una combinación de autoconf, automake y libtool.
- Se ha dejado de soportar archivos de zona en formato «map» (masterfile-format map). A los usuarios de este formato se les recomienda convertir las zonas al formato raw utilizando la utilidad named-compilezone.
- Se ha dejado de soportar controladores antiguos DLZ (Dynamically Loadable Zones), que han sido reemplazados por módulos DLZ.
- Se ha dejado de soportar la compilación y ejecución en la plataforma Windows. La última versión que se puede instalar en Windows es BIND 9.16.
Fuente: opennet.ru
