Résumé

  • Publiée le 2 septembre, NSD 4.15.2 réunit la vérification du nom de certificat, de l’adresse et de TSIG dans la même entrée de contrôle d’accès.
  • Le signalement initial concernait un transfert légitime refusé en présence d’un second nom de certificat. Le test de régression couvre deux identités valides, sans reprendre toutes les conditions du montage signalé.

Un certificat différent n’est pas nécessairement un certificat interdit. Cette évidence devient importante lorsqu’un serveur primaire DNS autorise plusieurs secondaires, chacun avec sa propre identité. Dans le cas corrigé par NSD, la différence attendue entre deux noms pouvait faire échouer un transfert pourtant légitime.

Le signalement du 24 juillet décrit un essai sur RHEL 9.8 avec NSD 4.14.0 fourni par EPEL. Deux serveurs secondaires, utilisant d’autres logiciels, disposent chacun d’une adresse et d’un nom de certificat distincts. Leurs règles de transfert partagent une clé TSIG. Les journaux indiquent une négociation TLS réussie, une authentification TSIG acceptée et un premier nom conforme, puis un désaccord avec l’autre nom avant le refus. Avec une seule règle, le transfert aboutit.

Le mainteneur répond le 28 août avoir reproduit et corrigé le problème. La publication du 2 septembre mentionne expressément cette correction. Le site de téléchargement présentait encore 4.15.2 comme version courante lors de la vérification du 8 septembre. Le fil ne contient toutefois pas de nouveau test du déclarant après cette publication. Il ne documente ni panne généralisée ni bilan de rétablissement chez les utilisateurs.

La bonne combinaison de conditions

Le changement de code replace le contrôle du nom de certificat dans l’évaluation de la même entrée que l’adresse et la clé TSIG. Auparavant, une boucle distincte sur les noms pouvait retourner un échec en rencontrant une autre identité.

Il ne s’agit donc pas de rendre acceptable un mauvais certificat. Un nom incorrect reste incompatible avec la règle qui l’exige. Mais l’échec sur une alternative ne doit plus annuler abusivement une correspondance valable avec une autre. Les règles explicites de blocage restent à prendre en compte : résumer tout le contrôle d’accès par « une correspondance suffit toujours » serait inexact.

La conséquence pratique apparaît lors de l’ajout d’un secondaire ou d’une rotation de certificats. Deux noms peuvent devoir coexister sans qu’un seul client soit tenu de porter les deux. Une supervision limitée à l’établissement de TLS risque alors de constater un canal disponible et de manquer l’essentiel : l’absence de données de zone à son extrémité.

Ce que les assertions ne remplacent pas

Le nouveau test de régression ajoute une seconde identité. Le test complet figé sur la version publiée exige qu’un marqueur du contenu de zone soit reçu avec chacun des deux certificats valides. Il conserve aussi des contrôles de refus : nom erroné, autorité de certification inconnue et requêtes sans certificat client.

Ses deux entrées fondées sur un certificat acceptent cependant toute adresse IPv4 et utilisent NOKEY. Ce n’est pas le montage initial, avec ses adresses distinctes et sa clé TSIG commune. Les assertions éclairent précisément la coexistence des identités ; elles ne valident pas toutes les associations possibles entre source, clé et certificat. Nous avons examiné le code et les tests, sans exécuter NSD ni reproduire l’incident.

Une troisième règle autorise séparément certains transferts authentifiés par TSIG, sur TLS ordinaire ou TCP. Cette permission explicite n’est pas une nouvelle faille. Selon RFC 9103, l’authentification par TSIG ne chiffre pas à elle seule le contenu transféré. La confidentialité d’un ensemble de transferts dépend donc de la politique appliquée à toutes ses relations, pas du seul succès d’une session chiffrée.

Il faut également séparer cette correction du contournement de certificat décrit en juin dans les avis de sécurité de NLnet Labs. CVE-2026-12490 a été corrigée dans 4.14.3. Lui emprunter son numéro ou sa plage de versions pour qualifier le refus à plusieurs identités brouillerait deux problèmes différents. Aucune nouvelle exploitation, estimation du nombre de clients touchés ou matrice exhaustive des versions affectées n’est établie ici.

L’exigence de règles de sécurité précises et vérifiables localement, formulée par Lu Heng, fournit une lecture utile mais limitée de ce cas : rendre explicites les conditions à satisfaire, sans affaiblissement discret pour obtenir un résultat favorable. C’est une application éditoriale de son principe, non un avis de sa part sur NSD.