Résumé

  • RESINFO donne au résolveur un enregistrement faisant autorité pour déclarer la minimisation QNAME, les erreurs DNS étendues disponibles et une page d’information HTTPS.
  • Un canal authentifié ou une validation DNSSEC locale empêche la substitution de la réponse, mais ne vérifie pas séparément la réalité de chaque propriété annoncée.
  • La réputation, la politique de sélection, la cohérence des instances, les traces de requêtes et le résultat final restent des constats distincts.

Le résolveur avait signé sa propre fiche

Un client découvre un résolveur chiffré, ouvre une connexion authentifiée et demande RESINFO sans récursion. La réponse porte le bit d’autorité. Elle contient un seul enregistrement valide : qnamemin, plusieurs codes EDE et une adresse HTTPS pour l’assistance. Aucun tiers n’a pu remplacer cette fiche pendant le transport.

Le client sait donc précisément qui a parlé. Il ne sait toujours pas ce que le serveur faisant autorité a vu lors d’une résolution donnée, si un blocage produira le code annoncé, ni si une autre instance atteinte derrière la même adresse anycast publiera la même fiche.

Cette séparation est le cœur de RFC 9606. Le standard remplace les suppositions opportunistes par une auto-description structurée. Sa section de sécurité prévient également qu’un résolveur chiffré peut fournir des informations incorrectes. L’authentification attribue la phrase ; elle ne transforme pas son contenu en observation indépendante.

La découverte ne choisit pas encore

DNR ou DDR peut révéler un résolveur chiffré et son Authentication Domain Name. Ce premier reçu identifie un candidat et un nom à authentifier. Il ne décrit pas encore ses fonctions de confidentialité ou de filtrage.

Le client interroge ensuite RESINFO au nom de cet ADN. Lorsque DDR emploie resolver.arpa, ce nom spécial peut servir à la même demande. RD doit être nul : l’information appartient au résolveur interrogé et ne doit pas provenir d’une récursion ordinaire. Une réponse sans AA est rejetée. Un résolveur compatible produit exactement un enregistrement ; les formes invalides sont ignorées.

Ces règles empêchent une confusion de rôles. Elles prouvent la destination, la forme d’autorité revendiquée et la conformité syntaxique. La connexion sûre authentifiée ou la validation DNSSEC locale ajoute l’intégrité. Dans le cas resolver.arpa, seule la connexion authentifiée convient, car un serveur qui ne comprend pas RESINFO pourrait transmettre la question en amont.

Le résultat reste une déclaration sous garde. Il ne contient ni paquet de la marche de délégation ni décision du client.

qnamemin ne contient aucune trace

La présence de qnamemin indique une configuration destinée à réduire les données sensibles du nom envoyées aux serveurs faisant autorité selon RFC 9156. Le champ est volontairement booléen. Il n’enregistre ni le nom testé, ni l’état du cache, ni les exceptions, ni les replis, ni la suite des délégations.

Pour tester le comportement, il faut préparer un domaine contrôlé et un cache connu, dater la mesure, identifier l’instance jointe et observer les demandes sur chaque zone de la chaîne. La comparaison porte sur les labels réellement exposés. Une seconde mesure après changement de version ou de configuration permet de voir si le comportement a suivi l’intention.

Une trace réussie reste locale à un scénario. Elle vaut davantage qu’un drapeau pour cette requête, sans devenir un certificat éternel. La fiche expose la configuration annoncée ; la trace expose une exécution.

exterr décrit les mots disponibles, pas la légitimité du filtre

Le champ exterr énumère des codes Extended DNS Error que le résolveur sait renvoyer. Les codes Blocked, Censored ou Filtered peuvent expliquer certaines réponses de politique. Leur présence dans la liste n’assure ni que chaque événement sera expliqué, ni que la règle appliquée était correcte, ni que le client montrera la raison à l’utilisateur.

RFC 9606 offre néanmoins un contrôle concret. Si le client reçoit un EDE absent de la liste, il peut relire RESINFO. Si l’écart persiste, il peut déclarer la fiche inexacte et l’écarter. Le comportement observé corrige alors l’inventaire symbolique.

L’absence du code annoncé demande plus de prudence. Peut-être qu’aucune condition déclenchante ne s’est produite. Peut-être que le déploiement est incomplet ou que le test a atteint une autre instance. Il faut associer la requête, la réponse, l’EDE, la règle attendue, l’heure et le point d’observation avant de conclure.

Une page HTTPS reste une page

infourl mène vers des informations générales et une procédure de signalement. Le schéma doit être HTTPS et les valeurs invalides sont ignorées. Le standard réserve cette page au diagnostic par le personnel technique et non à la consommation directe des utilisateurs.

HTTPS protège la relation avec le serveur d’information désigné. Il ne garantit ni l’exhaustivité du texte, ni sa fraîcheur, ni l’exécution des engagements. Une procédure de réclamation ne prouve pas qu’une plainte sera traitée. Une politique rédigée ne constitue pas une mesure. Cette page enrichit le dossier d’exploitation sans devenir une autorité automatique de sélection.

L’anycast oblige à conserver le lieu de l’observation

Des instances partageant le même ADN ou la même adresse anycast devraient présenter un RESINFO cohérent. Cette recommandation n’efface pas le routage. Deux clients peuvent atteindre deux machines ; un seul client peut changer d’instance entre la lecture de la fiche et son test de comportement. Une mise à jour peut être déployée progressivement.

Chaque collecte doit donc conserver le point de mesure, l’adresse, la session, l’heure, le TTL et, lorsque c’est observable, l’instance. Des réponses différentes sous un même nom sont un résultat à expliquer, pas des échantillons à fusionner dans un profil imaginaire.

Des fiches égales ne prouvent pas davantage des chemins de code égaux. Des fiches momentanément différentes peuvent accompagner le même comportement. Il faut versionner séparément la déclaration et la mesure.

Le dernier mot revient à la politique locale

Lorsque les attributs ne sont pas vérifiables au moment du choix, RFC 9606 recommande de ne les utiliser que si le résolveur dispose d’une réputation suffisante selon la politique locale. La confiance peut venir de l’utilisateur, de l’administrateur ou d’une liste intégrée.

IANA coordonne le vocabulaire. Le résolveur produit la déclaration. Le canal en établit l’auteur. La politique locale décide du crédit accordé. Cette chaîne protège la liberté du sélecteur : aucune inscription au registre et aucune réponse authentifiée ne contraint le client à adopter le service.

La discipline de Lu Heng sur le code en fonctionnement prend ici une forme précise. Une spécification minimale rend les affirmations comparables ; elle ne remplace pas l’exécution locale. Le format commun devrait faciliter l’audit, pas fournir un costume d’autorité à une case verte.

Sources