Les domaines .nl qui utilisent DNSSEC voient désormais cinquante-sept pour cent de leur zone signée avec l’algorithme ECDSA 13. Selon sidn.nl, cette progression s’inscrit dans une évolution plus large de la cryptographie appliquée à ce protocole essentiel qui garantit l’authenticité des réponses DNS.

Six ans après l’introduction du support pour les algorithmes basés sur ECDSA (numéros 13 et 14), le déploiement de l’algorithme 13 est bien établi. Les responsables de la zone .nl ont d’ailleurs l’intention de commencer à l’utiliser pour signer le domaine de premier niveau lui-même plus tard cette année, en remplacement de l’algorithme 8.

Le protocole DNSSEC fonctionne entièrement sur des signatures numériques. Ces signatures (enregistrements RRSIG) jointes aux réponses DNS (RRsets) confirment l’authenticité de ces réponses. Une signature numérique (enregistrement DS) attachée à la clé publique du signataire (enregistrement DNSKEY) confirme l’authenticité des signatures du signataire. C’est ainsi qu’une « chaîne de confiance » est établie dans l’infrastructure DNS existante, ancrée dans la zone racine.

Cette chaîne repose sur des fonctions de hachage et des cryptographies à clé publique. Pour signer une zone, il faut choisir la combinaison de fonction de hachage et d’algorithme de clé publique. Il existe environ quinze combinaisons définies pour DNSSEC.

Les développements récents en cryptographie sont reflétés dans l’RFC 8624, publiée en juin 2019. Cet RFC recommande l’algorithme 13 (courbe P-256 avec SHA-256). L’algorithme 8 (RSA/SHA-256), qui était la norme pendant longtemps, est en cours de remplacement par les algorithmes basés sur ECDSA. L’algorithme 14 (ECDSA Curve P-384 avec SHA-384) existe, mais sidn.nl indique qu’il n’est pas nécessaire pour l’instant.

Ce qui retient l’attention, c’est la perspective que l’algorithme 13 sera remplacé, non pas par le 14, mais par un algorithme basé sur EdDSA, comme le numéro 15 (Ed25519). Même si les algorithmes EdDSA peuvent déjà être utilisés dans la zone .nl, leur utilisation à grande échelle dépend de la mise en place du support logiciel. Il est donc conseillé aux implémenteurs actuels d’utiliser l’algorithme 13, et de préparer le passage des systèmes plus anciens vers cette nouvelle norme.

Les défis de la cryptographie face au quantique

Au-delà de cette évolution progressive, le contexte général de la sécurité des noms de domaine est marqué par l’inquiétude croissante concernant l’informatique quantique. Selon un article de l’APNIC, l’avènement d’un ordinateur quantique suffisamment puissant, appelé « ordinateur quantique cryptographiquement pertinent » (CRQC), menace les pratiques cryptographiques actuelles, y compris celles utilisant RSA et ECC.

Le risque principal réside dans la possibilité qu’un CRQC calcule la clé privée à partir d’informations publiques exposées, comme la clé publique et un texte chiffré, dans un délai qui permettrait une exploitation ultérieure. Le danger actuel est celui de l’attaquant qui capture des données aujourd’hui, en prévision de pouvoir les traiter plus tard avec un CRQC. C’est ce qu’on nomme « Harvest Now, Decrypt Later » (HNDL).

Face à ce risque, une première réaction consiste à renouveler les clés plus souvent. Cependant, si le développement des ordinateurs quantiques s’accélère, des durées de vie de clés plus courtes ne suffiront pas. Il faudra alors migrer vers des algorithmes de cryptographie post-quantique (PQC) dans la configuration DNSSEC.

L’APNIC présente d’ailleurs une comparaison de taille entre l’algorithme 13 (ECDSA P-256 avec SHA-256) et l’algorithme 18 (ML-DSA-44). Le passage au PQC entraîne des clés et des signatures significativement plus volumineuses. Par exemple, la clé publique de ML-DSA-44 atteint 1 312 octets, contre 32 octets pour ECDSA P-256.

Sources

• EdDSA-based algorithms for DNSSEC under development | Cybersecurity | SIDN, sidn.nl
• Herding the DNS Camel, ietf.org
• The DOs and don’ts of post-quantum DNSSEC, APNIC Blog, 9 novembre 2026
• The post-quantum future of web privacy, Cloudflare, 6 novembre 2026