DNSSEC : plusieurs routeurs Asus en panne après l'activation de KSK-2024

La nouvelle clé KSK-2024, identifiée par le tag 38696, signe l’ensemble DNSKEY de la zone racine depuis le 11 octobre 2026. L’IANA confirme que le basculement a eu lieu comme prévu. KSK-2017, tag 20326, ne signe plus cet ensemble, même si elle reste pour le moment une ancre de confiance valide.

Il s’agit seulement du deuxième renouvellement de cette clé depuis le déploiement de DNSSEC à la racine en 2010. Le premier avait eu lieu en 2018. L’algorithme ne change pas : les deux clés utilisent RSA avec SHA-256.

Les communications officielles consultées le 13 octobre ne font état d’aucun incident généralisé. L’IANA estimait que la plupart des internautes ne subiraient aucune interruption. KSK-2024 était en effet publiée dans la zone racine depuis le 11 janvier 2025, afin que les résolveurs compatibles avec la RFC 5011 puissent l’adopter automatiquement.

ASUSWRT au centre des signalements

Les éléments les plus précis concernent plusieurs routeurs équipés d’ASUSWRT. Sur un RT-BE88U, un utilisateur indique que le système contient uniquement la clé 20326 dans le composant qui génère la configuration de dnsmasq. Le problème toucherait les firmwares 3.0.0.6.102_39396 et 3.0.0.6.102_39450, ce dernier datant du 7 octobre.

Le rapport publié sur le forum Asus ZenTalk montre des réponses considérées comme BOGUS lorsque la validation DNSSEC est activée. Son auteur a reproduit la configuration dans une instance indépendante de dnsmasq : l’ajout de l’ancre officielle 38696 fait alors passer la validation à l’état SECURE. Ce test constitue le signal technique le plus solide, mais il reste réalisé par un utilisateur et non par Asus.

Un deuxième cas concerne le ROG Rapture GT-AXE16000 sous le firmware 3.0.0.6.102_37547. Les journaux communiqués sur le forum officiel ROG montrent que dnsmasq charge l’ancre 20326, sans trace de 38696. Les requêtes directes vers Google DNS aboutissent, tandis que celles qui passent par le routeur renvoient SERVFAIL. Désactiver DNS-over-TLS ne corrige pas la panne, contrairement à la désactivation de la validation DNSSEC locale.

Le scénario se répète sur un ZenWiFi Pro ET12 en Irlande, avec le firmware 3.0.0.6.102_37457. Son propriétaire situe le début de la panne au matin du 12 octobre. L’accès par adresse IP et les requêtes directes vers Cloudflare fonctionnent toujours, mais la résolution via le routeur échoue. Ce témoignage ne contient toutefois ni journal de l’ancre chargée ni code d’erreur DNS précis. Il renforce donc le faisceau d’indices sans démontrer à lui seul que la clé manquante est la cause. Un modérateur Asus indique avoir transmis le dossier à l’équipe concernée.

Suivi du 15 octobre 2026 : un modérateur officiel d’Asus confirme que le fabricant a connaissance du problème et a commencé à mettre à jour la clé DNSSEC dans ses firmwares. Asus prévoit de publier les premiers firmwares concernés à partir de cette semaine. Cette annonce ne signifie pas qu’un correctif est déjà disponible pour chaque modèle touché. Lors d’une nouvelle vérification le 16 octobre, la page de support du RT-BE88U proposait encore comme version la plus récente le firmware 3.0.0.6.102_39450 du 7 octobre, signalé parmi les versions affectées.

Des témoignages concordants concernant d’autres modèles apparaissent aussi sur Reddit, SNBForums et le forum de NextDNS, mais cet écho communautaire ne permet pas encore de mesurer l’étendue du problème ni de conclure que tous les routeurs Asus sont concernés.

Que vérifier maintenant ?

Si l’ancre 38696 manque, le résolveur ne peut plus valider la chaîne DNSSEC depuis la zone racine. Il renvoie alors SERVFAIL, donnant l’impression que l’accès à Internet est coupé alors que la connexion IP fonctionne encore.

Cloudflare propose toujours un test sur dnstest.dev fondé sur le mécanisme de sentinelle de la RFC 8509. Il permet de vérifier si le résolveur employé par le navigateur fait confiance à la clé 38696. Un VPN, le DNS sécurisé du navigateur ou un relais peut toutefois modifier le résolveur réellement testé.

Les utilisateurs concernés doivent d’abord rechercher une mise à jour de firmware pour leur modèle. Dans l’attente d’un correctif, Asus recommande de se connecter à l’interface d’administration, puis d’ouvrir WAN > Internet Connection > Internet DNS Setting, de régler Enable DNSSEC support sur No et d’appliquer la modification. Cette désactivation contourne la panne en supprimant la validation effectuée par le routeur. Un résolveur public utilisé en amont peut continuer à valider DNSSEC, mais le routeur ne vérifie alors plus lui-même les réponses reçues. Ce réglage doit donc rester provisoire et être réévalué après l’installation d’un firmware corrigé.

Ajouter manuellement une ancre de confiance n’est pas une opération anodine. Elle doit provenir des données officielles de l’IANA et être installée selon une procédure prise en charge par le fournisseur, plutôt que copiée sans vérification depuis un forum.

Le renouvellement n’est pas encore totalement terminé. L’IANA prévoit de révoquer KSK-2017 le 11 janvier 2027, puis de la retirer de la zone racine le 22 mars 2027.