Résumé

  • La révision 00 de Support for nothing-new notifications in the DNS propose d’associer la troncature à un signal NN et à un RR LARGE muni d’un identifiant sur seize bits, afin d’éviter de retransmettre un RRset volumineux apparemment inchangé.
  • Il s’agit d’un Internet-Draft individuel, déclaré incomplet et non implémentable. Le Datatracker ne lui attribue ni flux ni statut RFC visé, tandis que l’en-tête indique Standards Track.
  • L’unicité de l’identifiant n’est exigée que pendant la durée de validité des signatures des données représentées. L’égalité n’a donc de sens qu’avec le nom, le type, la classe, la méthode de génération, la fenêtre et la filiation exacte du cache.
  • Une exploitation défendable sépare le signal, son authentification, la comparaison, le hash du RRset, la validité DNSSEC, l’état de chaque autorité, la décision de transport et le résultat observé.

Une étiquette courte n’est pas l’identité de l’objet

Le projet part d’un problème réel : certains RRsets DNS sont assez grands pour déclencher une réponse tronquée puis une nouvelle requête sur un transport fiable. Des clés et signatures post-quantiques pourraient accentuer cette pression, sans que le texte fournisse pour autant une prévision de déploiement ou une mesure de gain.

Le mécanisme proposé cherche à ne pas retransmettre un grand objet que le résolveur possède déjà. Avec TC, le serveur pourrait envoyer NN pour dire que l’enregistrement demandé n’a pas changé récemment. Un RR LARGE donnerait un identifiant compact de la version courante. Si le cache porte le même identifiant, le résolveur pourrait conserver ses données.

Mais un identifiant de seize bits n’est pas l’objet. C’est une assertion de correspondance dans un contrat précis. Le draft exige son unicité pendant la durée de vie des signatures associées, pas pour toujours, pas pour toutes les zones, pas pour tous les serveurs et pas pour toutes les méthodes de génération.

Un journal qui ne conserve que 42 = 42 perd les conditions qui rendent cette égalité utile. Il faut savoir quel nom, quel type et quelle classe étaient visés, quel serveur parlait, comment il avait fabriqué la valeur, quel RRset exact le cache lui associait et si la comparaison restait dans la fenêtre où une réutilisation était interdite.

Chaque méthode de génération crée son propre contrat

Le texte autorise plusieurs familles : hash cryptographique, compteur, horodatage soigneusement construit ou valeur dérivée des données. Elles ne possèdent pas les mêmes modes d’échec.

Un hash tronqué a une probabilité de collision qu’un opérateur doit placer dans son modèle. Un compteur suppose un état durable et, si plusieurs serveurs le produisent, une coordination. Un horodatage impose une granularité, une règle de redémarrage et une définition du même instant. Une valeur dérivée du contenu exige une sérialisation canonique. Le champ réseau ne révèle pas ce choix à lui seul.

La restauration d’une ancienne configuration illustre le risque. Un serveur peut reprendre un compteur précédent alors que le cache a conservé la même petite valeur pour un autre grand objet. Un deuxième serveur peut calculer autrement. Un passage de signature peut ouvrir une nouvelle fenêtre de réutilisation alors qu’un cache mal indexé joint encore les époques.

La Minimal Initial Specification doit donc nommer le profil de génération, l’autorité émettrice, l’époque, le hash complet du RRset, l’intervalle RRSIG et la clé de cache. Cette enveloppe ne rend pas seize bits magiques. Elle rend la décision reconstructible.

Le numéro SOA répond à une autre question

La révision 00 déconseille d’utiliser automatiquement le serial SOA. Une zone dynamique peut changer fréquemment alors que son DNSKEY volumineux reste identique. La version de zone avancerait sans que l’objet concerné change. À l’inverse, une mauvaise projection pourrait laisser un indicateur de zone stable alors qu’un RRset particulier devrait être renouvelé.

Cette dissociation est un principe de gouvernance autant qu’un détail DNS. Un numéro partagé simplifie l’interface, mais il transfère au producteur du numéro le pouvoir de définir quels changements comptent. Si le contrôle porte sur le RRset, son reçu doit rester attaché au RRset.

La même prudence vaut pour les vues. Deux réponses différentes peuvent être correctes selon le client, le réseau ou la politique. Un identifiant n’a de sens qu’à l’intérieur de la vue qui l’a produit. Rassembler les valeurs sans conserver cette dimension fabrique une fausse collision ou une fausse continuité.

« Rien de nouveau » a un locuteur

Le DNS faisant autorité est distribué. Une primaire, des secondaires et des instances anycast peuvent présenter des générations différentes pendant un transfert, un chargement ou une panne partielle. Une réponse NN décrit l’état de comparaison du répondant atteint par cette requête. Elle n’est pas un vote de l’ensemble.

La bonne question opérationnelle n’est pas seulement « l’identifiant correspond-il ? », mais « quel ensemble devait être cohérent avant notre décision ? ». Pour une requête ordinaire, une observation peut suffire selon la politique assumée. Pour une rotation de clé, un changement de délégation ou une récupération, l’organisation peut exiger plusieurs autorités nommées ou une acquisition complète.

Le dénominateur doit être conservé. « Toutes les autorités » signifie une liste et un instant. Une adresse anycast n’est pas un inventaire de ses instances. Une série de réponses d’un même point de présence n’est pas une preuve de convergence mondiale.

Cette limite ne condamne pas l’optimisation. Elle empêche simplement le tableau de bord de transformer la parole d’un serveur en vérité universelle.

La signature valide n’est pas l’intention présente

DNSSEC authentifie des données déterminées et les lie à un intervalle de validité. Une RRSIG encore valable permet de vérifier que le RRset signé appartient à la chaîne correspondante. Elle ne dit pas que l’opérateur n’a pas depuis voulu le remplacer, que toutes les autorités ont reçu le remplacement ou que le cache a choisi la bonne filiation.

Le signal réduit complique encore la frontière. Si la signature du RR LARGE tient dans la réponse, le projet exige sa présence. Si elle ne tient pas, il recommande l’envoi du LARGE sans signature. Une donnée non authentifiée peut alors influencer la décision de ne pas récupérer la donnée signée.

La section sécurité reconnaît explicitement ce point. Son argument est marginal : un intermédiaire capable d’usurper NN peut déjà supprimer des paquets et pousser le résolveur vers son cache périmé après expiration du délai. Le nouveau chemin pourrait seulement accélérer l’effet. Cela compare des capacités d’attaque. Cela n’authentifie pas le signal et ne démontre pas que toutes les politiques de données périmées sont équivalentes.

Le reçu doit donc distinguer NN authentifié, LARGE authentifié, LARGE non authentifié, RRSIG du RRset en cache valide, et politique locale autorisant ou refusant la réutilisation. Un seul booléen secure écrase trop d’autorités.

TC ne signifie pas que TCP est inutile

Le bit TC annonce une troncature. Il ne prouve ni l’échec de TCP, ni son indisponibilité, ni l’absence d’information nouvelle dans la réponse complète. RFC 7766 place le support de TCP dans le contrat des implémentations DNS complètes. Ne pas ouvrir la voie fiable est un choix d’optimisation, pas une constatation sur le monde.

Le résolveur doit conserver les entrées de ce choix : capacité NN négociée, état du cache, identifiant reçu, validation, risque associé au type de RR, politique de données périmées et possibilité de repli. La sortie n’est pas « frais » ; elle est « récupération supprimée selon la politique P sur la base des reçus R ».

Cette formulation permet les tests. On peut faire réutiliser un identifiant avec un RRset différent, laisser TCP fonctionner, faire expirer la RRSIG, modifier une seule secondaire ou perdre la réponse NN. Le système doit produire l’état prévu, y compris inconnu ou désaccord, sans forcer chaque cas dans vert ou rouge.

Servir une donnée périmée est un contrat explicite

RFC 8767 décrit un usage borné de données périmées lorsque le rafraîchissement échoue. Cette possibilité soutient la comparaison de menace du draft, mais elle ne permet pas d’appeler toute réutilisation « actuelle ».

Un délai dépassé et un NN reçu conduisent peut-être aux mêmes octets en cache, mais pas au même fait. Le premier documente un rafraîchissement qui n’a pas abouti. Le second documente l’affirmation d’un serveur que le rafraîchissement n’apporterait rien. L’incident, l’escalade et la confiance ne sont pas identiques.

Les métriques utiles conservent cache valide par TTL, cache valide par signature, maintien après NN authentifié, maintien après NN non authentifié, service périmé après échec et récupération complète. Un taux global de cache hit ne permet pas de comprendre pourquoi une ancienne génération a survécu.

Enfin, le résultat applicatif reste extérieur. Une application peut fonctionner malgré une génération ancienne, ou échouer après une décision DNS correcte. Le succès visible ne blanchit pas la preuve de fraîcheur ; la preuve DNS ne garantit pas le service.

Le statut du texte borne l’analyse

Au gel des sources, le Datatracker classait la révision 00 comme Internet-Draft individuel actif. Il précise qu’un tel texte peut être soumis par n’importe qui et ne bénéficie d’aucune approbation IETF. Aucun flux, AD responsable, téléchat ou statut RFC visé n’était enregistré. L’en-tête disait pourtant Standards Track.

Le document annonce lui-même qu’il n’est ni complet ni implémentable. Les considérations IANA sont TBD. La partie DNSSEC laisse des idées non écrites. Le format, l’emplacement et un éventuel signal du résolveur vers le parent restent discutés.

Il serait donc faux de parler d’allocation finale, de prise en charge par des produits, de déploiement PQC ou d’économie mesurée. L’objet éditorial est la frontière de preuve qu’une telle optimisation devrait préserver si elle mûrit.

Le meilleur produit est un graphe de reçus

Le graphe commence par la requête et la génération de cache. Il ajoute l’autorité, la vue, TC, NN, le RR LARGE, l’authentification et le profil d’identifiant. Le nœud de comparaison lie les petites valeurs aux hashes complets et à leurs époques. Le nœud de politique explique pourquoi la récupération a été supprimée ou imposée.

Le transport, l’admission en cache, la réponse client et l’observation applicative restent des nœuds ultérieurs. Aucun ne réécrit le précédent. Une conclusion défendable peut alors dire : « l’autorité X a annoncé NN ; l’identifiant Y correspondait au RRset Z encore signé jusqu’à T ; la politique P a évité une récupération ». Elle ne dit pas plus que ses preuves.

La décision de leadership devient explicite : dans quelles phases un petit indice peut-il autoriser la non-acquisition d’une preuve plus coûteuse ? Le seuil peut privilégier l’efficacité au quotidien et devenir plus strict pendant une transition irréversible.

Le projet propose d’économiser un grand transfert. La gouvernance doit empêcher que cette économie supprime aussi l’identité du grand objet. L’égalité des étiquettes est utile. L’état actuel exige encore sa propre preuve.

Sources