Resumo

  • Lançado em 2 de setembro, o NSD 4.15.2 inclui uma correção que associa a conferência do certificado às condições de endereço e TSIG da mesma regra.
  • O relato original trata de uma transferência legítima recusada quando havia uma segunda identidade configurada. Os testes cobrem dois certificados válidos, mas não todas as combinações do ambiente relatado.

Uma mudança de configuração pode aumentar a lista de permissões e, ainda assim, diminuir o que funciona. Foi esse o paradoxo descrito por um usuário do NSD: com duas regras para servidores secundários distintos, uma transferência era recusada; com apenas uma, passava.

O relato de 24 de julho usa NSD 4.14.0 do EPEL sobre RHEL 9.8 como servidor primário, com dois secundários executando outros programas. Cada um tinha endereço e nome de certificado próprios. As regras compartilhavam uma chave TSIG. Os registros indicavam negociação TLS bem-sucedida, TSIG aceito e correspondência com o primeiro nome, seguida de divergência em relação ao segundo e recusa da transferência.

Em 28 de agosto, um mantenedor afirmou ter reproduzido e corrigido o problema. O anúncio da versão 4.15.2, de 2 de setembro, inclui expressamente a correção. Na checagem de 8 de setembro, a página oficial de downloads ainda a indicava como versão atual.

O material não relata uma indisponibilidade generalizada. Os endereços privados pertencem ao ensaio descrito, não a um mapa público de redes afetadas. Tampouco há, na conversa, um novo teste do autor do relato após o lançamento. A confirmação do mantenedor e a inclusão no pacote não equivalem a uma medição de recuperação de clientes.

O nome pertence a uma regra, não à lista inteira

Na alteração de código, a comparação do nome do certificado passa a compor a avaliação do mesmo item que contém as condições de endereço e chave TSIG. Antes, uma verificação separada dos nomes podia encerrar o processo com falha ao encontrar outra identidade.

Um certificado com nome errado continua sem atender à regra correspondente. O ajuste evita que a diferença esperada em relação a uma segunda identidade invalide uma combinação legítima. Regras explícitas de bloqueio continuam relevantes; seria incorreto reduzir toda a autorização do NSD a uma política irrestrita de aceitar qualquer coincidência.

A implicação fica clara durante a renovação de certificados. Manter dois nomes válidos por algum tempo deveria oferecer alternativas previstas, não exigir que o mesmo cliente fosse os dois. Um painel que acompanhe apenas a abertura da sessão TLS pode deixar de perceber que a zona não chegou ao destinatário.

O alcance real da prova

O acréscimo ao teste de regressão introduz um segundo certificado e sua regra. No teste completo associado à versão publicada, cada identidade válida deve obter um marcador do conteúdo da zona. Permanecem verificações que impedem esse resultado com nome errado, autoridade certificadora desconhecida e solicitações sem certificado de cliente.

Há um limite importante: as duas regras de certificado do teste aceitam qualquer origem IPv4 e usam NOKEY. O relato inicial combinava endereços distintos e uma chave TSIG comum. As asserções testam a convivência de identidades, não esgotam todas as associações entre endereço, chave e nome. Este artigo examinou fontes e testes; não executou NSD nem realizou uma reprodução independente.

Outra regra do ensaio permite, separadamente, transferências com TSIG por TLS comum ou TCP. Isso expressa uma autorização configurada, não uma nova burla. O RFC 9103 distingue autenticação de confidencialidade: TSIG não criptografa, por si só, o conteúdo transferido. Proteger um grupo inteiro de transferências exige uma política para cada relação relevante, não apenas uma conexão cifrada funcionando.

Também é preciso separar este caso da CVE-2026-12490, descrita nos avisos de segurança de NLnet Labs. Aquele problema de contorno da exigência de certificado foi divulgado em junho e corrigido em 4.14.3. Seu identificador e sua faixa de versões não devem ser atribuídos à recusa por múltiplas identidades discutida aqui. Não há comprovação de nova exploração, contagem de clientes atingidos ou matriz completa de versões afetadas.

A defesa de condições de segurança precisas e verificáveis localmente, feita por Lu Heng, permite uma aplicação restrita ao caso: explicitar a combinação que autoriza o acesso, sem afrouxá-la silenciosamente para obter sucesso. Trata-se de uma interpretação editorial, não de uma avaliação de NSD atribuída a ele.