Résumé

  • EDE 33 indique qu’une ancre de confiance négative couvrante était active lors de la génération d’une réponse ; il ne démontre ni que l’exception a modifié cette réponse, ni que les données sont authentiques.
  • La gouvernance doit conserver séparément les preuves de configuration, de portée, de divulgation, de validation, de transport et de résultat applicatif.

Une exception jusque-là silencieuse

Une panne de validation DNSSEC oppose deux risques. En maintenant la protection, un opérateur peut rendre inaccessible un domaine dont la signature est simplement mal configurée. En suspendant la validation, il restaure peut-être l’accès, mais renonce délibérément à un contrôle central de DNSSEC. RFC 7646 encadre ce compromis avec l’ancre de confiance négative, ou NTA : une exception locale, temporaire et limitée à un nom dans un résolveur récursif validant.

Cette exception restait difficile à observer depuis le client. Une liste pouvait être publiée sur un site, sans que le message DNS explique qu’il avait été produit sous une NTA active. Le nouveau projet du groupe DNSOP, Disclosure of Negative Trust Anchors in DNS Responses, propose le code Extended DNS Error 33, « Negative Trust Anchor ». La révision 00 date du 23 septembre 2026. C’est un document de travail, ni RFC ni consensus final de l’IETF.

Son assertion est étroite : une réponse contenant EDE 33 a été générée alors qu’une NTA couvrante était en vigueur. Le code appartient au résolveur récursif qui applique l’exception. Un serveur faisant uniquement autorité, sans valider, ne devrait pas l’émettre. L’opérateur devrait le joindre aux réponses concernées afin de signaler qu’elles pourraient ne pas avoir été validées par DNSSEC.

Cette visibilité est un progrès. Elle ne répond pourtant pas aux questions décisives.

Déclarer n’est pas authentifier

Le texte de la révision 00 qualifie EDE 33 de diagnostic. Sa présence ne doit pas modifier le traitement protocolaire par le client et ne change rien au bit AD. Cette limite vient de RFC 8914 : un EDE complète le contexte d’une réponse, sans remplacer le RCODE ni commander un comportement nouveau.

Le code ne prouve pas non plus la causalité. Un résolveur peut l’ajouter tant qu’une NTA est active, même si cette dernière n’a eu aucun effet matériel sur la réponse. Pour savoir si la requête aurait échoué sans l’exception, il faut le journal du validateur ou une répétition contrôlée sans NTA.

Il n’authentifie pas davantage les données. Une NTA existe précisément parce que le résolveur cesse d’exiger la validation ordinaire pour une portée donnée. RFC 4035 décrit le travail du validateur et ses états de sécurité ; EDE 33 ne reconstruit pas la chaîne de confiance suspendue. Il constate le choix de l’opérateur.

Le diagnostic lui-même ne porte pas de signature cryptographique intrinsèque. Un acteur sur le chemin peut l’ajouter, le supprimer ou le modifier. TSIG, SIG(0), DNS over TLS ou DNS over HTTPS peuvent protéger un message ou un segment pertinent. Même intact, le code ne démontre que le rapport du résolveur identifié. Il ne prouve pas que la panne est bénigne, que l’enquête a été suffisante, ni que l’adresse obtenue mène au service attendu.

Six pièces au dossier

La preuve de configuration identifie le nom exact, l’opérateur, l’incident, l’approbateur, l’heure de création et l’expiration prévue. RFC 7646 impose une durée limitée : une dérogation large ou permanente trahit le mécanisme.

La preuve de portée établit que ce QNAME et cette réponse étaient couverts à cet instant. Une NTA placée sur un ancêtre peut affecter un descendant et plusieurs NTA peuvent se cumuler.

La preuve de divulgation conserve la réponse brute, l’identité du résolveur, l’heure d’observation et chaque occurrence d’EDE 33. Plusieurs occurrences sont permises, chacune avec son EXTRA-TEXT. Le champ structuré d peut désigner le domaine de configuration ; t peut indiquer un horizon de maintien. Ce dernier n’est ni une promesse ni un reçu de suppression.

La preuve de validation réunit les bits AD/CD, les journaux et le résultat contrôlé sans exception. Le code ne fournit pas ce contrefactuel.

La preuve de transport montre si le trajet entre client et résolveur empêchait l’altération du diagnostic. Elle protège une provenance dans un contexte donné, pas la qualité du jugement humain.

La preuve applicative montre ce que le stub et l’application ont reçu, affiché et utilisé. Une réponse DNS peut être livrée tandis que l’application échoue, choisit une autre adresse ou rejoint le mauvais point de terminaison.

Réduire ces six pièces à une seule formule produit une erreur : « la NTA est déclarée, donc la réponse est sûre ». La conclusion défendable est plus modeste : « ce résolveur rapporte qu’une NTA couvrait cette réponse à cet instant ».

La transparence a aussi une limite de confidentialité

EXTRA-TEXT peut mentionner le nom, la raison, une référence ou la durée attendue. Il doit rester lisible et exclure les données privées ou sensibles. Un numéro de ticket, un client, un nom interne ou un plan d’incident non publié ne devient pas anodin dans une option DNS.

Les champs d et t facilitent l’observation automatisée, sans changer la force de preuve. d rapporte le point de configuration selon l’opérateur ; il ne prouve pas la propriété du domaine. t est indicatif ; il ne supprime rien et n’atteste aucune revue. De bonnes métadonnées rendent la dérive visible, elles ne l’empêchent pas.

Un minimum commun, pas une autorisation centrale

L’IETF peut standardiser le plus petit fait interopérable : une exception locale était active. L’opérateur du résolveur conserve la décision et la responsabilité, l’opérateur du domaine doit réparer le DNSSEC faisant autorité, et le client choisit la présentation sans transformer le diagnostic en ordre de confiance.

Cette division rejoint le principe de Heng Lu sur la spécification initiale minimale, la décision future localisée et l’adoption volontaire. Le signal commun ne doit pas devenir un tribunal mondial des exceptions. Sa distinction entre autorité et croyance est également décisive : une étiquette standard identifie un locuteur et une affirmation, sans rendre celle-ci vraie. Enfin, la primauté du code en fonctionnement exige paquets, versions, chemins de transfert, comportement des clients et preuve de retrait avant toute affirmation de déploiement.

Statut et limites

Les exemples de la révision 00 illustrent le mécanisme, ils ne mesurent pas son adoption. Un forwarder peut supprimer ou recréer l’EDE, la contrainte de taille UDP peut éliminer une option supplémentaire, et de nombreux clients ne l’exposeront pas. Le texte peut encore changer.

La proposition améliore néanmoins la surface de preuve : une baisse jusque-là cachée de validation obtient un témoin standard. La discipline consiste à ne jamais confondre ce témoin avec un verdict.

Sources