Resumen

  • NSD 4.15.2, publicado el 2 de septiembre, comprueba el nombre del certificado junto con la dirección y TSIG de la misma entrada de acceso.
  • El caso que motivó la corrección era un rechazo indebido al coexistir dos identidades autorizadas, no una intrusión demostrada. Las pruebas permiten distinguir esa reparación de una validación completa del despliegue.

Quitar una regla hizo que la transferencia volviera a funcionar. El dato resulta incómodo para quien acaba de añadir un servidor secundario con su propio certificado: la nueva autorización debería ampliar las alternativas permitidas, no invalidar una que ya funcionaba.

Eso es lo que describió un usuario en el informe del 24 de julio. Su ensayo empleaba NSD 4.14.0 de EPEL sobre RHEL 9.8 como primario y dos secundarios con otro software. Cada secundario tenía una dirección y un nombre de certificado propios; las dos entradas compartían una clave TSIG. Los registros mostraban una negociación TLS correcta, TSIG aceptado y la coincidencia del primer nombre. Después aparecía una discrepancia con el otro nombre y se denegaba la transferencia. Una sola entrada no provocaba el problema.

El 28 de agosto, un mantenedor comunicó que había reproducido el fallo y aplicado una solución. La publicación de NSD 4.15.2, del 2 de septiembre, incluye expresamente la corrección. El portal de descargas seguía señalando esa versión como actual al comprobarlo el 8 de septiembre.

Son evidencias de un ensayo, una reproducción del mantenedor y la inclusión del cambio en una versión. No documentan una interrupción generalizada ni una nueva comprobación del informante después de actualizar. Las direcciones privadas del ejemplo tampoco describen una red pública afectada.

Una identidad no necesita ser todas las identidades

El cambio de implementación evalúa conjuntamente la dirección, la clave TSIG y el nombre del certificado dentro de cada entrada. Antes, una comprobación separada de nombres podía devolver un fallo al encontrar otra identidad.

No se elimina la obligación de presentar el nombre exigido. Si el nombre no corresponde a una entrada, esa entrada no coincide. Lo que se evita es que la diferencia respecto de otra alternativa descalifique indebidamente una coincidencia válida. Siguen existiendo reglas explícitas de bloqueo; no cabe resumir toda la política de NSD como una autorización automática ante cualquier coincidencia.

La diferencia importa al renovar certificados. Durante una transición pueden convivir dos nombres válidos. El cliente debe satisfacer la combinación que le corresponde, no convertirse simultáneamente en ambos. También explica por qué el establecimiento del canal cifrado es una señal insuficiente: puede haber sesión sin entrega de la zona.

Dos éxitos y varios rechazos

La modificación de las pruebas incorpora una segunda identidad de certificado. El ensayo completo fijado a la versión publicada exige que cada certificado válido obtenga un marcador del contenido transferido. También comprueba que no se obtenga en casos de nombre incorrecto, autoridad certificadora desconocida y solicitudes sin certificado de cliente.

Pero sus dos entradas basadas en certificados admiten cualquier origen IPv4 y usan NOKEY. El informe original combinaba direcciones distintas y una clave TSIG compartida. Por tanto, la prueba cubre las identidades múltiples, no todas las combinaciones de origen, clave y nombre de aquel montaje. Este artículo examina código y aserciones; no ejecuta NSD ni presenta una reproducción independiente.

Otra entrada del ensayo permite transferencias autenticadas mediante TSIG por TLS ordinario o TCP. Es una alternativa autorizada de forma explícita, no un nuevo acceso indebido. RFC 9103 distingue autenticación y confidencialidad: TSIG no cifra por sí mismo el contenido de la zona. La política debe decidir qué protección exige en cada relación del grupo de transferencia.

Conviene además no mezclar este rechazo con CVE-2026-12490. Los avisos de seguridad de NLnet Labs sitúan ese problema distinto de elusión del certificado en junio y su corrección en 4.14.3. No hay base para atribuir a este cambio de septiembre su identificador o su intervalo de versiones afectadas. Tampoco se acredita una explotación nueva, un número de clientes perjudicados o una matriz exhaustiva de versiones.

La idea de Lu Heng de mantener condiciones de seguridad precisas y verificables localmente ofrece una lectura acotada: definir la combinación que concede acceso, sin relajarla de manera silenciosa. Es una aplicación editorial del principio, no una valoración de NSD realizada por Lu Heng.