EDE 33 peut signaler une NTA sans prouver qu’elle a changé la réponse

Résumé

• DNSOP consulte jusqu’au 16 septembre sur l’adoption de draft-farrokhi-dnsop-ede-nta-01. Le document reste un Internet-Draft individuel ; aucune adoption ni publication RFC n’est acquise.
• EDE 33 indique qu’une ancre de confiance négative couvrait la réponse au moment de sa production. Le projet autorise ce signal même si la NTA n’a eu aucun effet matériel sur le contenu.
• Une fiche d’effet limitée devrait relier l’origine du signal et l’état de protection du trajet à un test contemporain sans NTA, ou mentionner honnêtement que ce contrefactuel n’a pas été mesuré.

Un numéro attribué n’est pas une conclusion de procédure

L’appel de DNSOP a commencé le 2 septembre et doit se terminer le 16. Il demande si le groupe de travail doit prendre en charge un texte consacré à la divulgation des Negative Trust Anchors dans les réponses DNS. Le Datatracker affiche encore Call For Adoption By WG Issued. La révision 01 vise le statut Informational et demeure un projet individuel, non un RFC.

Parallèlement, le registre DNS d’IANA contient déjà la valeur 33, intitulée Negative Trust Anchor. Ce point de coordination évite à plusieurs implémentations d’inventer des nombres concurrents. Il ne préjuge pas l’issue de l’appel, ne gèle pas le texte et ne mesure aucun déploiement.

Les états sont donc séparés : attribution d’un identifiant, garde d’un document par un groupe, publication éventuelle et comportement réel des résolveurs. Dire « le code existe » est exact. En déduire « la norme est adoptée » ou « tous les résolveurs l’envoient » ne l’est pas.

La NTA suspend une règle locale

Le RFC 7646 décrit une NTA comme une configuration du résolveur récursif. À partir d’un nom choisi, le validateur cesse d’appliquer la chaîne DNSSEC ordinaire et traite les réponses couvertes comme non signées. La zone n’est pas réparée. Sa délégation ne change pas. Le résolveur n’acquiert aucune autorité sur les données de la zone.

L’exception est encadrée. Elle ne doit pas être créée automatiquement. Des techniciens formés doivent chercher à distinguer une mauvaise configuration d’une attaque, vérifier que le domaine n’est pas volontairement cassé et tenter raisonnablement de joindre son responsable. La portée doit rester étroite. Le RFC recommande des retests, une expiration automatique, une durée ne dépassant pas une semaine, un retrait rapide après retour de la validation et la purge du cache sous le nœud concerné.

Ces obligations appartiennent au cycle de vie de la décision. D’autres articles de BTW ont déjà analysé son autorisation, son échéance et sa suppression. Le présent article observe un autre objet : ce qu’une application peut conclure d’une réponse précise qui contient EDE 33.

Un état d’environnement, pas toujours une cause

La révision 01 définit EDE 33 comme l’indication qu’une NTA couvrante était active lorsque la réponse a été générée. Le code reste diagnostique, ne change pas le traitement du bit AD et n’est pas destiné à un serveur faisant seulement autorité.

Le projet recommande à l’opérateur qui applique une NTA d’insérer ce code dans les réponses touchées. Puis il ouvre volontairement la portée : le résolveur peut l’ajouter à toute réponse pendant que l’exception est active, même si celle-ci n’a pas matériellement changé le contenu.

Deux noms placés sous la même NTA peuvent donc produire le même signal. Sans l’exception, le premier échouerait à la validation et le second réussirait. EDE 33 accompagne alors, d’un côté, une réponse rendue possible par la suspension et, de l’autre, une réponse qui serait identique. Le paquet ne contient pas le résultat de la branche alternative.

Cette conception évite d’imposer deux parcours de validation à chaque requête. Elle conserve aussi une information utile : le client apprend qu’une protection a été suspendue quelque part au-dessus du nom. En contrepartie, l’observateur doit refuser de transformer la présence du code en causalité.

d et t ajoutent du contexte, non un verdict

Le champ EXTRA-TEXT peut donner le nom configuré, la raison, une référence ou la durée attendue. Avec le format structuré mentionné par le projet, d désigne le domaine de la NTA et t une heure indicative jusqu’à laquelle elle pourrait rester en place.

Ces données sont facultatives. Le nom couvrant ne dit pas si la réponse aurait été Bogus sans l’exception. L’heure est une estimation, pas un événement de retrait. Une raison lisible n’est ni l’identité de l’approbateur ni la preuve de son mandat. Plusieurs NTA peuvent produire plusieurs instances ; du texte est alors exigé pour chacune, mais la liste ne désigne toujours pas la cause du résultat.

Le RFC 8914 rappelle que tout EDE est un complément et ne doit pas modifier le traitement DNS. Sans protection appropriée de la transaction ou du transport, son contenu n’est pas authentifié. Un relais peut le supprimer, le transmettre ou en créer un nouveau. L’attribution de la source est recommandée précisément parce que le dernier émetteur peut sembler être l’auteur du diagnostic.

La phrase soutenable est donc : « le système répondant déclare qu’une NTA couvrait cette réponse à cet instant ». Le signal ne prouve pas que la zone était mal configurée, que l’exception était justifiée, qu’elle a changé l’issue ou qu’elle existe encore. Son absence ne prouve pas non plus la validation normale, puisque l’émission n’est pas obligatoire et qu’un intermédiaire peut l’effacer.

Le décor de démonstration a bougé

Le fil d’adoption fournit un cas particulièrement instructif. La révision 01 utilise une délégation enfant volontairement invalide pour illustrer la réponse. Dans un message du 2 septembre, le coauteur Joe Abley a averti que l’automatisation de Cloudflare réparait la délégation ou supprimait le point de coupure. L’exemple en ligne ne correspondait donc plus, à cet instant, à l’état recherché ; les auteurs ont annoncé une correction.

Ce fait ne prouve ni panne ni défaillance du résolveur. Il montre qu’une expérience possède sa propre horloge. Le texte peut rester immobile tandis que le DNS qu’il cite est réparé. Le code peut toujours signaler une NTA, alors que le contrefactuel qui justifiait l’exemple a disparu.

Une discussion d’implémentation antérieure avait déjà constaté qu’une réponse portant EDE 33 ne révélait ni le niveau exact de la NTA, ni l’existence d’autres exceptions, ni le résultat qu’aurait produit la validation ordinaire. Le diagnostic était véridique dans son périmètre, sans devenir une explication totale.

Une fiche d’effet distincte du dossier d’autorisation

Il serait dangereux de charger EXTRA-TEXT avec des tickets internes, des adresses de clients ou un historique complet des requêtes. Le protocole doit rester petit. L’élément manquant peut prendre la forme d’une fiche d’effet de la NTA conservée par l’opérateur. Il s’agit de ma proposition éditoriale, non d’une exigence IETF ou IANA.

Pour un échantillon ou un incident, elle relierait l’heure et l’empreinte de la réponse ; le rôle du résolveur ou du relais ; l’origine d’EDE ; la protection du trajet observé ; les valeurs d et t divulguées ; l’état AD ; le résultat d’une validation contemporaine dans un chemin isolé sans NTA, ou la mention non mesuré avec motif ; la différence éventuelle des données ou du résultat ; et un pointeur vers le dossier séparé d’autorisation et d’expiration.

Il n’est pas nécessaire de doubler chaque requête réelle. Un opérateur peut échantillonner, reproduire sans risque ou déclarer que le contrefactuel manque. La publication peut agréger des classes d’effet sans exposer les noms ni les utilisateurs. L’honnêteté consiste à préserver l’inconnu au lieu de lui attribuer la cause la plus commode.

Le Policy Mirror de Heng Lu sépare l’acteur, la règle et la preuve. IANA tient l’index ; le processus IETF porte le document ; le résolveur exerce l’exception ; un chemin particulier transporte le message. Running Code Primary demande ensuite d’ancrer la conclusion dans le comportement observé plutôt que dans le seul projet.

EDE 33 améliore la transparence en reconnaissant sa limite. Il sait annoncer la présence de l’exception. La preuve de son effet reste une opération distincte.

Sources

1. Appel à l’adoption de DNSOP
2. Fiche courante du Datatracker
3. Projet sur la divulgation des NTA, révision 01
4. Historique du document
5. Signalement de Joe Abley sur l’état de l’exemple
6. Discussion sur la limite de l’implémentation
7. RFC 7646 — Negative Trust Anchors DNSSEC
8. RFC 8914 — Extended DNS Errors
9. Paramètres DNS d’IANA
10. Fiche du groupe DNSOP
11. Heng Lu — The Policy Mirror
12. Heng Lu — Running Code Primary