Résumé

  • Les RCODE historiques disent le résultat commun, mais réduisent des causes très différentes à SERVFAIL ou REFUSED. L’option EDNS 15 ajoute un INFO-CODE enregistré et, si nécessaire, un texte destiné aux humains.
  • Une EDE peut accompagner une erreur, un NXDOMAIN, un refus ou même NOERROR. Plusieurs options peuvent coexister, mais aucune ne remplace les règles de traitement du RCODE.
  • La provenance du diagnostic reste fragile : un relais choisit de le transmettre ou de le recréer, la taille peut le faire disparaître avant les données essentielles, le texte peut révéler une politique interne et une EDE non protégée peut être falsifiée.

La différence entre les deux SERVFAIL n’est pas cosmétique. Le premier invite à examiner la connectivité, les serveurs faisant autorité et les délais. Le second invite à vérifier une signature, une délégation DS, une clé ou une horloge. Interroger ensuite un résolveur qui ne valide pas peut produire une adresse, mais cette « réussite » abandonne précisément la condition qui avait provoqué le refus.

Le résultat compact était donc juste et insuffisant à la fois. Il devait rester stable pour l’interopérabilité, tandis que le chemin de réparation avait besoin d’une preuve plus fine.

Le RCODE décrivait une issue, non un dossier d’incident

RFC 1035 a fixé les grandes issues d’une réponse DNS : absence d’erreur, erreur de format, défaillance du serveur, nom inexistant, opération non prise en charge ou refus. Cette petite grammaire permet au client de réagir sans connaître les caches, les validateurs et les serveurs amont.

Elle ne peut cependant pas dire si un serveur charge encore sa zone, si toutes les autorités sont injoignables, si une erreur est servie depuis un cache, si une preuve DNSSEC manque ou si une politique bloque la réponse. Un même code peut cacher une panne transitoire, une exigence de sécurité ou une décision institutionnelle.

Ajouter toutes ces causes au RCODE aurait confondu résultat et explication. Il fallait une couche extensible qui demeure subordonnée au résultat de base.

Une option EDNS porta la cause à côté du résultat

RFC 6891 avait créé le pseudo-enregistrement OPT et un espace d’options. OPT appartient au message, pas aux données ordinaires publiées par une zone. Il offre donc un lieu naturel pour un contexte de transport ou de traitement.

RFC 8914, publié en 2020, attribua le numéro 15 à Extended DNS Error. Son contenu commence par un INFO-CODE de 16 bits. Le reste peut contenir un EXTRA-TEXT UTF-8.

Le nombre et la phrase n’ont pas le même statut. Le nombre indexe un registre IANA et permet une classification stable. La phrase aide un humain, mais ne constitue pas une syntaxe à analyser automatiquement. Elle peut être vide, ne doit pas être supposée terminée par un octet nul et tire sa longueur du champ EDNS.

Une EDE peut se joindre à SERVFAIL, NXDOMAIN, REFUSED, NOERROR ou un autre RCODE lorsque la requête comportait OPT. Plusieurs EDE peuvent figurer dans le même message. Le destinataire doit les accepter, sans devoir agir sur chacune.

La règle structurante reste négative : l’EDE ne modifie pas le traitement du RCODE. SERVFAIL avec DNSSEC Bogus demeure un échec. NOERROR avec Stale Answer fournit une réponse, mais signale son âge. Le contexte oriente l’enquête ; il ne rouvre pas la décision protocolaire.

Un état Bogus n’attribuait pas une attaque

RFC 4035 distingue Bogus et Indeterminate. Un ensemble est Bogus lorsque le résolveur pense qu’une chaîne de confiance devrait pouvoir être établie, mais que la validation échoue ou que les données attendues manquent. Cela peut indiquer une attaque, une mauvaise configuration ou une corruption.

Indeterminate signifie que le résolveur ne peut même pas déterminer si l’ensemble devrait être signé, faute d’obtenir les enregistrements DNSSEC nécessaires. L’un est un échec de preuve attendue ; l’autre est une incapacité à déterminer l’obligation de preuve.

RFC 8914 leur attribue des codes distincts. Il distingue aussi algorithme DNSKEY non pris en charge, condensat DS inconnu, signature expirée ou prématurée, DNSKEY ou RRSIG absent, bit de clé de zone manquant et preuve NSEC absente.

Cette précision réduit le champ des hypothèses, sans désigner automatiquement le responsable. La correction peut dépendre de la zone enfant, de la zone parente, du registraire, d’une horloge, d’un logiciel ou d’un chemin qui a perdu des données. Le code rapporte l’état atteint par le résolveur ; il ne rend pas un jugement sur une organisation.

Une réponse réussie pouvait avouer son ancienneté

Quand une actualisation échoue, un résolveur peut préférer une donnée récemment expirée à une panne complète. RFC 8767 encadre cette continuité. Le code 3 signale une ancienne réponse positive ; le code 19, un ancien NXDOMAIN.

NOERROR et Stale Answer peuvent donc apparaître ensemble. Le RCODE décrit ce qui est livré maintenant. L’EDE décrit la condition temporelle de cette livraison. Continuer à servir la copie ne remet pas son TTL à neuf et ne prouve pas que l’autorité vient de confirmer son contenu.

Le code 4, Forged Answer, s’emploie lorsqu’une politique a modifié une réponse qui reste fournie. Si la politique empêche toute réponse, Blocked, Censored et Filtered distinguent respectivement une politique interne de l’opérateur, une contrainte extérieure et un filtrage demandé par le client. Prohibited peut préciser un refus opposé à un client non autorisé.

Ces catégories rendent visible le lieu déclaré du contrôle. Elles ne prouvent ni le fondement juridique d’un blocage ni la qualité d’une liste, et n’authentifient pas celui qui les émet.

Une erreur en cache n’était pas une nouvelle tentative

Répéter toute une résolution après chaque demande peut amplifier une panne. RFC 9520 précise la mise en cache bornée des échecs de résolution.

EDE 13, Cached Error, indique que le SERVFAIL actuel provient de cet état conservé. Ce n’est ni une donnée de zone faisant autorité ni la preuve que l’incident initial persiste au même instant. C’est une provenance locale.

La distinction empêche de compter mille lectures d’une même erreur comme mille observations indépendantes. Une nouvelle preuve exige d’attendre l’expiration, d’interroger un autre point de contrôle ou de tester directement le chemin d’autorité.

Le relais pouvait conserver le code et perdre le témoin

Le client parle souvent à un résolveur local, qui peut transférer la requête à un autre service. L’auteur initial de l’EDE n’est donc pas nécessairement l’adresse visible par le client.

RFC 8914 laisse au relais le choix de supprimer, transmettre ou recréer l’information. S’il relaie une cause observée en amont, il devrait en attribuer la source dans EXTRA-TEXT, faute de quoi le client lira le diagnostic comme une affirmation du résolveur immédiat.

Plusieurs EDE permettent de garder plusieurs couches : validation amont, échec mis en cache localement, décision de filtrage à la sortie. Mais une liste de numéros sans source n’est pas une chaîne de responsabilité. Le texte peut restaurer l’attribution, tout en restant non structuré et non authentifié par défaut.

Dans un paquet trop grand, l’explication partait d’abord

Une longue phrase peut dépasser la taille UDP annoncée par le demandeur. RFC 8914 recommande alors de retirer les EDE avant les autres données et de positionner le bit de troncature lorsque l’option a été supprimée.

Cette priorité confirme que le diagnostic est supplémentaire. Son absence ne prouve pas l’absence de cause connue : taille, politique du relais ou absence de prise en charge peuvent l’avoir éliminé. Les journaux doivent distinguer génération, transmission, remplacement, suppression et troncature.

La concision devient une qualité opérationnelle. Un texte trop abondant peut provoquer un passage à TCP ou faire disparaître l’explication avant qu’elle atteigne celui qui en avait besoin.

Une explication précise pouvait toujours être fausse

Les mots « signature expirée » inspirent davantage confiance qu’un code opaque. Pourtant la précision n’est pas une authentification.

RFC 8914 avertit qu’une EDE n’est authentifiée que si la transaction DNS est elle-même sécurisée ou authentifiée. Un adversaire capable d’insérer un diagnostic peut aussi être capable de modifier un RCODE ou une adresse. L’information doit donc rester diagnostique et ne jamais changer le traitement DNS.

Le texte libre crée également une fuite possible : numéro de compte, nom d’un amont, présence sur une liste de blocage, politique interne. L’objectif n’est pas de publier tout l’état du résolveur, mais de fournir l’information minimale qui permet de choisir le prochain test et le bon responsable.

Le registre des paramètres DNS de l’IANA consigne l’option 15 et les INFO-CODE ajoutés au fil du temps. Il prouve la coordination des numéros et des références, non leur déploiement, leur exactitude, leur transport protégé ou leur présentation aux utilisateurs.

L’innovation de l’EDE tient ainsi à une retenue. DNS a obtenu une mémoire explicative plus riche sans donner à cette mémoire le droit de réécrire l’issue. Le RCODE gouverne le traitement ; l’EDE fournit une piste. Séparer ces fonctions permet de réparer plus vite sans confondre disponibilité et confiance.