BIND 9 corrige 14 failles qui ouvrent l’empoisonnement du cache DNS et contournent DNSSEC

16 septembre 2026. L’Internet Systems Consortium (ISC) publie BIND 9.20.29 et 9.21.26. 16 septembre 2026. L’annonce officielle révèle que ces deux releases corrigent 14 vulnérabilités dans le démon named. 21 septembre 2026. Le CERT-In indien classe l’ensemble dans une note (CIVN-2026-0467) qui mentionne explicitement le cache poisoning et l’ajout non autorisé de données dans une zone. Pourquoi c’est important : BIND 9 reste le serveur DNS de référence de l’Internet — celui qui résout les noms des FAI, des clouds et des entreprises — et une faille d’empoisonnement de cache, c’est la possibilité de rediriger silencieusement un domaine entier vers une machine contrôlée par l’attaquant.

L’empoisonnement de cache, la faille d’intégrité qui ne fait pas de bruit

Parmi les 14 failles, deux touchent directement la capacité d’un attaquant à empoisonner le cache d’un résolveur récursif. C’est la catégorie la plus grave du lot, et de loin : contrairement à un déni de service, qui coupe le service et se voit immédiatement, l’empoisonnement de cache corrompt la réponse elle-même sans interrompre quoi que ce soit.

CVE-2025-40778 couvre plusieurs faiblesses de spoofing qui permettent d’insérer des enregistrements forgés dans le cache d’un résolveur lorsque DNSSEC n’est pas activé, ou que sa validation est désactivée. Concrètement, un attaquant qui contrôle un serveur de noms autoritaire pour un sous-domaine peut faire accepter au résolveur des enregistrements DNAME ou des enregistrements NS superflus dans la section authority d’une réponse — et ainsi étendre son emprise au domaine parent. La parade d’ISC est radicale : BIND n’accepte plus ces enregistrements dans la section authority que si la réponse arrive par un mécanisme résistant au spoofing — TCP, DNS Cookies, TSIG ou SIG(0).

CVE-2025-40780 s’attaque, elle, au générateur de nombres pseudo-aléatoires (PRNG) que BIND utilisait pour tirer les ports UDP source et les identifiants de transaction. Un générateur prévisible rend ces deux valeurs devinables, ce qui augmente mécaniquement la probabilité qu’une réponse forgée soit acceptée. ISC l’a remplacé par un générateur cryptographiquement sûr, ce qui rend l’empoisonnement par prédiction nettement plus difficile.

Le fil conducteur des deux correctifs est le même : la robustesse de la couche de transport conditionne la confiance dans la réponse. Un résolveur qui n’authentifie pas ses réponses par DNSSEC ne peut plus compter que sur la difficulté de deviner les paramètres du paquet — et c’est précisément cette difficulté que ces deux failles réduisaient.

DNSSEC contourné, la racine de confiance fragilisée

La seconde famille de failles affaiblit DNSSEC, le mécanisme de signature cryptographique censé garantir l’intégrité des réponses DNS. CVE-2026-3104 touche la validation DNSSEC elle-même, tandis que CVE-2025-8677 et CVE-2026-1519 concernent respectivement le traitement des enregistrements DNSKEY et NSEC3.

L’enjeu dépasse le simple bug logiciel. DNSSEC est la brique qui permet de dire « cette réponse vient bien du titulaire légitime du domaine ». Lorsque sa validation peut être contournée, un résolveur se retrouve dans la situation exacte que DNSSEC était censé éviter : il accepte des réponses qu’il ne peut plus distinguer des vraies. Pour un opérateur qui a fait l’effort de signer ses zones, une faille de validation côté résolveur neutralise une partie de ce travail — sans même toucher aux clés de la zone elle-même.

La conséquence opérationnelle est directe : la confiance ne se décrète pas une fois pour toutes, elle se maintient par mise à jour. Un résolveur non patché peut servir de maillon faible à un utilisateur final dont le domaine est pourtant parfaitement signé.

Les dénis de service à distance, du crash à l’épuisement

Le reste du bulletin corrige des conditions de déni de service à distance, dont plusieurs peuvent faire planter le processus named avec une seule requête ou réponse forgée.

CVE-2026-5947 fait planter named sur des réponses signées SIG(0) reçues sous charge. CVE-2026-3593 est un use-after-free dans DNS-over-HTTPS (DoH) : un flot de trames HTTP/2 SETTINGS envoyé pendant que BIND écrit une réponse peut provoquer un crash. D’autres failles peuvent interrompre named pendant le traitement TKEY, la manipulation de réponses NSEC/NSEC3 malformées, les opérations DNS64, les transferts de zone ou les chaînes CNAME/DNAME.

ISC a par ailleurs ajouté des garde-fous contre l’épuisement de ressources : limites sur le travail de validation DNSSEC, sur la taille des listes de serveurs de noms, sur les réponses négatives forgées et sur la croissance du cache. Ces attaques ne font pas planter le serveur, mais consomment CPU et mémoire jusqu’à retarder les résolutions légitimes — un effet insidieux qui se manifeste en dégradation, pas en panne franche.

Ce que ça change pour un opérateur réseau

Le tableau complet se lit comme un inventaire des surfaces d’un résolveur moderne : le cache, la validation, le DoH, le SIG(0), le TSIG, les zones, le DNS64. Un seul bulletin, mais tous les points d’entrée d’un named exposé.

Pour un opérateur, la leçon tient en trois constats. Premièrement, la récursion ouverte est le facteur aggravant universel : un résolveur qui accepte des requêtes récursives de n’importe qui expose son cache à l’empoisonnement. Deuxièmement, l’UDP reste le maillon faible — ISC pousse explicitement vers des canaux résistants au spoofing (TCP, DNS Cookies, TSIG). Troisièmement, l’intégrité se surveille : un redémarrage inattendu de named, une consommation CPU anormale ou des requêtes malformées dans les journaux sont les signes avant-coureurs d’une exploitation en cours.

La mise à jour se limite à deux cibles de release. Les séries 9.20 et 9.21 reçoivent respectivement 9.20.29 et 9.21.26 ; les séries plus anciennes sont hors support et doivent migrer. Le correctif s’applique sans changement de configuration pour la majorité des déploiements, ce qui retire toute excuse pour différer.

Verdict

Si vous exploitez un résolveur récursif BIND exposé sur Internet, montez en 9.20.29 ou 9.21.26 dans la semaine — l’empoisonnement de cache est une attaque d’intégrité qui ne laisse aucune trace visible, et les correctifs renforcent précisément la couche de transport qui la rendait possible. Si vous signez vos zones avec DNSSEC, vérifiez en parallèle la version du résolveur de vos clients et de vos relais : une zone signée ne protège personne si le résolveur en face contourne la validation. Si vous n’exposez que des serveurs autoritaires, le risque est moindre, mais les failles SIG(0) et de transfert de zone vous concernent toujours — planifiez la mise à jour dans le cycle normal. La leçon générale est simple : la confiance dans le DNS se reconstruit à chaque release, et un résolveur non patché est un résolveur qui ment sans le savoir.

Références

• ISC — New BIND 9 releases: 9.20.29, 9.21.26 (16 septembre 2026)
• SecurityWeek — ISC Patches 14 Vulnerabilities in BIND 9 Security Update
• Cyber Security News — BIND DNS Servers Hit by 14 Security Flaws Enabling Cache Poisoning and Remote Crashes (17 septembre 2026)
• ISC — BIND 9 Security Vulnerability Matrix