Résumé

  • La RFC 8914 place dans l’option EDNS 15 un INFO-CODE de 16 bits et, éventuellement, un texte UTF-8. Plusieurs EDE peuvent accompagner n’importe quel RCODE, y compris NOERROR, sans modifier son traitement.
  • Le message n’est ni automatiquement authentifié ni nécessairement conservé de bout en bout. Un forwarder peut supprimer l’option ou en fabriquer une nouvelle ; même une liaison chiffrée ne garantit pas la justesse du diagnostic.
  • La chaîne de preuve doit relier paquet, ordre des codes, émetteur, transport, validation DNSSEC, cache, règle locale, retry du client et résultat. EDE ouvre une enquête ; il n’autorise pas un repli moins sûr.

L’alerte qui a choisi le mauvais coupable

Dans un centre d’exploitation, deux services cessent d’atteindre le même domaine. Le premier résolveur retourne SERVFAIL avec EDE 7, Signature Expired. Un forwarder d’une autre région renvoie le même RCODE avec EDE 23, Network Error. Le tableau d’alerte déduit immédiatement que le propriétaire de la zone a oublié de renouveler ses signatures et ouvre une procédure externe.

L’explication paraît précise, donc crédible. Pourtant le premier résolveur peut avoir une horloge fausse ; le second peut perdre son transit ; le forwarder peut avoir recomposé le code reçu en amont. Le propriétaire de la zone n’est responsable que si les signatures servies, leur période de validité et les observations indépendantes confirment cette histoire.

EDE améliore le triage : expiration, absence de DNSKEY et autorité injoignable ne demandent pas les mêmes vérifications. Mais le code représente la conclusion locale d’un composant. Le passage de « voilà ce que j’ai observé » à « voilà qui doit agir » appartient à une politique distincte, révisable et appuyée par d’autres preuves.

Deux octets de contexte, aucune nouvelle vérité protocolaire

L’option EDE commence par un INFO-CODE de 16 bits. Le reste peut contenir un EXTRA-TEXT UTF-8 destiné aux personnes, pas à un analyseur automatique. Sa taille vient d’OPTION-LENGTH et non d’un caractère de fin supposé. Un message peut contenir plusieurs options, et le récepteur doit les accepter même s’il ne les interprète pas.

La RFC 8914 autorise EDE avec SERVFAIL, REFUSED, NXDOMAIN, NOERROR et les autres réponses portant un OPT. Elle impose toutefois de continuer à appliquer la spécification du RCODE. Cette séparation empêche un diagnostic d’effacer un échec, de rendre des données sûres ou de convertir une réponse de filtrage en donnée autoritative.

Lorsque le budget UDP est dépassé, EDE doit céder avant les données principales et le serveur devrait poser TC. Une absence d’EDE ne signifie donc pas absence de diagnostic : l’implémentation peut ne pas le produire, le forwarder peut l’omettre ou le paquet peut l’avoir perdu pour des raisons de taille.

Le dernier émetteur n’est pas toujours le premier témoin

Un résolveur intermédiaire peut conserver, jeter ou reformuler l’EDE reçu. S’il le transmet ou le recrée, la RFC recommande d’indiquer la source dans EXTRA-TEXT, car le client voit l’option comme venant du dernier hop. Cette phrase aide l’opérateur, mais ne constitue pas une provenance cryptographique.

Le journal doit séparer l’observateur, le composant qui a choisi le code, celui qui a écrit le texte et celui qui a envoyé le paquet final. DoT, DoH ou DoQ peut protéger un hop et identifier un pair selon le contrat de transport. Un résolveur authentifié reste capable de se tromper ou de mentir. DNSSEC authentifie des données DNS ; il ne signe pas l’interprétation opérationnelle d’un résolveur.

La conséquence pratique est simple : une automatisation ne doit jamais prendre DNSSEC Bogus comme permission de désactiver la validation. Elle conserve le SERVFAIL, compare d’autres validateurs, inspecte DS, DNSKEY, RRSIG, NSEC, horloge et trust anchors, puis répare le maillon confirmé.

Le registre coordonne les nombres, pas la maturité

La RFC 8914 a défini les codes 0 à 24. IANA maintient maintenant une liste plus large. La plage publique relève de First Come First Served, tandis que la plage haute est réservée à l’usage privé. Les références actuelles mélangent RFC, drafts et preuves d’implémentation.

Cette diversité n’est pas une faute : le registre empêche les collisions. Elle interdit cependant d’assimiler inscription et certification. Un nombre enregistré n’atteste ni que la cause s’est produite, ni que le choix du code était pertinent, ni que toutes les plateformes lui donnent exactement la même portée.

La RFC 9606 permet à un résolveur d’annoncer avec RESINFO exterr les codes qu’il peut produire. Un écart persistant entre annonce et paquets rend l’information inexacte. Là encore, la capacité annoncée reste une affirmation du résolveur ; le client conserve sa politique de sélection et sa faculté de refus.

Des implémentations qui ne promettent pas la même chose

Unbound sépare l’activation générale d’EDE, l’étiquetage des réponses périmées et DNS Error Reporting. BIND permet d’associer des codes précis à des réponses modifiées par une Response Policy Zone. PowerDNS Recursor documente les erreurs étendues de résolution et rappelle, pour son signal Negative Trust Anchor, que le code reste diagnostique et ne change ni la validation ni le bit AD.

Ainsi, « EDE activé » n’est pas un inventaire. Il faut connaître les codes émis, les chemins de forwarding, le nombre d’options accepté, le traitement du texte, l’affichage client, la politique RPZ, le cache, les transports et le comportement lorsqu’aucun espace ne reste dans le paquet.

Le texte libre est une entrée non fiable

EXTRA-TEXT peut être vide. Il ne doit pas contenir d’informations privées auxquelles un observateur n’aurait pas accès, par exemple un numéro de compte. Un code Prohibited peut déjà révéler l’existence d’une blocklist ; une phrase détaillée peut divulguer logiciel, topologie ou état interne.

L’interface doit échapper le texte, limiter sa taille, conserver les octets bruts sous accès restreint et refuser toute interprétation en commande, lien de confiance ou objet de politique. La localisation du produit entoure le code avec un message sûr ; elle ne suppose pas que le texte reçu est fidèle, propre ou écrit pour l’utilisateur.

Quand le diagnostic produit une nouvelle requête

La RFC 9567 définit un Report-Channel. Un résolveur validant peut encoder QTYPE, QNAME et code EDE dans une requête destinée à un agent de supervision. Ce retour aide l’opérateur autoritatif à découvrir une signature expirée ou une autre panne qu’il ne voit pas depuis ses serveurs.

Mais résoudre le rapport peut lui-même échouer. Un plafond de profondeur ou de dépense est obligatoire pour éviter une cascade. Le canal ne fournit pas d’authentification mutuelle. TCP ou DNS Cookies augmente la confiance dans l’adresse source ; QNAME minimisation réduit la fuite ; aucune de ces mesures ne transforme le rapport en preuve d’identité ou de responsabilité.

L’agent corrèle donc le signal avec la version de zone, les journaux de signature, les nœuds autoritatifs et des sondes externes. Un rapport peut ouvrir un incident. Il ne doit pas publier une nouvelle zone ou accuser un tiers à lui seul.

Une langue commune mince, une décision locale

Selon Minimum Initial Specification, le commun se limite au code d’option, aux longueurs, à l’index IANA et au maintien du traitement RCODE. Localized Future Decision laisse aux résolveurs, clients et opérateurs le choix d’émettre, afficher ou exploiter un diagnostic. Voluntary Adoption se mesure dans les paquets et les comportements, pas dans la seule publication d’une RFC.

Running-Code Primacy exige une chaîne vérifiable : le pair A a envoyé le code B sur le transport C ; les traces montrent l’observation D ; une vérification indépendante confirme E ; la règle locale autorise l’action bornée F ; les paquets suivants prouvent la réparation. Sans cela, l’organisation possède une étiquette, pas une autorité.

Sources