Cloudflare valide le DNSSEC post-quantique ML-DSA-44 sur son résolveur 1.1.1.1
Le résolveur public 1.1.1.1 valide désormais les signatures DNSSEC produites avec ML-DSA-44, l’algorithme post-quantique normalisé par le NIST, dont chaque signature pèse 2 420 octets. C’est le premier test à l’échelle d’Internet du transport de réponses DNS massives et de la parade contre le repli vers des algorithmes fragilisés.
10 septembre 2026. Cloudflare annonce que 1.1.1.1, son résolveur DNS public, valide désormais les signatures DNSSEC produites avec ML-DSA-44, l’algorithme de signature post-quantique normalisé par le NIST. La difficulté tient en un chiffre : 2 420 octets par signature, soit près de 38 fois la taille d’une signature ECDSA P-256 de 64 octets. Ce n’est pas un simple ajout d’algorithme — c’est le premier exercice à l’échelle d’Internet de deux problèmes que la communauté DNS va devoir résoudre ensemble : transporter des réponses massives, et empêcher le repli vers les algorithmes fragilisés.
Pourquoi le DNSSEC a besoin du post-quantique maintenant
Cloudflare vise une sécurité post-quantique complète d’ici 2029. L’essentiel de l’effort a porté sur TLS jusqu’ici, mais le DNSSEC repose, lui aussi, sur de la cryptographie à clé publique — RSA et ECDSA, tous deux vulnérables à un ordinateur quantique suffisamment puissant.
Le DNSSEC n’est pas exposé aux attaques « collecte maintenant, déchiffre plus tard » : il fournit de l’authenticité, pas de la confidentialité. L’urgence est ailleurs. Migrer le DNSSEC exige une coordination entre serveurs faisant autorité, registres, registrars et résolveurs validateurs — et la migration doit finir par atteindre le sommet de la hiérarchie DNS, là où une clé compromise a le plus d’impact. Un attaquant qui récupérerait la clé de signature de la zone racine grâce à un ordinateur quantique pourrait forger un chemin de validation vers n’importe quelle zone en dessous : « casser une fois, tout forger ». ML-DSA-44 donne à cette migration un point de départ normalisé.
Le problème des 2 420 octets
Les algorithmes DNSSEC d’aujourd’hui produisent de petites signatures. ML-DSA-44 en produit une de 2 420 octets, et sa clé publique pèse 1 312 octets. Or le DNS est extrêmement sensible à la taille des messages.
Historiquement, le DNS limitait les réponses UDP à 512 octets. EDNS(0) a ensuite permis à un résolveur d’annoncer la plus grande réponse UDP qu’il accepte ; beaucoup d’implémentations utilisent une limite conservatrice de 1 232 octets, choisie pour tenir dans la MTU minimale d’IPv6 de 1 280 octets. Plus récemment, RFC 9715 a recommandé un maximum de 1 400 octets pour le DNS sur UDP. Une signature ML-DSA-44 dépasse ce budget à elle seule, avant même de compter le RRset signé, les noms de domaine, les en-têtes et les autres enregistrements DNSSEC.
Envoyer une telle réponse en UDP fragmenté n’est pas fiable. La parade est connue : le serveur faisant autorité renvoie une réponse tronquée, ce qui pousse le résolveur à réessayer sur TCP. C’est le comportement que Cloudflare mesure désormais en production : environ 85 % des requêtes vers 1.1.1.1 arrivent en UDP, et 60 % sur l’ensemble des services portés par la plateforme Big Pineapple — les 40 % restants passant par TCP, DoT ou DoH.
Bloquer le repli, pas seulement signer
Le deuxième problème est plus subtil. Une zone ne peut pas publier uniquement du ML-DSA-44, sous peine de casser la validation pour les résolveurs qui ne le supportent pas encore. Le chemin de migration pratique consiste donc à publier ensemble clés et signatures conventionnelles et post-quantiques.
Mais la RFC 6840 précise que « les validateurs DEVRAIENT accepter n’importe quel chemin de validation valide ». Une fois ECDSA fragilisé, ce comportement crée une voie de repli : un attaquant pourrait forger une réponse signée uniquement en ECDSA qu’un résolveur accepterait alors qu’il supporte ML-DSA-44.
1.1.1.1 referme cette voie grâce aux enregistrements DS publiés par la zone parente. Si le RRset DS authentifié contient un enregistrement pour un algorithme post-quantique supporté, le résolveur applique une politique de validation locale plus stricte : il exige au moins un chemin de validation post-quantique valide, et un chemin conventionnel ne suffit plus. La RFC 4035 autorise une telle politique locale. Les signatures conventionnelles restent disponibles pour les anciens résolveurs, sans permettre aux résolveurs modernes d’y retomber.
Ce qui manque encore
ML-DSA-44 dispose désormais des prérequis initiaux : NIST l’a normalisé, les bibliothèques cryptographiques courantes l’implémentent, un Internet-Draft décrit son usage dans le DNSSEC, et l’IANA lui a attribué le numéro d’algorithme 18. Mais ajouter la validation côté résolveur n’est qu’une première étape.
Il faut encore que les serveurs faisant autorité signent leurs zones en ML-DSA-44, que les registrars acceptent les DS correspondants et que les registres les publient dans les zones parentes — jusqu’à la racine, dont la clé post-quantique devra devenir une ancre de confiance. Tout niveau sans protection post-quantique reste un point de repli.
Cloudflare indique que sa prochaine étape est l’ajout de la signature ML-DSA-44 à son DNS faisant autorité et du support des enregistrements DS à son Registrar, gratuitement. L’ensemble permettra de tester le chemin complet, de la génération de signature à la validation via 1.1.1.1. Un domaine de test existe déjà : valid.mldsa44.dnstest.dev, interrogeable via dig @1.1.1.1.
Verdict
Si vous utilisez 1.1.1.1, vous n’avez rien à faire : la validation ML-DSA-44 s’active automatiquement quand une zone publie les enregistrements nécessaires, et les zones existantes continuent de valider comme avant.
Si vous opérez un résolveur ou une zone DNSSEC, c’est le moment de commencer les tests : le transport de signatures de 2 420 octets va faire apparaître des ruptures chez les équipements intermédiaires, exactement comme le TLS post-quantique l’a fait en son temps. Si vous gérez une chaîne de signature (autoritatif, registrar, registre), mesurez dès maintenant votre capacité à publier des DS ML-DSA-44 et à servir des réponses tronquées vers TCP — c’est là que se décidera le rythme réel de la migration.