Résumé

  • RFC 9532 autorise un intermédiaire HTTP à publier, dans Proxy-Status, les alias et noms canoniques reçus pendant la résolution du prochain saut.
  • La chaîne peut être partielle, absente ou vide ; elle ne contient aucune preuve DNSSEC et sa fiabilité ne dépasse pas celle du proxy et de ses résolveurs.
  • Une décision sérieuse doit relier le témoin, la réponse DNS, la validation, l’authentification du point final, la règle locale et l’effet produit.

La console affichait trois noms alignés, puis une adresse. Tout semblait enfin explicable : le domaine demandé, l’alias intermédiaire, le service final. Il aurait été tentant de convertir cette visibilité en verdict d’identité.

Le RFC 9532 interdit précisément ce raccourci. Son paramètre next-hop-aliases permet au proxy de déclarer les CNAME et noms canoniques qu’il a reçus lors de la résolution de son prochain saut. Il restaure une partie de ce que le client ne voit plus lorsqu’il délègue la résolution. Il ne transforme pas l’intermédiaire en autorité DNS, ni la liste en certificat du service.

Une observation située

Le besoin est réel. Le champ Proxy-Status défini par le RFC 9209 peut déjà nommer un prochain saut, mais un seul élément ne raconte pas une chaîne d’alias. Or un CNAME peut cacher un traceur ou une destination malveillante derrière un nom de première partie apparemment rassurant. Un navigateur ou un client d’entreprise peut vouloir connaître cette indirection avant d’appliquer sa politique de cookies, de blocage ou d’accès.

RFC 9532 transporte cette vue dans une chaîne Structured Fields. À l’intérieur, les noms sont séparés par des virgules. Ils peuvent inclure le nom demandé, puis les alias et le nom canonique. L’ordre est recommandé pour la cohérence, pas imposé comme une preuve chronologique absolue.

La forme exige une lecture à deux étages. Il faut d’abord décoder le champ structuré selon le RFC 8941, puis interpréter la liste interne. Une virgule appartenant à un nom doit être encodée en pourcentage. Un point faisant partie d’une étiquette DNS doit d’abord être échappé ; la barre oblique inverse est ensuite encodée. Inverser ces opérations peut produire un autre nom que celui transmis.

Pour l’audit, conserver uniquement la liste finale est donc insuffisant. Il faut les octets du champ HTTP, la version du parseur, les étapes de décodage et les étiquettes obtenues.

La chaîne complète peut ne jamais atteindre le proxy

Le standard reconnaît une limite d’implémentation importante. Des interfaces répandues comme getaddrinfo peuvent retourner le dernier nom canonique avec AI_CANONNAME, sans fournir les alias antérieurs. Le proxy est alors autorisé à envoyer une information incomplète.

La conformité syntaxique n’implique pas l’exhaustivité historique.

Quatre états doivent rester distincts. L’absence du paramètre peut signifier qu’il n’est pas pris en charge, qu’il n’était pas applicable, qu’un intermédiaire l’a supprimé ou qu’il n’a pas été émis. Une chaîne vide signifie seulement que le proxy déclare n’avoir rencontré aucun CNAME. Une liste remplie rapporte les noms disponibles. Une valeur mal formée ne peut pas être utilisée sans ambiguïté.

Même une chaîne vide ne décrit qu’une résolution, depuis un point d’observation et à un moment donné. Le cache, le DNS partagé, la politique du résolveur ou une réponse autoritative différente peuvent produire une autre vue. Un résolveur récursif ou autoritatif peut omettre les CNAME afin de masquer un cloaking. Un proxy malveillant peut faire de même. Le silence n’est donc pas une preuve d’absence.

DNSSEC demeure une autre couche

Le texte de RFC 9532 est sans équivoque : next-hop-aliases ne transporte aucune information DNSSEC et ne signifie pas que DNSSEC a été utilisé. La liste est un indice. Elle ne devrait pas servir à décider de l’identité de la ressource.

Les RFC 4033 et RFC 4035 décrivent une chaîne différente : enregistrements de sécurité, ancres de confiance, validation de l’origine et de l’intégrité, preuve d’inexistence. Rien de cela n’est inclus dans une chaîne d’alias rapportée par le proxy.

Et DNSSEC ne ferme pas tout le dossier. Il peut valider les données DNS. Il ne prouve pas, à lui seul, la possession de la clé TLS, l’identité d’un compte applicatif, le droit de déposer un cookie ou l’autorisation de révéler des données. Chaque succès conserve sa portée.

Nommer le témoin avant de croire le récit

Une trace défendable commence par le proxy : identité, relation de confiance, version et place dans la chaîne d’intermédiaires. Elle nomme ensuite le résolveur, son mode de validation, son cache et sa configuration. Elle conserve les questions et réponses DNS, les CNAME, l’adresse terminale, les TTL et les éléments DNSSEC obtenus séparément.

Puis vient la transformation : chaîne complète ou partielle, ordre, échappement, encodage et sérialisation. Enfin viennent la connexion, l’authentification du point final, la politique du client et l’action effectivement exécutée.

Cette séparation reprend la discipline des couches de réalité de Heng Lu. Un nom n’est pas une réponse. Une réponse n’est pas la déclaration du proxy. La déclaration n’est pas une validation. La validation n’est pas une authentification. L’authentification n’est pas une autorisation.

Le principe du minimum initial convient également. RFC 9532 fournit une grammaire commune mince. Les navigateurs, entreprises et applications gardent la décision locale sur le risque, les cookies et l’accès. La coordination n’a pas besoin de devenir un verdict central.

Utilité sans inflation de pouvoir

Une chaîne rapportée peut déclencher une vérification supplémentaire, expliquer une route inattendue ou révéler qu’un service de première partie dépend d’un autre domaine. Elle peut enrichir un dossier d’incident. Elle peut être comparée à une capture DNS indépendante.

Sa force vient de cette modestie. Le registre IANA coordonne le nom du paramètre ; il ne certifie aucune mise en œuvre. Les RFC décrivent la sémantique ; elles ne prouvent ni l’adoption, ni le comportement d’un navigateur nommé, ni la fréquence du cloaking. Les exemples restent des illustrations.

Le rapport n’acquiert une autorité décisionnelle que lorsqu’il rejoint les autres preuves dans une chaîne exécutée et révisable.

Sources