Después de dos años y medio de desarrollo, el consorcio ISC presentó la primera versión estable de una rama significativa del servidor DNS BIND 9.20, que incorpora cambios desarrollados en la rama experimental BIND 9.19. El soporte para la rama 9.20 se proporcionará en el marco de un ciclo de mantenimiento ampliado hasta el primer trimestre de 2028. El soporte para la rama 9.18 se interrumpirá en el segundo trimestre de 2025. Se formará una rama experimental BIND 9.21.0 para desarrollar la funcionalidad de la próxima versión estable de BIND. El código del proyecto está escrito en C y se distribuye bajo la licencia MPL 2.0.
Principales cambios:
- El núcleo de la aplicación, que conecta todos los componentes, ha sido trasladado a un ciclo de procesamiento de eventos en modo no bloqueante, implementado sobre la biblioteca libuv, utilizada en proyectos como Node.js, Knot DNS, H2O, Luvit y MoarVM. En la rama 9.16, el gestor de conexiones de red en BIND se trasladó a libuv, y ahora también las partes utilizadas para la interacción de los componentes internos de la infraestructura, así como los manejadores asistenciales de largas ejecuciones en hilos separados (threadpool), utilizados para la verificación de DNSSEC, el traslado de zonas, el mantenimiento del directorio de zonas y el procesamiento de RPZ (Response Policy Zone). Ahora se requiere al menos la versión 1.34.0 de libuv para compilar BIND.
- Se ha propuesto un nuevo backend para el trabajo con bases de datos — «QP trie», que sustituye a RBTDB (Red-Black Tree Database) y se utiliza por defecto para el almacenamiento de la caché y la base de zonas DNS. Para el trabajo multihilo en QP trie, se ha empleado la biblioteca liburcu con la implementación en el espacio de usuario de estructuras que no utilizan bloqueos, gracias al uso del mecanismo de sincronización RCU (read-copy-update) y del método de liberación segura de memoria QSBR (Quiescent-State-Based Reclamation).
- Se ha implementado un mecanismo de compresión actualizado de nombres de dominio, que utiliza un método de codificación más compacto para nombres con un mayor número de etiquetas.
- Se han ampliado las capacidades de DNSSEC: se permite aplicar «dnssec-policy» para gestionar zonas firmadas (se eliminó la opción auto-dnssec); al utilizar «inline-signing» se ha añadido soporte para la RFC 8901 (modelo multi-firmante DNSSEC 2); se ha reintroducido el soporte PKCS#11 basado en OpenSSL 3.0.0 Engine API; se ha añadido soporte HSM (Hardware Security Module) en «dnssec-policy».
- Se agregó soporte para la segunda versión del catálogo de zonas (Catalog Zone, RFC 9432), que simplifica el mantenimiento de servidores DNS secundarios al permitir que, en lugar de definir en el servidor secundario registros separados para cada zona secundaria, se organice una transmisión del catálogo de zonas secundarias entre los servidores primarios y secundarios. Después de configurar la transmisión del catálogo de manera similar a la transmisión de zonas individuales, las zonas creadas en el servidor primario y marcadas como parte del catálogo se crean automáticamente en el servidor secundario sin necesidad de modificar archivos de configuración.
- Se agregó soporte para el mecanismo de errores extendidos (Extended DNS Errors, RFC 8914), que permite devolver información adicional sobre la causa de un error ocurrido al realizar una consulta DNS.
- La implementación de las tecnologías 'DNS sobre HTTPS' (DoH, DNS over HTTPS) y DNS sobre TLS (DoT, DNS over TLS), utilizadas para cifrar las consultas de los clientes al resolutor y el intercambio de datos cifrados entre servidores, ha sido actualizada para utilizar un transporte unificado.
- Se agregó la posibilidad de utilizar el protocolo PROXYv2 con todos los transportes soportados en BIND. El protocolo PROXY permite transmitir información de conexión para conservar detalles sobre la dirección IP original y el número de puerto al enrutarse las consultas DNS a través de otros backend, balanceadores de carga y proxies.servidores.
- Se agregó soporte para el modo USDT (User Statically Defined Tracing), que permite realizar trazas de la aplicación utilizando el comando perf, sin crear costos adicionales cuando la traza está desactivada.
- La estadística recopilada refleja información sobre operaciones entrantes de transferencia de zonas que no se han completado.
- Se realizó un trabajo para reducir las latencias, disminuir el consumo de memoria y reducir la carga en la CPU durante la resolución, el funcionamiento de DNS-over-TLS y la formación de respuestas por UDP y TCP.
Fuente: opennet.ru
