Résumé

  • La plus petite SvcPriority ne vaut qu'entre enregistrements utilisables. Le client élimine d'abord le contenu malformé, incohérent ou incompatible ; une clé obligatoire inconnue peut donc exclure le choix affiché comme premier.
  • AliasMode délègue la découverte sans changer l'origine. ServiceMode lie cible et paramètres, mais une adresse suggérée ou un ALPN publié reste une entrée : résolution A/AAAA, certificat du nom d'origine, ALPN négocié et réponse applicative constituent des preuves ultérieures.

Une priorité sans droit d'entrée

Une origine publie deux enregistrements HTTPS en ServiceMode. Le premier, priorité 1, vise une nouvelle périphérie et déclare obligatoire une extension expérimentale. Le second, priorité 2, décrit l'infrastructure existante avec des paramètres connus du parc installé. Le tableau d'exploitation annonce : « destination préférée : priorité 1 ».

Pour un client qui ignore l'extension, cette destination ne fait pas partie du choix. RFC 9460 lui impose d'écarter tout enregistrement dont il ne comprend pas toutes les clés obligatoires. Il peut alors employer la priorité 2. Ce n'est pas une inversion de préférence : l'admissibilité précède le classement.

Le scénario est analytique, sans viser un navigateur ou un CDN. Il montre la différence entre publier une intention et faire exécuter un ordre. Le propriétaire DNS compose des plans possibles. Il ne donne pas magiquement aux logiciels la capacité de les comprendre, au réseau la capacité d'ouvrir le port, au serveur la capacité de négocier le protocole, ni au certificat la capacité d'authentifier l'origine.

Deux modes, deux délégations

RFC 9460 attribue le type 64 à SVCB et le type 65 à HTTPS. Une donnée contient SvcPriority, TargetName et éventuellement des SvcParams. Zéro signifie AliasMode ; toute valeur non nulle signifie ServiceMode.

AliasMode renvoie la découverte d'un service vers un autre nom. Il rend notamment possible un alias au sommet d'une zone, là où CNAME ne peut normalement occuper la place. Son effet reste limité au type de service concerné : les autres types DNS ne suivent pas cet alias. Les paramètres présents sont ignorés et la longueur totale des chaînes doit être bornée.

Surtout, l'alias ne rebaptise pas l'origine. Après avoir suivi un TargetName de fournisseur, le client HTTPS présente encore le nom d'origine en SNI, vérifie le certificat pour ce nom et conserve ce même Host ou :authority dans HTTP. Le contrôle délégué porte sur le chemin de découverte, pas sur l'identité à laquelle le lecteur accorde sa confiance.

ServiceMode exerce une autre fonction. Chaque RR lie une cible, un port, un ensemble de protocoles, des indications d'adresse et d'éventuelles extensions. Dans une architecture multi-CDN, chaque prestataire peut ainsi publier un ensemble cohérent avec ses capacités. La liaison évite d'associer l'adresse de l'un aux paramètres de l'autre, mais elle ne prouve toujours ni disponibilité ni conformité du déploiement.

Filtrer avant de préférer

Le client traite d'abord la validité. Un RR malformé peut faire rejeter tout le RRset et ramener à une connexion sans SVCB. Des paramètres reconnus mais contradictoires rendent un enregistrement incohérent. Une extension inconnue peut ordinairement être ignorée ; si elle figure dans mandatory, l'enregistrement devient incompatible.

Les survivants seulement sont classés. Les plus petites priorités passent en premier ; à priorité égale, un mélange aléatoire assure une répartition équilibrée. Il n'existe pas ici le poids réglable de SRV. Une priorité basse veut donc dire « essayer d'abord si compatible », jamais « obéir quelle que soit la réalité ».

mandatory n'ordonne rien au serveur. Il prévient le client que négliger une clé dénaturerait le plan. Toutes les clés citées doivent exister dans le même RR et mandatory ne peut se citer lui-même. Pour HTTPS, port et no-default-alpn deviennent automatiquement obligatoires lorsqu'ils sont présents : ignorer l'un enverrait vers le mauvais écouteur, ignorer l'autre réintroduirait un protocole que l'opérateur a précisément exclu.

Annonce et négociation ne sont pas le même fait

Le paramètre alpn annonce les suites de protocoles offertes par la destination. Il permet de préparer directement HTTP/3 sur QUIC ou HTTP/2 sur TLS, mais la négociation réelle reste dans la poignée de main. Une zone peut précéder la mise en production, un site peut être en retard ou UDP peut être bloqué.

L'enquête doit conserver l'ensemble ALPN obtenu par DNS et la valeur réellement négociée. De même, port propose un écouteur ; une politique client ou un pare-feu peut l'interdire. La publication atteste le contenu DNS observé. Le résultat de transport atteste une exécution à un endroit et à un instant.

ipv4hint et ipv6hint sont également des accélérateurs. Si les adresses A/AAAA de TargetName sont déjà disponibles, le client devrait ignorer les indications. Sinon il continue la résolution et devrait employer les réponses d'adresse pour les connexions futures. Une indication peut servir à démarrer, puis céder la place à une réponse géolocalisée différente.

Il faut donc enregistrer la provenance de l'adresse : hint signé, Answer, section Additional, cache ou résolution du proxy. Un simple journal « connexion vers telle IP » ne permet pas de distinguer course prévue, cache ancien, divergence de fournisseur et redirection hostile.

L'identité d'origine traverse le détour

RFC 9460 suppose que SVCB et HTTPS puissent arriver par un DNS non fiable. DNSSEC peut authentifier le RRset, mais reste facultatif. Même une réponse DNSSEC valide ne prouve ni la vie de la cible, ni le protocole actif, ni la correction de l'application.

La destination alternative doit s'authentifier pour le service d'origine. Un certificat valable uniquement pour TargetName ne suffit pas. Le client envoie le nom d'origine, vérifie ce nom et lui adresse la requête HTTP. DNS gouverne la découverte ; TLS gouverne l'identité du pair ; ALPN décrit l'accord de cette connexion ; HTTP porte l'autorité et la réponse applicative.

HTTP étant antérieur à SVCB, son usage est généralement optionnel. L'absence ordinaire peut mener au chemin classique. En revanche, l'échec d'une résolution SVCB protégée — erreur d'authentification, SERVFAIL, transport protégé rompu ou délai — devrait arrêter la tentative afin qu'un adversaire ne retire pas sélectivement les paramètres. Un échec DNS non authentifié peut relever d'une politique locale différente.

Dans un système multi-CDN, CNAME, HTTPS et A/AAAA peuvent observer des générations différentes. Le client doit résoudre les adresses du TargetName effectivement retenu. C'est la portée pratique de la primauté du code en fonctionnement : la déclaration commune n'a de pouvoir que dans la mesure où des implémentations compatibles l'exécutent, sans absorber l'autorité des contrôles TLS et applicatifs.

Sources