Résumé

  • La révision 00 définit une option EDNS(0) par laquelle un client annonce jusqu’à huit SigTag associés à des Merkle Tree Ladders signées.
  • Une correspondance permet au serveur d’envoyer une signature condensée, mais ne prouve ni la présence du cache, ni son bon signataire, ni le résultat DNSSEC.
  • La réduction n’est sûre à exploiter qu’avec une reprise par signature complète, des traces de validation distinctes et une politique explicite sur la fuite d’historique.

Une économie fondée sur un état absent du paquet

Dans ML-DSA-MTL, la signature complète réunit un chemin d’authentification Merkle condensé et une échelle signée contenant la signature ML-DSA sous-jacente. L’échelle peut couvrir plusieurs RRset. Elle amortit donc le calcul, mais reste volumineuse ; le projet de base indique qu’une réponse complète dépasse UDP.

SigTag calcule un identifiant de 32 octets, SHAKE128(SIGNED_LADDER, 256), sur la sérialisation complète de cette échelle. Si le client affirme connaître cet identifiant et si le serveur conserve l’échelle correspondante, celui-ci peut retourner un RRSIG condensé de type 0x02. Sans correspondance, ou si le serveur ne possède plus l’échelle, la signature complète reste obligatoire.

Le gain dépend ainsi d’un objet qui ne voyage pas. Le résolveur doit retrouver les bons octets, vérifier la signature de l’échelle avec la DNSKEY pertinente, contrôler le chemin Merkle, puis achever la validation DNSSEC ordinaire. Le tag ne valide rien à lui seul ; il autorise seulement une forme de réponse.

Le nom du signataire appartient à la clé du cache

Le projet de base avertit qu’un autre signataire peut réutiliser le même SID. Une échelle en cache doit donc être liée au nom du signataire. Une table indexée uniquement par SID ou SigTag pourrait produire une correspondance exacte dans le mauvais contexte d’autorité.

La déclaration du client demeure aussi temporelle. Entre la construction de la requête et la réponse, l’entrée peut être évincée ou devenir incohérente lors d’un rollover. Le serveur détient son propre état et le chemin condensé reçu doit correspondre à l’échelle effectivement chargée. « Cache hit » ne décrit pas ces trois contrôles.

Un client sans tag connu peut envoyer l’option vide. Le serveur compatible la renvoie vide et peut dédupliquer plusieurs RRSIG d’une même réponse : une première signature complète, puis des signatures condensées. Cet écho indique une capacité, pas une validation réussie.

La reprise détermine la disponibilité

Si la réponse ne se valide pas, la révision 00 prévoit de recommencer avec une option vide, de supprimer SigTag pour obtenir les signatures complètes, ou d’interroger un autre serveur. Les signatures condensées incompatibles et les charges manquantes sont citées explicitement.

Ces branches doivent être testées avant l’optimisation. Sinon, une entrée de cache obsolète transforme une économie de bande passante en panne. Le choix UDP/TCP reste local : commencer directement en TCP peut réduire certaines reprises, mais ne prouve ni la livraison ni la validité. Il faut distinguer taille, troncature, transport, nouvelle requête, validation et résultat remis à l’application.

Un identifiant de cache peut devenir un identifiant de client

Annoncer un tag connu révèle qu’un client a déjà reçu une échelle. Le projet mentionne la déduction de requêtes antérieures et le suivi par une autorité qui distribuerait des échelles distinctes. Envoyer toujours l’option vide conserve la déduplication interne à une réponse sans révéler les tags connus ; vider ce cache lors d’un changement d’adresse ou d’interface réduit aussi la persistance.

Ce sont des arbitrages, pas des garanties. La politique doit rester chez l’opérateur qui supporte le coût et le risque. Une autorité ne reçoit aucun mandat général de transformer ces tags en profil, et un fournisseur de résolveur ne devrait pas cacher ce choix dans un réglage opaque.

Un brouillon n’est pas un déploiement

La révision 00 date du 28 septembre 2026. Le code EDNS et la nouvelle valeur MTL-Type sont encore TBD. LDNS, NSD et Unbound figurent comme implémentations de test, mais le texte précise que ces déclarations sont fournies par les contributeurs, non vérifiées et sans valeur d’approbation IETF.

Un numéro IANA rend un champ interprétable ; il ne démontre pas l’interopérabilité. Du code disponible ne donne pas les taux d’échec. L’autorité opérationnelle vient de versions identifiées, de traces reproductibles et de reçus montrant chaque étape de validation et de reprise.

Sources