Ya fue lanzada la nueva rama estable de DNS BIND 9.18

Después de dos años de desarrollo, ISC lanzó la primera versión estable de una nueva rama importante del servidor DNS BIND 9.18 la cual tendrá soporte durante tres años hasta el segundo trimestre de 2025 como parte de un ciclo de mantenimiento extendido.

El soporte para la rama 9.11 finalizará en marzo y la rama 9.16 a mediados de 2023. Se formó una rama experimental de BIND 9.19.0 para desarrollar la funcionalidad de la próxima versión estable de BIND.

El lanzamiento de BIND 9.18.0 se destaca por la implementación de soporte para las tecnologías DNS sobre HTTPS (DoH, DNS sobre HTTPS) y DNS sobre TLS (DoT, DNS sobre TLS), así como el mecanismo XoT (XFR-over-TLS  para la transmisión segura de contenido DNS sobre TLS zonas entre servidores (se admiten zonas de envío y recepción a través de XoT).

Con la configuración adecuada, un solo proceso con nombre ahora puede atender no solo las consultas de DNS tradicionales, sino también las consultas enviadas mediante DNS sobre HTTPS y DNS sobre TLS. La compatibilidad con el cliente DNS sobre TLS está integrada en la utilidad de excavación, que se puede usar para enviar consultas sobre TLS cuando se especifica el indicador «+tls».

Entre las características de la implementación de DoH en BIND, se destaca la posibilidad de transferir operaciones de cifrado para TLS a otro servidor, lo que puede ser necesario en condiciones donde los certificados TLS se almacenan en otro sistema (por ejemplo, en una infraestructura con servidores web) y atendidos por otro personal. El soporte para DNS sobre HTTP sin cifrar se implementa para simplificar la depuración y como una capa para el reenvío a otro servidor en la red interna (para mover el cifrado a un servidor separado). En un servidor remoto, nginx se puede usar para generar tráfico TLS, de forma similar a cómo se organiza el enlace HTTPS para los sitios.

Principales novedades de DNS BIND 9.18

En esta nueva versión que se presenta podremos encontrar que se agregaron configuraciones tcp-receive-buffer, tcp-send-buffer, udp-receive-buffer y udp-send-buffer para establecer los tamaños de búfer utilizados al enviar y recibir solicitudes a través de TCP y UDP. En servidores ocupados, aumentar los búferes entrantes evitará caídas de paquetes en el momento de los picos de tráfico y reducirlos ayudará a eliminar la obstrucción de la memoria con solicitudes antiguas.

Otro de los cambios que se destaca es que se agregó una nueva categoría de registros «rpz-passthru», que permite registrar por separado las acciones de reenvío de RPZ (Zonas de política de respuesta), ademas de que se agregó la opción «nsdname-wait-recurse» a la sección de política de respuesta, cuando se establece en «no», las reglas RPZ NSDNAME se aplican solo si se encuentran servidores de nombres autorizados presentes en el caché para la solicitud; de lo contrario, la regla RPZ NSDNAME es se ignora, pero la información se recupera en segundo plano y se aplica a solicitudes posteriores.

Para abordar los problemas con la fragmentación de IP al manejar mensajes DNS grandes, identificados por la iniciativa DNS Flag Day 2020, el código que ajusta el tamaño del búfer EDNS en caso de que no se responda a una consulta se eliminó del resolutor. El tamaño del búfer de EDNS ahora se establece constante (edns-udp-size) para todas las solicitudes salientes.

Ademas de ello se eliminó la compatibilidad con archivos de zona en formato de «mapa» (mapa en formato de archivo maestro). Se recomienda a los usuarios de este formato que conviertan las zonas a formato sin formato mediante la utilidad named-compilezone.

De los demás cambios que se destacan:

  • Para registros con tipos HTTPS y SVCB, se implementa el procesamiento de la sección «ADICIONAL».
  • Se agregaron tipos de políticas de actualización personalizadas (krb5-subdomain-self-rhs y ms-subdomain-self-rhs) para restringir las actualizaciones a los registros SRV y PTR. En los bloques de políticas de actualización, también se ha agregado la capacidad de establecer límites en la cantidad de registros, separados 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 de excavación.
  • Se agregó soporte para la biblioteca OpenSSL 3.0.
  • El sistema de compilación se ha cambiado para usar autoconf, automake y libtool.
  • Se eliminó la compatibilidad con los controladores DLZ (zonas cargables dinámicamente) anteriores y se reemplazó por módulos DLZ.
  • Se eliminó 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.

Finalmente si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.


El contenido del artículo se adhiere a nuestros principios de ética editorial. Para notificar un error pincha aquí.

Sé el primero en comentar

Deja tu comentario

Tu dirección de correo electrónico no será publicada.

*

*

  1. Responsable de los datos: Miguel Ángel Gatón
  2. Finalidad de los datos: Controlar el SPAM, gestión de comentarios.
  3. Legitimación: Tu consentimiento
  4. Comunicación de los datos: No se comunicarán los datos a terceros salvo por obligación legal.
  5. Almacenamiento de los datos: Base de datos alojada en Occentus Networks (UE)
  6. Derechos: En cualquier momento puedes limitar, recuperar y borrar tu información.

bool(true)