Después de dos años de desarrollo, el consorcio ISC ha lanzado la primera versión estable de una nueva e importante rama del servidor DNS BIND 9.18. El soporte para la rama 9.18 se brindará durante tres años hasta el segundo trimestre de 2 como parte de un ciclo de soporte extendido. El soporte para la rama 2025 finalizará en marzo y el soporte para la rama 9.11 a mediados de 9.16. Para desarrollar la funcionalidad de la próxima versión estable de BIND, se ha formado una rama experimental BIND 2023.
El lanzamiento de BIND 9.18.0 se destaca por la implementación de soporte para DNS sobre HTTPS (DoH, DNS sobre HTTPS) y DNS sobre TLS (DoT, DNS sobre TLS), así como el mecanismo XoT (XFR-over-TLS). para una transferencia segura de contenido DNS zonas entre servidores (se admiten zonas de envío y recepción a través de XoT). 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 DNS sobre HTTPS y DNS sobre TLS. La compatibilidad del cliente con DNS sobre TLS está integrada en la utilidad dig, que se puede utilizar para enviar solicitudes a través de TLS cuando se especifica el indicador "+tls".
La implementación del protocolo HTTP/2 utilizado en DoH se basa en el uso de la biblioteca nghttp2, que se incluye como una dependencia de ensamblaje opcional. Los certificados para DoH y DoT pueden ser proporcionados por el usuario o generarse automáticamente en el momento del inicio.
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;}; }
Una de las características de la implementación de DoH en BIND 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 se mantienen. por otro personal. Se implementa soporte para DNS sobre HTTP no cifrado para simplificar la depuración y como una capa para reenviar a otro servidor en la red interna (para mover el cifrado a un servidor separado). 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.
Otra característica es la integración de DoH como transporte general que se puede utilizar no solo para manejar solicitudes de clientes al resolutor, sino también cuando se comunica entre servidores, cuando se transfieren zonas mediante un servidor DNS autorizado y cuando se procesan consultas admitidas por otros DNS. transportes.
Entre las deficiencias que se pueden compensar desactivando la compilación con DoH/DoT o moviendo el cifrado a otro servidor, destaca la complicación general del código base: se añaden un servidor HTTP integrado y una biblioteca TLS, que potencialmente podría contener vulnerabilidades y actúan como vectores adicionales de ataques. Además, cuando se utiliza DoH, el tráfico aumenta.
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.
Algunas otras innovaciones:
- Se agregaron configuraciones 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 a través de TCP y UDP. En servidores ocupados, aumentar los buffers entrantes ayudará a evitar que los paquetes se caigan durante los picos de tráfico, y disminuirlos ayudará a eliminar la obstrucción de la memoria con solicitudes antiguas.
- Se ha agregado una nueva categoría de registro "rpz-passthru", que le permite registrar por separado acciones de reenvío RPZ (Zonas de política de respuesta).
- En la sección de política de respuesta, se agregó la opción "nsdname-wait-recurse". Cuando se establece en "no", las reglas de RPZ NSDNAME se aplican solo si se encuentran servidores de nombres autorizados presentes en el caché para la solicitud; La regla RPZ NSDNAME se ignora, pero la información se recupera en segundo plano y se aplica a solicitudes posteriores.
- Para registros con tipos HTTPS y SVCB se ha implementado el procesamiento de la sección “ADICIONAL”.
- Se agregaron tipos de reglas de política de actualización personalizadas: krb5-subdomain-self-rhs y ms-subdomain-self-rhs, que le permiten limitar la actualización de registros SRV y PTR. Los bloques de política de actualización también agregan la capacidad de establecer límites en la cantidad de registros, individuales para cada tipo.
- Se agregó información sobre el protocolo de transporte (UDP, TCP, TLS, HTTPS) y los prefijos DNS64 a la salida de la utilidad dig. Para fines de depuración, dig ha agregado la capacidad de especificar un identificador de solicitud específico (dig +qid= ).
- Se agregó soporte para la biblioteca OpenSSL 3.0.
- Para abordar los problemas con la fragmentación de IP al procesar mensajes DNS grandes identificados por el Día de la Bandera de DNS 2020, se eliminó del solucionador el código que ajusta el tamaño del búfer EDNS cuando no hay respuesta a una solicitud. El tamaño del búfer EDNS ahora está configurado en constante (edns-udp-size) para todas las solicitudes salientes.
- El sistema de compilación ha pasado a utilizar una combinación de autoconf, automake y libtool.
- Se ha interrumpido la compatibilidad con archivos de zona en formato "mapa" (mapa en formato masterfile). Se recomienda a los usuarios de este formato convertir zonas al formato sin formato utilizando la utilidad llamada-compilezone.
- Se suspendió la compatibilidad con controladores DLZ (zonas de carga dinámica) más antiguos y se reemplazó por módulos DLZ.
- Se ha descontinuado el soporte de compilación y ejecución para la plataforma Windows. La última rama que se puede instalar en Windows es BIND 9.16.
Fuente: opennet.ru