Le DNS et le routage internet reposent sur des signatures cryptographiques légères, pensées pour circuler en quelques dizaines de bytes dans des paquets UDP. La bascule vers des algorithmes post-quantiques menace ce fragile équilibre. Selon une étude publiée en 2026, faire migrer le dépôt RPKI (Resource Public Key Infrastructure) vers ML-DSA sans optimisation fait gonfler son poids de 853,2 Mo à 3 577,3 Mo, soit une hausse de 319,3 %. Pour le DNSSEC, remplacer une signature Ed25519 de 64 bytes par une signature ML-DSA-44 de 2 420 bytes revient à multiplier la charge par 38. L’IETF planche sur le sujet depuis octobre 2025, Cloudflare et Verisign publient des comparatifs techniques, et SIDN Labs teste des architectures alternatives pour éviter l’engorgement. Cet article détaille les chiffres, les acteurs et les enjeux de cette bascule technique encore largement ignorée du grand public.
Le DNSSEC et le RPKI, deux piliers invisibles menacés par le calcul quantique
Le DNSSEC (Domain Name System Security Extensions) signe les réponses DNS pour empêcher qu’un attaquant ne redirige un utilisateur vers un faux serveur. Le RPKI, de son côté, signe les annonces de routage BGP pour garantir qu’un opérateur télécom possède bien le bloc d’adresses IP qu’il annonce. Les deux systèmes dépendent de signatures numériques compactes, aujourd’hui basées sur RSA, ECDSA ou Ed25519. Ce choix n’est pas anodin : le DNS transite majoritairement en UDP, un protocole sans connexion limité en taille de paquet, et le RPKI doit être validé en continu par des milliers de routeurs à travers le monde.
Le problème, c’est que les algorithmes post-quantiques validés par le NIST (ML-DSA, SLH-DSA, Falcon devenu FN-DSA) produisent des clés et des signatures nettement plus lourdes que leurs équivalents actuels. Un brouillon de l’IETF intitulé Post-Quantum Cryptography Strategy for DNSSEC, publié le 16 octobre 2025 et mis à jour le 17 août 2026, cadre officiellement cette difficulté technique. Un second brouillon, Considerations for Selecting Post-Quantum Algorithms for DNSSEC, daté du 19 juillet 2026, détaille les compromis entre taille de signature et niveau de sécurité pour chaque famille d’algorithmes candidats.
Les chiffres qui inquiètent les ingénieurs réseau
Cloudflare a publié deux analyses comparatives détaillant le poids réel de chaque algorithme post-quantique candidat pour signer des enregistrements DNS. Une clé publique ML-DSA-44 pèse 1 312 bytes contre 32 bytes pour Ed25519, et sa signature atteint 2 420 bytes contre 64 bytes. SLH-DSA, la variante fondée sur les fonctions de hachage plutôt que sur les réseaux euclidiens, va plus loin encore : sa version 128s produit une signature de 7 856 bytes avec une clé publique de seulement 32 bytes, tandis que sa variante rapide 128f grimpe à 17 088 bytes de signature. Falcon-512, rebaptisé FN-DSA dans la nomenclature du NIST, reste le plus compact des trois avec une signature de 666 bytes et une clé publique de 897 bytes.
Rapporté à Ed25519, l’algorithme le plus utilisé actuellement pour signer les zones DNSSEC modernes, ML-DSA-44 multiplie la taille de la signature par environ 38, SLH-DSA-128s par environ 123, et Falcon-512 par environ 10. Cloudflare précise par ailleurs qu’ajouter ML-DSA à une poignée de main TLS alourdit l’échange de 14,7 Ko, contre 39 Ko pour SLH-DSA. Ces chiffres ne concernent pas directement le DNSSEC, mais ils donnent une idée de l’ampleur du problème sur des protocoles conçus à l’origine pour des messages courts.
| Algorithme | Taille clé publique | Taille signature | Facteur vs Ed25519 |
|---|---|---|---|
| Ed25519 (référence actuelle) | 32 bytes | 64 bytes | 1x |
| RSA-2048 (référence actuelle) | 256 bytes | 256 bytes | 4x |
| Falcon-512 / FN-DSA | 897 bytes | 666 bytes | ~10x |
| ML-DSA-44 | 1 312 bytes | 2 420 bytes | ~38x |
| SLH-DSA-128s | 32 bytes | 7 856 bytes | ~123x |
| SLH-DSA-128f | 32 bytes | 17 088 bytes | ~267x |
Verisign, l’opérateur historique des domaines .com et .net, arrive à des ordres de grandeur similaires dans son propre document technique. Son papier PQC DNSSEC – Routine Performance Resilient Fallback situe la fourchette de ML-DSA entre 2 420 et 4 627 bytes selon le niveau de sécurité, celle de SLH-DSA entre 7 856 et 49 856 bytes, et celle de Falcon entre 666 et 1 280 bytes. L’écart entre le plus compact et le plus lourd des candidats post-quantiques atteint donc un facteur proche de 75 sur la seule taille de signature.
Pourquoi la taille des signatures casse le modèle du DNS classique
Le DNS a été conçu pour tenir dans un seul paquet UDP, historiquement limité à 512 bytes, puis étendu à des tailles plus grandes via l’extension EDNS0, mais toujours pensé pour éviter la fragmentation IP. Une étude de 2025-2026 consacrée à l’évaluation des schémas post-quantiques pour le DNSSEC constate que la plupart des algorithmes candidats forcent un basculement vers TCP, avec une latence médiane regroupée autour de 31,6 millisecondes pour la majorité des variantes testées. Ce chiffre peut sembler faible isolément, mais il s’additionne à chaque résolution DNS, sur des infrastructures qui traitent des dizaines de milliards de requêtes par jour à l’échelle mondiale.
La même étude relève que certains algorithmes plus récents comme SNOVA, MAYO-1 ou ML-DSA-44 affichent des temps de signature moyens inférieurs à 25 millisecondes, ce qui les rend viables du point de vue du calcul pur. Le vrai goulot d’étranglement n’est donc pas la puissance de calcul nécessaire pour signer ou vérifier, mais la taille des données à faire transiter et à stocker. Un travail de terrain s’appuyant sur le réseau de sondes RIPE Atlas, avec environ 10 000 points de mesure répartis dans le monde, a été utilisé pour quantifier l’effet réel de ces changements sur des résolveurs DNS en conditions réelles plutôt qu’en laboratoire.
RPKI : quand le dépôt de sécurité du routage internet explose
Le RPKI pose un problème différent mais tout aussi concret. Ce système attribue à chaque bloc d’adresses IP un certificat signé qui prouve qu’un opérateur a le droit de l’annoncer sur le réseau mondial BGP. Aujourd’hui, la taille médiane d’un objet ROA (Route Origin Authorization), la brique de base du RPKI, est de 2 125 bytes selon les données publiées par SIDN Labs, le laboratoire de recherche du registre néerlandais .nl. Une étude publiée à la conférence NDSS 2026 détaille la répartition interne de cet objet : le certificat et la signature occupent à eux seuls entre 1 337 et 1 846 bytes, tandis que le contenu utile réel, c’est-à-dire l’autorisation de routage elle-même, ne représente que 27 des 1 846 bytes, soit 1,4 % du total.
Faire basculer cette infrastructure de RSA-2048 vers ML-DSA-44 change radicalement l’équation. La clé publique passe de 256 à 1 312 bytes et la signature de 256 à 2 420 bytes. Appliqué à l’ensemble des objets RPKI actuellement publiés, ce changement ferait grimper la taille totale de l’infrastructure de 1,2 Go à environ 2,9 Go selon les estimations de cette même étude. Une autre équipe de recherche, dans un papier consacré à une architecture baptisée pqRPKI, mesure un effet encore plus marqué sur un dépôt réel : une bascule naïve vers ML-DSA fait passer le poids du dépôt de 853,2 Mo à 3 577,3 Mo, une hausse de 319,3 %.
Le coût en temps de validation, un problème pour les opérateurs
Au-delà du poids en stockage et en bande passante, la validation RPKI post-quantique coûte aussi du temps de calcul, une ressource critique pour les routeurs qui doivent revalider en continu des centaines de milliers d’objets. Sur un benchmark complet, les chercheurs à l’origine de pqRPKI mesurent un temps de 213,2 secondes avec RSA, contre 404,6 secondes avec une implémentation naïve de ML-DSA, soit quasiment le double. Leur architecture optimisée pqRPKI ramène ce temps à 102,7 secondes, en dessous même du temps de référence RSA.
Sur un corpus de données collecté pendant sept jours consécutifs, la même équipe rapporte une moyenne de 226,9 secondes pour RSA, 431,5 secondes pour ML-DSA appliqué sans optimisation, et 118,3 secondes pour pqRPKI. L’écart entre l’approche naïve et l’approche optimisée dépasse donc un facteur 3,6, ce qui illustre que le choix de l’architecture logicielle pèsera au moins autant que le choix de l’algorithme lui-même dans la réussite de cette transition.
| Scénario RPKI | Taille dépôt / temps | Variation vs base RSA |
|---|---|---|
| Dépôt actuel (RSA-2048) | 853,2 Mo | Référence |
| Dépôt ML-DSA naïf | 3 577,3 Mo | +319,3 % |
| Validation RSA (moyenne 7 jours) | 226,9 s | Référence |
| Validation ML-DSA naïve (moyenne 7 jours) | 431,5 s | +90,2 % |
| Validation pqRPKI optimisée (moyenne 7 jours) | 118,3 s | -47,9 % |
Qui travaille concrètement sur le sujet
Le dossier post-quantique du DNS et du RPKI mobilise un nombre restreint mais influent d’acteurs. Du côté du DNS, Cloudflare a publié plusieurs billets techniques comparant les candidats post-quantiques et leur impact sur le protocole TLS et le DNS, dont une analyse approfondie disponible sur son blog technique. Verisign, qui gère l’infrastructure racine de .com, a publié son propre papier de recherche comparant performance et résilience des schémas de repli. Deux brouillons IETF, portés respectivement par les auteurs des textes Post-Quantum Cryptography Strategy for DNSSEC et Considerations for Selecting Post-Quantum Algorithms for DNSSEC, structurent la discussion normative en cours.
Côté RPKI, SIDN Labs, le laboratoire de recherche du registre du .nl néerlandais, a publié une étude dédiée intitulée Post-Quantum Cryptography for the RPKI. Plusieurs équipes académiques ont également contribué au corpus scientifique disponible en 2025 et 2026, notamment via des travaux publiés sur arXiv et à la conférence NDSS, qui fournissent l’essentiel des chiffres de performance cités plus haut. Ni RIPE NCC, ni APNIC, ni ICANN n’ont à ce stade publié de pilote officiel documenté sur la période août-septembre 2026, ce qui distingue nettement ce chantier de la communication institutionnelle plus visible autour du calendrier post-quantique porté par l’ANSSI et le G7.
Cinq algorithmes candidats, cinq compromis différents
Le choix de l’algorithme n’est pas neutre. ML-DSA (anciennement CRYSTALS-Dilithium), standardisé par le NIST sous la référence FIPS 204, offre un bon compromis entre taille et vitesse, ce qui en fait le candidat par défaut pour de nombreux déploiements TLS. SLH-DSA (ex-SPHINCS+, FIPS 205) repose uniquement sur des fonctions de hachage, ce qui le rend particulièrement résistant sur le plan théorique, mais au prix de signatures nettement plus volumineuses, jusqu’à 267 fois la taille d’Ed25519 pour sa variante rapide. Falcon, rebaptisé FN-DSA par le NIST, reste le plus compact des trois, mais son implémentation repose sur une arithmétique en virgule flottante jugée plus délicate à sécuriser contre les attaques par canal auxiliaire.
Les brouillons IETF mentionnent également XMSS et LMS, deux schémas de signature à état, comme options pour des cas d’usage spécifiques où le nombre de signatures à produire reste borné, un profil qui correspond bien aux clés de signature de zone DNSSEC utilisées pendant une durée limitée. Chaque registre ou opérateur devra donc arbitrer entre la taille des paquets, la vitesse de signature et de vérification, et la marge de sécurité offerte par chaque famille mathématique, sans qu’un consensus univoque ne se soit encore dégagé courant 2026.
Contexte historique : du RSA au post-quantique, une infrastructure déjà remaniée plusieurs fois
Le DNSSEC n’en est pas à sa première migration. Standardisé au début des années 2000, il a d’abord fonctionné avec des clés RSA relativement lourdes avant que l’adoption progressive d’ECDSA, puis d’Ed25519, ne réduise nettement la taille des signatures et améliore les performances de validation. Le RPKI, plus récent, s’est construit directement sur RSA sans jamais connaître de transition vers les courbes elliptiques, en partie parce que sa spécification technique reste plus rigide que celle du DNS. La bascule post-quantique inverse donc la tendance de deux décennies de miniaturisation cryptographique, et c’est précisément ce qui inquiète les ingénieurs qui ont opéré ces infrastructures pendant cette période.
Cette dynamique s’inscrit dans un mouvement plus large de préparation post-quantique porté à l’échelle européenne et internationale, avec un calendrier de transition qui demande aux États membres d’avoir engagé leur migration avant fin 2026, et aux systèmes jugés les plus critiques d’avoir achevé la leur avant fin 2030. Le DNS et le routage BGP figurent parmi les candidats naturels à ce classement, puisqu’une compromission de l’un ou l’autre permettrait de rediriger silencieusement du trafic à l’échelle d’un pays entier.
Impact sur le marché et les opérateurs d’infrastructure
Pour les grands registres de noms de domaine, les hébergeurs DNS et les opérateurs de transit qui exploitent le RPKI, cette transition représente un investissement d’ingénierie loin d’être négligeable. Une croissance de 319 % du poids d’un dépôt RPKI implique de revoir la capacité de stockage, la bande passante de réplication entre serveurs miroirs, et les délais de synchronisation entre les caches locaux des opérateurs et les dépôts centraux. Pour le DNS, le passage forcé vers TCP pour une partie du trafic signifie davantage de connexions à maintenir côté serveur, avec un coût en mémoire et en gestion de sessions que les résolveurs actuels, optimisés pour l’UDP sans état, ne supportent pas nativement à la même échelle.
Les fournisseurs de modules matériels de sécurité ne sont pas en reste. Le 19 août 2026, le programme de validation du NIST a inscrit le module QASM de l’entreprise Crypto4A comme validé au niveau de sécurité 3 de la norme FIPS 140-3, avec une prise en charge native de ML-KEM, ML-DSA, SLH-DSA, LMS, AES, SHA et RSA. Ce type de validation matérielle conditionne directement la capacité des registres et des opérateurs télécoms à déployer légalement ces algorithmes dans des environnements réglementés, notamment pour les administrations et les infrastructures critiques en Europe.
Comparaison compétitive : DNS versus RPKI face au même problème
Le DNS et le RPKI partagent le même défi mathématique mais n’y répondent pas avec les mêmes marges de manœuvre. Le DNS bénéficie d’un mécanisme de repli déjà éprouvé, TCP, même s’il implique un surcoût de latence et de gestion de connexions. Le RPKI, lui, ne dispose pas d’un tel filet de sécurité : ses objets sont publiés et répliqués en masse via rsync ou le protocole RRDP, et toute augmentation de taille se répercute directement sur l’ensemble de la chaîne de distribution, jusqu’aux routeurs de périphérie qui doivent stocker et valider ces objets en mémoire vive, une ressource nettement plus contrainte que l’espace disque d’un serveur DNS.
C’est en partie ce qui explique pourquoi les travaux les plus avancés sur l’optimisation, comme l’architecture pqRPKI qui ramène le temps de validation sous le niveau de référence RSA, se concentrent sur le RPKI plutôt que sur le DNSSEC : la marge d’erreur y est plus étroite, et l’impact d’une mauvaise migration plus immédiat, puisqu’une validation trop lente peut retarder la propagation d’une annonce de routage légitime à l’échelle mondiale.
Ce qui reste non résolu et non public
Malgré l’avancée des travaux techniques, plusieurs zones d’ombre subsistent à la mi-septembre 2026. Aucun des deux brouillons IETF cités plus haut n’a encore été promu au rang de RFC, ce qui signifie qu’aucune norme finale n’encadre à ce jour le choix de l’algorithme pour le DNSSEC. Aucun pilote de production documenté n’a été confirmé auprès des grands registres régionaux comme RIPE NCC ou APNIC, ni auprès de l’ICANN, pour la période août-septembre 2026, même si des travaux de recherche menés par leurs partenaires académiques et par des laboratoires comme SIDN Labs progressent en parallèle. Cette absence de communication officielle contraste avec la visibilité du calendrier post-quantique porté au niveau politique par l’ANSSI et ses homologues du G7.
Prédictions pour la suite de la transition
Plusieurs évolutions paraissent probables dans les prochains mois. D’abord, l’adoption de schémas hybrides combinant une signature classique et une signature post-quantique devrait devenir la norme transitoire pour le DNSSEC, à l’image de ce qui se pratique déjà pour l’échange de clés dans TLS 1.3 avec ML-KEM. Ensuite, Falcon (FN-DSA) a de bonnes chances de s’imposer comme l’algorithme de signature de zone privilégié pour le DNSSEC en raison de sa compacité, malgré les réserves techniques sur son implémentation, tandis que ML-DSA devrait dominer les usages où la simplicité d’implémentation prime sur la taille.
Pour le RPKI, la publication de résultats comme ceux de pqRPKI devrait pousser les équipes d’ingénierie des principaux registres à investir dans des architectures optimisées plutôt que dans une bascule naïve, afin d’éviter la croissance à trois chiffres observée dans les scénarios non optimisés. Il est également probable que l’un des grands registres régionaux, RIPE NCC ou APNIC, annonce un programme pilote structuré d’ici la fin de l’année 2026 ou début 2027, sous la pression du calendrier européen qui fixe fin 2026 comme point de départ formel de la transition. Enfin, la normalisation IETF du DNSSEC post-quantique devrait rester en phase de brouillon au moins jusqu’en 2027, le temps que les tests de performance en conditions réelles, notamment via RIPE Atlas, confirment la viabilité opérationnelle des algorithmes retenus.
Foire aux questions
Le DNSSEC post-quantique va-t-il ralentir la navigation web pour les utilisateurs ?
Pas de façon perceptible dans l’immédiat. Le surcoût mesuré, environ 31,6 millisecondes de latence pour la majorité des variantes testées lorsque le trafic bascule en TCP, reste marginal comparé au temps de chargement total d’une page web, mais il pèsera sur l’infrastructure des résolveurs à grande échelle.
Pourquoi le RPKI est-il plus vulnérable que le DNS à cette transition ?
Parce que ses objets sont répliqués en masse et validés en continu par des routeurs disposant d’une mémoire vive limitée, alors que le DNS peut s’appuyer sur TCP comme mécanisme de repli déjà standardisé depuis des décennies.
Quel algorithme post-quantique est le plus adapté au DNS et au RPKI ?
Aucun consensus définitif n’existe mi-2026. Falcon (FN-DSA) offre la meilleure compacité, ML-DSA le meilleur compromis global, et SLH-DSA la garantie de sécurité théorique la plus solide au prix de signatures nettement plus lourdes.
Existe-t-il déjà des RFC officielles sur le DNSSEC post-quantique ?
Non. Les deux textes de référence disponibles à ce jour restent des brouillons IETF, datés d’octobre 2025 et juillet 2026, sans promotion au statut de RFC finalisée.
Les registres comme RIPE NCC ou l’ICANN ont-ils un calendrier public de migration ?
Aucun pilote de production documenté n’a été confirmé publiquement pour ces organisations sur la période août-septembre 2026, contrairement aux laboratoires de recherche comme SIDN Labs qui publient des études techniques détaillées.
Qu’est-ce que pqRPKI et pourquoi ce projet est-il important ?
pqRPKI est une architecture de recherche optimisée qui ramène le temps de validation d’un dépôt RPKI post-quantique à 102,7 secondes contre 213,2 secondes pour une base RSA classique, alors qu’une bascule naïve vers ML-DSA grimpe à 404,6 secondes sur le même benchmark.
Cette transition est-elle liée au calendrier post-quantique de l’ANSSI et du G7 ?
Elle s’inscrit dans le même mouvement de fond, mais reste un chantier technique distinct, porté par des acteurs d’infrastructure comme l’IETF, Cloudflare, Verisign et SIDN Labs plutôt que par les autorités de certification nationales.
Quand les internautes ressentiront-ils un effet concret de cette migration ?
Probablement pas avant plusieurs années. La priorité actuelle porte sur la normalisation et les tests de performance en laboratoire et sur des réseaux de sondes comme RIPE Atlas, avant tout déploiement à grande échelle sur les infrastructures de production.
