Summary

  • Le nouveau projet du groupe DNSOP autoriserait, sous conditions, une signature par au moins un algorithme dit UNIVERSAL au lieu d’une signature par chacun des algorithmes annoncés dans les enregistrements DS ou les ancres de confiance.
  • Les algorithmes 8 et 13 recevraient initialement cette étiquette. Le registre actuel de l’IANA impose déjà leur prise en charge pour la validation, mais ne comporte pas encore la nouvelle colonne proposée.
  • Un résolveur qui désactive localement un algorithme UNIVERSAL annoncé devrait traiter la zone comme non signée, même s’il sait utiliser un autre algorithme annoncé. Le coût de cette politique locale serait une perte d’authentification visible.

Un opérateur DNS peut posséder deux clés, deux algorithmes et deux prestataires, puis se voir imposer deux jeux de signatures sur chaque ensemble d’enregistrements. Le résolveur, lui, n’a besoin que d’un chemin valide. Les règles de signature de RFC 4035 et leur précision dans RFC 6840 font payer au producteur une redondance qui garantit la compatibilité avec des validateurs dont il ignore les capacités. Le projet DNSOP cherche à réduire cette facture sans transformer l’absence d’une signature en invitation au déclassement de sécurité.

La difficulté apparaît quand une zone utilise plusieurs fournisseurs DNS. Le modèle à clés indépendantes de RFC 8901 permet à chacun de signer la même zone. Si leurs algorithmes diffèrent, exiger toutes les signatures à chaque endroit crée une coordination lourde. Une migration entre fournisseurs peut se coincer dans cette phase. Une rotation d’ancre de confiance, notamment à la racine, peut imposer une longue période de double signature avant la publication de la nouvelle ancre. Le projet veut séparer l’annonce d’un futur chemin de sa production immédiate.

Une étiquette qui crée une obligation

Le texte demande à l’IANA d’ajouter une colonne Validation support status au registre des algorithmes DNSSEC. Les valeurs proposées sont UNIVERSAL, FORMERLY-UNIVERSAL ou vide. Les algorithmes 8, RSA/SHA-256, et 13, ECDSA P-256/SHA-256, seraient les premiers UNIVERSAL. Aucun ne commencerait dans l’ancienne catégorie. Dans le registre en vigueur, les deux portent déjà la mention d’implémentation obligatoire pour la validation. Le projet veut faire de cette attente une propriété sur laquelle un signataire peut s’appuyer.

La règle envisagée n’est pas « une signature suffit toujours ». Si les DS du parent ou les ancres de confiance contiennent un algorithme UNIVERSAL et aucun FORMERLY-UNIVERSAL, la zone doit signer avec au moins un UNIVERSAL ; les autres signatures deviennent facultatives. Elle peut limiter ses DNSKEY aux algorithmes réellement employés. Sans UNIVERSAL, ou dès qu’un ancien UNIVERSAL apparaît, toutes les signatures restent obligatoires. Le choix dépend de l’ensemble DS ou des ancres, pas d’une préférence commerciale du fournisseur.

Deux prestataires utilisant respectivement les algorithmes 8 et 13 pourraient ainsi répondre chacun avec leur chemin valide. Un exploitant pourrait publier une nouvelle ancre avant de faire entrer la clé et les signatures correspondantes dans la zone. Une expérimentation post-quantique menée par un fournisseur ne forcerait pas immédiatement tous ses partenaires à signer de la même façon. Une migration vers un algorithme encore hors de la catégorie UNIVERSAL peut toujours nécessiter une période de double signature.

La politique privée du résolveur devient publique dans le résultat

Prenons une zone qui annonce 8 et 13. Un fournisseur sert un chemin valide en 8. Un résolveur a désactivé 8 par décision locale, bien qu’il sache traiter 13. Le projet lui demande de classer la zone comme non signée, au lieu d’accuser le fournisseur d’avoir produit une réponse fausse et de renvoyer SERVFAIL. Si le résolveur refuse un algorithme autrefois UNIVERSAL, la même conséquence s’applique.

Cette allocation de responsabilité est le cœur du texte. Le propriétaire de la zone a choisi un algorithme dont le registre dit que tout validateur doit disposer. Le résolveur s’est écarté de cette attente. Il peut répondre à l’utilisateur, mais la réponse perd l’authentification DNSSEC dans sa propre vue. Le journal et la supervision doivent montrer ce statut : le simple succès de la résolution cache trop bien le coût de la décision.

Les auteurs reconnaissent l’objection de sécurité. Un attaquant ne doit pas pouvoir supprimer les signatures que le résolveur comprend et faire passer une réponse sûre pour une réponse innocemment non sécurisée. Leur règle s’appuie donc sur la mémoire des algorithmes UNIVERSAL, même désactivés ensuite. Les résolveurs doivent tenir ce registre local correctement. Un bogue dans cette classification change la frontière entre secure, insecure et bogus.

Le document, daté du 31 octobre 2026, en est à sa première version de groupe de travail. Il ne fournit ni mesure d’adoption ni panne attribuée à cette nouvelle règle. Pour une zone concrète, il faut tester les validateurs réellement utilisés : quel statut rendent-ils lorsque chaque fournisseur sert un seul chemin, puis lorsque l’algorithme UNIVERSAL de ce chemin est désactivé ? Cette matrice d’interopérabilité décidera si l’économie de signatures tient hors du papier.

L’enjeu dépasse une optimisation cryptographique. Un opérateur de zone obtient la liberté de faire évoluer ses fournisseurs sans leur faire produire toutes les signatures partout. Le résolveur qui impose son veto local obtient aussi la responsabilité de nommer la sécurité perdue. Il n’y a pas de bouton « politique personnelle » qui transforme silencieusement une validation absente en preuve.

Projet IETF · RFC 4035 · RFC 6840 · RFC 8901 · Registre IANA