Résumé

  • Avec RFC 9567, un serveur faisant autorité annonce spontanément un domaine d’agent dans l’option EDNS Report-Channel. Le résolveur validateur qui constate un EDE fabrique ensuite une requête TXT distincte ; le message fautif n’est ni corrigé ni remplacé.
  • Le retour reste une observation limitée : aucune authentification de bout en bout ne lie le résolveur à l’agent, le cache étouffe les répétitions et TCP ou DNS Cookies renforcent la provenance de l’adresse sans certifier la justesse du diagnostic.

Prenons une zone dont une signature RRSIG a expiré sur un seul serveur. Celui-ci continue de recevoir des questions et d’émettre des réponses. Dans ses journaux, le service fonctionne. Le résolveur validateur, lui, rejette le RRset. L’information décisive naît après la frontière d’observation de l’opérateur.

RFC 9567 organise le chemin inverse. La réponse autoritaire peut contenir l’option EDNS numéro 18 et un nom de domaine pleinement qualifié désignant l’agent de suivi. L’option est non sollicitée : elle ne figurait pas dans la question et ne doit jamais y figurer. Elle dit « voici où parler », sans dire « tu dois parler ».

Le résolveur compatible et configuré évalue l’échec selon le vocabulaire des Extended DNS Errors. Il crée alors une autre question DNS. Pour une requête A sur broken.test associée au code EDE 7, le nom peut devenir _er.1.broken.test.7._er.a01.agent-domain.example. Le type demandé est TXT. Le nom demandé porte déjà l’objet, le type et le diagnostic.

Le rapport n’est donc pas une métadonnée qui remonte à l’intérieur de la réponse défaillante. C’est une nouvelle transaction vers une autre autorité. Le contenu TXT n’a d’ailleurs aucun sens normalisé dans RFC 9567. Une réponse positive sert surtout à confirmer que le nom d’agent est résolu et à fournir un TTL au cache.

L’adresse de retour ne distribue pas tous les pouvoirs

L’hébergeur autoritaire choisit l’agent qu’il annonce. Le résolveur possède l’observation, puisqu’il a exécuté la validation, retenu un code EDE et appliqué sa politique de signalement. L’agent reçoit, classe et rapproche. L’opérateur de zone décide d’une correction éventuelle. Aucun paquet ne fusionne ces quatre mandats.

Le registre DNS de l’IANA fixe le code 18 et le nom _er. Cette inscription rend la syntaxe interopérable. Elle ne démontre ni activation, ni livraison, ni exactitude, ni adoption actuelle.

EDE reste lui-même un constat borné. RFC 8914 précise que l’information étendue ne modifie pas le traitement du RCODE. RFC 9567 ne définit pas ce qui constitue une erreur et n’impose pas tous les codes à tous les résolveurs. Une requête de rapport signifie donc : « ce résolveur a classé cette combinaison nom/type ainsi ». Elle ne signifie pas : « toute l’Internet est en panne ».

La validation DNSSEC donne parfois un objet cryptographique reproductible, par exemple une signature expirée ou une chaîne DS/DNSKEY rompue. Mais une ancre de confiance locale périmée peut aussi produire l’échec. L’agent doit refaire la validation depuis un point indépendant avant d’attribuer la cause à la zone.

Un incident compressé dans un QNAME

Le nom de rapport enchaîne _er, le QTYPE décimal, les labels du nom défaillant, le code EDE, un second _er, puis le domaine de l’agent. Le RCODE ordinaire et la classe DNS sont absents. Le premier marqueur signale à l’agent qu’il voit le nom complet, et non un fragment révélé pendant la minimisation ; le second sépare l’incident de sa destination.

Cette enveloppe rencontre une limite nette. Au-delà de 255 octets, elle ne doit pas partir. Le résolveur doit aussi borner la profondeur ou la dépense, car la résolution de l’agent peut échouer et engendrer un autre rapport. L’abandon est préférable à une récursion de diagnostics.

Le domaine d’agent ne doit pas être un sous-domaine de la zone signalée. La panne ne doit pas couper son propre canal de retour. Un nom court laisse davantage de place au QNAME d’origine. L’architecture du nom devient ainsi une mesure de disponibilité.

Prouver la joignabilité n’est pas prouver le diagnostic

RFC 9567 n’authentifie pas le résolveur auprès de l’agent. Un paquet UDP peut usurper son adresse et un résolveur réellement joignable peut se tromper. La recommandation est d’utiliser DNS Cookies, DNS sur TCP ou un autre transport orienté connexion. Sans Cookie sur UDP, l’agent devrait répondre avec TC pour exiger un nouvel essai TCP.

Ces contrôles augmentent la confiance dans l’adresse source. Ils ne certifient ni l’identité juridique de l’exploitant, ni l’état de ses ancres, ni la vérité du code EDE. Une adresse connue peut recevoir un poids supérieur ; elle ne reçoit pas pour autant le pouvoir d’éditer la zone.

Cette nuance commande l’automatisation. Une requête UDP anonyme peut ouvrir une observation. Plusieurs résolveurs connus, passés par TCP et reproduisant la même chaîne, peuvent ouvrir un incident. La modification DNS reste soumise à une validation indépendante et au contrôle du propriétaire de zone.

Le cache protège l’agent et déforme la mesure

L’agent devrait répondre positivement avec un TXT. Le TTL permet au résolveur de ne pas répéter sans cesse le même rapport. Ce frein rend le dispositif léger, mais empêche de lire le volume reçu comme un nombre d’utilisateurs ou de tentatives.

NXDOMAIN est particulièrement destructeur. RFC 8020 peut étendre ce verdict aux descendants, tandis que RFC 2308 le conserve. Un seul déni sous le domaine d’agent peut faire disparaître des rapports différents. L’agent ne doit donc pas répondre NXDOMAIN aux noms suivis ; un joker positif est une solution possible.

Avec une zone d’agent signée, RFC 8198 permet de synthétiser certains dénis depuis le cache DNSSEC. Des requêtes suivantes n’atteignent plus l’agent. RFC 9567 évoque un domaine d’agent non signé pour éviter cette charge particulière, tout en imposant au résolveur le traitement normal de validation afin qu’un domaine réellement signé ne soit jamais rétrogradé par supposition.

Le silence devient alors ambigu. Il peut annoncer la réparation, l’effet d’un TTL, une synthèse négative, une panne de l’agent, l’abandon du mécanisme ou un filtrage anti-abus. La santé doit être mesurée par une validation indépendante, non par la seule disparition des rapports.

Le canal de retour ouvre aussi une surface d’attaque

Le QNAME révèle à l’agent le nom, le type et le code d’erreur. Il peut également dévoiler une faute locale du résolveur. La minimisation réduit ce que voient les autorités intermédiaires, mais l’agent reçoit nécessairement le rapport complet.

Un adversaire peut publier une zone volontairement cassée et désigner comme agent le domaine d’une victime. Des résolveurs ouverts ou des sondes distribuées enverront alors des requêtes supplémentaires vers cette cible. Un déluge de faux rapports peut aussi dissimuler la vraie panne. Les limites de débit, la séparation des niveaux de provenance et la détection d’agents sans lien avec la zone font partie du mécanisme opérationnel.

Même le TXT de réponse est une donnée hostile si on le journalise. RFC 9567 ne lui donne aucun rôle. Une valeur fixe et un analyseur limité aux labels attendus réduisent le risque de transformer un canal d’alerte en entrée de commande.

Les distinctions de Heng Lu entre le code en fonctionnement, la spécification minimale et la décision locale et les couches de réalité éclairent ce partage. Le standard définit l’adresse et la grammaire. L’autorité annonce. Le résolveur juge. Le réseau livre. L’agent pondère. L’opérateur corrige. L’utilisateur retrouve — ou non — un résultat validable.

La preuve sérieuse conserve chaque étape : réponse originale, état DNSSEC, domaine d’agent, QNAME construit, motif d’abandon, transport, Cookie, réponse et TTL, reproduction indépendante, changement de zone et validation après correction. Le retour devient utile précisément parce qu’il ne prétend pas être le verdict final.