Cloudflare a activé dans son service DNS public 1.1.1.1 la validation des signatures DNSSEC basées sur ML-DSA-44, l’un des algorithmes de signature post-quântique standardisés par l’Institut national des standards et de la technologie (NIST) des États-Unis. Ce changement ne chiffre pas les requêtes DNS ni ne rend Internet résistant aux ordinateurs quantiques, mais il introduit une étape essentielle pour que DNSSEC puisse continuer à vérifier l’authenticité des enregistrements lorsque les algorithmes actuels de clés publiques deviendront obsolètes pour la cryptographie.
Les clés du DNS post-quântique de Cloudflare en 30 secondes
- Le résolveur 1.1.1.1 peut désormais valider les signatures DNSSEC créées avec ML-DSA-44.
- ML-DSA-44 est conçu pour résister aux attaques connues par les ordinateurs quantiques suffisamment puissants à l’avenir.
- Une signature occupe 2 420 octets, contre 64 octets pour l’ECDSA P-256.
- Ce format dépasse les limites habituelles de UDP pour DNS et peut nécessiter l’usage de TCP.
- Une chaîne DNSSEC entièrement post-quântique depuis la racine jusqu’aux domaines n’existe pas encore.
Il est important de préciser que Cloudflare n’utilise pas 1.1.1.1 pour signer directement les réponses DNS qu’il délivre aux utilisateurs, comme pourrait le laisser penser une lecture simplifiée de l’annonce. En réalité, le résolveur récursif a appris à valider les signatures ML-DSA-44 publiées par les zones DNS utilisant ce nouvel algorithme.
C’est une distinction technique majeure.
Dans DNSSEC, les signatures appartiennent aux enregistrements de la zone et sont générées par l’entité responsable. Le résolveur vérifie ensuite la chaîne cryptographique pour s’assurer que la réponse reçue est authentique et non altérée.
Cloudflare a commencé par cette seconde étape : permette à 1.1.1.1 de valider le nouvel algorithme. La société prévoit d’ajouter ultérieurement la prise en charge de la signature ML-DSA-44 pour la DNS autoritative de Cloudflare ainsi que la gestion des enregistrements DS correspondants dans Cloudflare Registrar.
DNSSEC ne chiffre pas le DNS : il assure que la réponse est authentique
Le DNS traditionnel a été conçu sans mécanismes cryptographiques intégrés pour authentifier les réponses.
Cela a permis l’émergence d’attaques connues depuis des décennies, comme le DNS spoofing et le cache poisoning, où un attaquant tente d’introduire une fausse réponse pour faire pointer un domaine légitime vers une adresse IP différente.
DNSSEC remédie à ce problème via des signatures numériques.
Une zone signée publie des enregistrements DNSKEY avec ses clés publiques et des RRSIG avec les signatures associées. Un résolveur qui valide DNSSEC peut suivre une chaîne de confiance allant du domaine interrogé jusqu’aux zones supérieures.
L’objectif est d’assurer une réponse à cette question : les données reçues sont-elles réellement celles publiées par le responsable de cette zone DNS ?
DNSSEC ne répond pas à une autre question : quelqu’un peut-il voir quel domaine l’utilisateur interroge ?
Pour protéger la confidentialité, des mécanismes comme DNS over HTTPS (DoH) et DNS over TLS (DoT) chiffrent la communication entre client et résolveur.
Ces technologies ont des fonctions différentes :
| Technologie | Ce qu’elle apporte |
|---|---|
| DNS traditionnel | Résolution de noms |
| DNSSEC | Authenticité et intégrité |
| DNS over HTTPS | Chiffrement via HTTPS entre client et résolveur |
| DNS over TLS | Chiffrement via TLS entre client et résolveur |
| DNSSEC + ML-DSA-44 | Authenticité protégée contre les attaques quantiques futures |
Ainsi, dire simplement que « DNS utilise UDP et n’a pas de cryptographie » est une vision partielle. DNS peut fonctionner en UDP ou TCP, avec des transports chiffrés comme DoH et DoT. Déjà, DNSSEC offre depuis des années une authentification cryptographique.
Ce qui change, c’est la cryptographie employée par DNSSEC.
Le défi des attaques quantiques sur RSA et ECDSA
Les déploiements actuels de DNSSEC utilisent différents algorithmes, notamment RSA et ECDSA.
Leur sécurité repose sur des problèmes mathématiques difficiles à résoudre avec des ordinateurs classiques assez puissants.
Le problème, c’est qu’un ordinateur quantique à grande échelle capable de lancer efficacement l’algorithme de Shor changerait la donne.
Une telle machine pourrait compromettre des systèmes basés sur la factorisation d’entiers ou les logarithmes discret, ce qui concerne RSA et la cryptographie par courbes elliptiques.
Actuellement, ce type d’ordinateur quantique cryptographiquement pertinent n’existe pas.
La migration vers des algorithmes post-quantiques est anticipée car le changement à l’échelle de l’Internet prend plusieurs années.
Cloudflare rappelle que DNSSEC complexifie cette transition. La chaîne de confiance passe par plusieurs niveaux :
Racine DNS
│
▼
TLD (.com, .fr, .org...)
│
▼
Délégué au domaine
│
▼
Enregistrements DNS signés
│
▼
Résolveur vérificateurPour une chaîne réellement post-quântique, il ne suffit pas qu’un seul domaine utilise ML-DSA-44.
L’ensemble de la chaîne doit supporter cette cryptographie : la zone supérieure doit publier la clé, les registraires doivent l’accepter, les enregistrements doivent la supporter, les résolveurs la vérifier, et enfin la racine DNS doit également disposer d’une chaîne de confiance post-quantique.
Cloudflare n’a pas encore annoncé ce scénario complet.
Le simple fait que 1.1.1.1 supporte ML-DSA-44 constitue déjà une étape importante.
ML-DSA-44 : un problème inattendu, des signatures énormes
La cryptographie post-quântique a un coût — notamment en taille de clé et de signature.
Cloudflare compare trois configurations :
| Algorithme | Clé publique | Signature |
|---|---|---|
| RSA-2048 / SHA-256 | 260 octets | 256 octets |
| ECDSA P-256 | 64 octets | 64 octets |
| ML-DSA-44 | 1 312 octets | 2 420 octets |
Une signature ML-DSA-44 est presque 38 fois plus grande qu’une signature ECDSA P-256.
L’exemple du chercheur Bill Buchanan illustre cela avec un simple enregistrement :
En consultant le domaine test valid.mldsa44.dnstest.dev, le DNSKEY contient une clé publique ML-DSA-44 de 1 312 octets.
Une requête DNSSEC vers le résolveur Cloudflare peut se faire avec :
dig @1.1.1.1 valid.mldsa44.dnstest.dev +dnssecLa réponse inclut une RRSIG avec l’algorithme DNSSEC 18, mentionnant ML-DSA-44.
Ce qui pose un problème pratique évident.
Historiquement, DNS utilisait des paquets UDP jusqu’à 512 octets. EDNS(0) a permis de négocier des réponses plus grandes, mais beaucoup de systèmes utilisent une limite conservatrice de 1 232 octets d’UDP pour éviter des problèmes de fragmentation liés à la MTU minimum d’IPv6.
La RFC 9715 recommande une taille maximale de 1 400 octets pour DNS over UDP.
Mais une signature ML-DSA-44 occupe 2 420 octets.
Elle ne rentre donc pas dans cette limite.
Une requête initiale en UDP peut finir en TCP
Le résultat peut s’observer directement avec dig.
Dans l’exemple de Buchanan, on voit :
;; Truncated, retrying in TCP mode.Le serveur renvoie une réponse tronquée, et le résolveur doit recommencer en TCP.
Ce n’est pas une erreur en soi. DNS supporte TCP depuis longtemps.
Mais cela devient un problème quand cela se produit plus fréquemment.
Avec une signature post-quântique, cela peut augmenter :
- le trafic généré par certaines résolutions ;
- le nombre de requêtes nécessitant TCP ;
- la consommation mémoire en cache ;
- la charge sur les serveurs et résolveurs ;
- le coût de vérification cryptographique.
Les enregistrements DNSKEY peuvent aussi devenir plus volumineux, notamment lors d’une migration où il faudra maintenir simultanément des clés classiques et post-quantiques.
Une zone pourrait ainsi devoir publier :
ECDSA DNSKEY
ML-DSA-44 DNSKEY
ECDSA RRSIG
ML-DSA-44 RRSIGCe qui garantit la compatibilité avec les anciens résolveurs, mais double la taille de certaines réponses DNS.
Les « rollover » de clés, qui durant une période permettent la coexistence de plusieurs clés pour une transition sécurisée, peuvent encore accroître la taille des réponses.
Maintenir ECDSA peut ouvrir à un downgrade
La coexistence entre cryptographie classique et post-quântique pose aussi un autre défi, moins visible :
Supposons qu’une zone publie à la fois ECDSA et ML-DSA-44.
Un résolveur ancien n’utilise que ECDSA, car il ne comprend pas ML-DSA-44. Un résolveur moderne pourra valider ML-DSA-44.
Pendant plusieurs années, ces deux systèmes coexisteront.
Mais si un jour ECDSA pouvait être cassé par un ordinateur quantique, un attaquant pourrait tenter de supprimer la partie post-quante, en falsifiant la chaîne ECDSA.
Le résolveur moderne pourrait alors interpréter cela comme si la zone utilisait encore uniquement l’ancien algorithme.
C’est ce qu’on appelle une attaque de downgrade.
Cloudflare a mis en place une politique spécifique dans 1.1.1.1 pour éviter ce scénario.
Lorsque qu’un ensemble de DNSSEC indique la présence d’un algorithme post-quántique supporté, le résolveur exige qu’au moins une voie de vérification post-quante valide soit disponible. Une signature classique ne suffit plus.
Cette politique est volontairement plus stricte que le comportement traditionnel de DNSSEC.
Le problème peut néanmoins revenir si certains niveaux supérieurs de la chaîne continuent d’utiliser uniquement de la cryptographie classique. La migration doit donc atteindre forcément la racine DNS pour garantir une chaîne entièrement post-quântique.
ML-DSA-44 : un algorithme DNSSEC avec le numéro 18
ML-DSA est issu de la famille d’algorithmes connue auparavant sous le nom de CRYSTALS-Dilithium, qui a été standardisée par le NIST dans le cadre de la transition vers la cryptographie post-quantique.
Pour l’utiliser dans DNSSEC, il a fallu définir comment représenter ses clés et signatures dans les enregistrements DNS.
ML-DSA-44 a été attribué du numéro d’algorithme DNSSEC 18, un préalable pour son déploiement interopérable.
Par ailleurs, la communauté IETF continue à travailler sur ce sujet, avec des brouillons sur l’utilisation de ML-DSA en DNSSEC et des propositions comme ML-DSA-MTL, qui explore des signatures basées sur des structures Merkle dans le cadre du DNS.
Ces documents sont encore en développement et ne doivent pas être considérés comme des standards définitifs.
Pas besoin de changer pour les utilisateurs de 1.1.1.1
Pour ceux qui utilisent déjà 1.1.1.1, le changement est transparent.
Quand une zone publiera les enregistrements nécessaires, Cloudflare pourra valider ML-DSA-44. Les zones DNSSEC classiques continueront de fonctionner comme avant.
La société prévoit aussi de déployer des domaines de test pour observer l’impact de ces réponses plus volumineuses à travers des réseaux, routeurs, pare-feux et résolveurs réels.
Ce travail est aussi crucial que la cryptographie elle-même.
La migration vers des algorithmes post-quantiques pour TLS a déjà montré que augmenter la taille de certains messages peut révéler des limites et des failles dans le logiciel et le matériel réseau. DNS, qui repose encore largement sur UDP, est encore plus sensible au volume.
Cloudflare estime qu’environ 85 % des requêtes vers 1.1.1.1 utilisent UDP. Ce chiffre concerne le transport entre le client et le résolveur, pas forcément celui entre le résolveur et les serveurs autoritaires.
L’entreprise fixe 2029 comme objectif pour une protection post-quantique totale, la cryptographie DNSSEC restant une étape clé dans ce processus.
Cela ne signifie pas qu’il y ait une menace immédiate pour DNS, car contrairement aux données chiffrées qui peuvent être stockées et décryptées plus tard, DNSSEC garantit l’authenticité, pas la confidentialité. Il ne présente donc pas le même risque que le « récolter maintenant, décrypter plus tard ».
Le temps est encore devant nous, mais l’infrastructure doit évoluer rapidement.
Et l’expérimentation avec ML-DSA-44 met en évidence une difficulté pratique majeure : remplacer une signature ECDSA de 64 octets par une autre de 2 420 octets implique de faire traverser ce volume à des millions de serveurs, résolveurs, pare-feux et équipements réseau, sans erreur.
Sources :
- Cloudflare, 1.1.1.1 supporte désormais DNSSEC post-quântique, ses 2 420 octets intégralement, 09/2026.