Résumé

  • Les RR SVCB et HTTPS associent un point d’accès à ses paramètres et permettent à l’éditeur de recommander un ordre. DNSSEC peut authentifier cette publication, sans prouver la compatibilité du client, la disponibilité de la route ni le succès TLS.
  • Le client demeure l’autorité d’exécution : il écarte les enregistrements incohérents, interprète les clés obligatoires, mélange les ex æquo, applique sa politique de proxy et d’adresses, tente, se replie et valide l’origine initiale.

Le cas le plus révélateur n’est pas une panne. C’est une réussite différente selon l’observateur. Un téléphone prend le point d’accès de priorité 1 en HTTP/3. Un poste d’entreprise ignore ce choix parce qu’une clé déclarée obligatoire lui est inconnue, puis utilise la priorité 2 en HTTP/2. Un troisième terminal, placé derrière un proxy qui résout lui-même les noms, désactive SVCB pour ne pas divulguer sa destination à un autre résolveur.

Les trois ont reçu le même RRset. Sa signature était valide. Pourtant, aucune signature ne pouvait transformer trois environnements en une seule connexion.

La norme RFC 9460 définit SVCB comme le type 64 et HTTPS comme le type 65 compatible avec SVCB. Son objectif est de fournir avant la connexion des informations qu’un client aurait autrement apprises trop tard : points d’accès alternatifs, protocoles, ports, indices d’adresse et paramètres extensibles.

La priorité zéro place un enregistrement en AliasMode. Elle délègue le service à un TargetName, notamment à l’apex où CNAME pose problème. Une priorité positive signifie ServiceMode : le TargetName et les SvcParams du même enregistrement forment un ensemble. Cette liaison évite de composer au hasard un port d’un fournisseur, une adresse d’un autre et un protocole d’un troisième.

AliasMode n’est cependant pas un CNAME universel. Il ne s’applique qu’au type SVCB-compatible interrogé, ne change pas les autres RR et n’emporte pas l’identité de l’origine. Les clients anciens peuvent encore dépendre de A et AAAA. Même l’alias correctement publié reste une voie réservée aux logiciels capables de le suivre.

ServiceMode révèle mieux encore la répartition des pouvoirs. L’éditeur propose des ensembles cohérents. Le client élimine d’abord les données malformées ou contradictoires. Il peut ignorer une clé inconnue, sauf si mandatory indique que le point d’accès ne fonctionnerait pas correctement sans elle. Un enregistrement dont une clé obligatoire est incomprise devient incompatible ; ce n’est pas une invitation à deviner.

Le registre IANA des paramètres SVCB, mis à jour le 25 juin 2026, contient les clés initiales — mandatory, ALPN, suppression de l’ALPN par défaut, port, indices IPv4 et IPv6 — ainsi que des extensions pour ECH, le chemin DoH, OHTTP, les groupes TLS, DNS over CoAP, PvD et un indicateur de confiance de transport. Un numéro enregistré stabilise une signification. Il n’annonce ni l’adoption générale ni la pertinence de cette clé pour tout protocole.

La priorité n’est pas davantage un ordre distant. La valeur positive la plus faible est la préférence de l’éditeur. À priorité égale, RFC 9460 demande un mélange aléatoire afin de répartir la charge ; il n’existe pas de poids à la manière de SRV. Le client essaie normalement les priorités supérieures, puis les suivantes, mais il peut lancer plusieurs essais, précharger plusieurs noms ou conserver une connexion déjà engagée et compatible.

Il peut même privilégier un enregistrement immédiatement exploitable lorsque l’autre exige une requête DNS supplémentaire. Ainsi, un relevé de zone ne permet pas de prédire à lui seul le premier paquet utile. La priorité encadre le choix ; elle n’abolit ni l’état du client ni la latence du réseau.

ALPN matérialise cette différence. Le paramètre annonce les suites proposées par un point d’accès. Le client conserve celles qu’il prend en charge, puis RFC 7301 régit la négociation dans TLS. Voir h3 dans DNS ne prouve pas que QUIC est actif dans ce navigateur, que l’UDP traverse le réseau ou que le serveur acceptera la négociation.

Les indices d’adresse portent bien leur nom. ipv4hint et ipv6hint peuvent accélérer un premier essai, mais RFC 9460 demande de préférer les réponses A et AAAA disponibles. Le client peut interrompre une connexion fondée sur un indice lorsque les vraies adresses arrivent, faute de quoi il risque de contourner la répartition géographique. Il peut ensuite appliquer Happy Eyeballs v2 pour mettre en concurrence IPv6 et IPv4. L’adresse gagnante est un résultat observé, non un décret du RR.

DNSSEC répond à une autre question. HTTPS n’est pas authentifié par nature : RFC 9460 considère le canal DNS comme potentiellement hostile et rend DNSSEC facultatif. Lorsqu’un client protège A et AAAA par validation, il devrait appliquer la même politique à SVCB. RFC 4035 permet alors d’attribuer un RRset Secure à la zone signée.

Cette attribution ne teste ni la santé du serveur ni son certificat. Elle prouve ce que la zone a publié, pas ce que le client réussira. Confondre ces deux preuves reviendrait à demander à une signature DNS de répondre à une question de chemin et de protocole qu’elle n’a jamais observée.

L’identité du service reste volontairement stable. Le TargetName ne devient pas l’origine HTTPS. SNI, Host et :authority continuent de désigner l’origine demandée. RFC 9525 précise que l’utilisation de SVCB ou HTTPS ne modifie pas les exigences PKIX existantes pour HTTP ou DNS over TLS. Un CDN peut recevoir la connexion ; il doit toujours présenter une identité valable pour le service initial.

La comparaison avec Alt-Svc confirme ce principe. Alt-Svc change éventuellement l’hôte, le port et le protocole de transport sans remplacer l’origine. Le client choisit selon ses propres critères de sécurité. HTTPS RR apporte une information comparable avant la première réponse HTTP, avec un TTL DNS plutôt que le paramètre ma. La sémantique de l’origine décrite par RFC 9110 demeure la référence au-dessus de ces routes.

Le repli protège la disponibilité et crée un risque. Pour un protocole préexistant tel que HTTP, SVCB est normalement facultatif. Après l’échec des points d’accès compatibles, un client peut revenir au mode classique. Mais si la première option offrait ECH ou une propriété plus forte, un adversaire qui la rend indisponible peut provoquer une connexion moins protectrice. La norme Alt-Svc relève le même danger : le repli ne doit pas être traité comme une opération neutre.

Le proxy ajoute sa propre géographie. S’il reçoit un nom et choisit lui-même A ou AAAA, une résolution SVCB séparée côté client peut exposer la destination à un tiers. RFC 9460 impose alors au client facultatif de désactiver SVCB si aucun mécanisme privé adapté n’existe. Quand le mécanisme est utilisé, la compatibilité doit inclure le proxy et les adresses reflètent son emplacement, non forcément celui du terminal.

L’exemple non HTTP de RFC 9461 applique SVCB à DoT, DoH et DoQ. Il démontre qu’un format commun a toujours besoin d’une interprétation propre au protocole. Chaque mapping précise les clés sûres et le comportement de repli ; le registre générique ne suffit pas.

Les distinctions de Heng Lu entre code en fonctionnement, spécification commune minimale et décision future localisée et couches de réalité offrent ici une discipline d’audit. La norme décrit. La zone recommande. Le résolveur transmet. Le client filtre. TLS négocie. L’application établit enfin ce qui a été réellement servi.

L’enquête ne doit donc pas s’arrêter à la réponse DNS. Elle relie le RRset et son état DNSSEC à la version du client, aux clés comprises, au proxy, à l’enregistrement choisi, aux adresses tentées, à ALPN, au certificat, au motif de repli et à la réponse applicative. La publication est un fait. La connexion en est un autre.