Résumé

  • Un enregistrement DNS HTTPS publie des instructions de connexion ; il n’exécute aucun test.
  • Le choix dépend de la priorité, des paramètres compris, de la résolution et des capacités du client.
  • Les indications d’adresse, l’annonce ALPN et la réussite d’un repli constituent des preuves distinctes.
  • L’aptitude opérationnelle demande un journal de validation technique reliant le RRset observé à une réponse applicative authentifiée pour chaque groupe de clients important.

Imaginons un tableau de déploiement qui passe au vert dès qu’un nouvel enregistrement HTTPS apparaît dans le DNS. Il annonce HTTP/3 et fournit une indication d’adresse IPv6. Une sonde de navigateur classique charge encore la page : le déploiement est déclaré terminé. Pourtant, toutes les tentatives HTTP/3 d’un groupe d’accès mobile échouent. Ces utilisateurs n’atteignent le service que grâce au repli vers HTTP/2 sur le point d’accès initial.

L’enregistrement n’est pas faux. C’est l’assimilation de sa publication à la livraison qui l’est.

Le RFC 9460 définit les enregistrements SVCB et HTTPS afin qu’un client connaisse des points d’accès alternatifs et leurs paramètres avant d’ouvrir la connexion habituelle. Le mécanisme peut réduire la latence, permettre un accès direct en HTTP/3, annoncer un port non standard et regrouper des paramètres cohérents. Il décrit le plan de contrôle ; il ne réalise pas une transaction synthétique.

La structure du RR est décisive. Une valeur SvcPriority égale à zéro désigne AliasMode, c’est-à-dire une délégation vers un autre nom. Une valeur non nulle désigne ServiceMode, qui associe un TargetName à des paramètres. Les valeurs faibles sont préférées, mais les entrées de même priorité sont mélangées aléatoirement. Le seul constat « HTTPS RR présent » ne conserve donc ni le choix disponible pour le client, ni la cible retenue, ni sa justification.

La compatibilité ajoute une frontière. Le paramètre mandatory indique les clés que le client doit comprendre. S’il en ignore une, l’entrée n’est pas utilisable pour lui. alpn annonce les protocoles applicatifs, tandis que no-default-alpn peut supprimer le protocole normalement implicite. Un RRset parfaitement formé peut ainsi produire des choix différents selon le navigateur, le système, la bibliothèque ou la politique d’un appareil géré.

Les valeurs ipv4hint et ipv6hint sont souvent surinterprétées. Elles autorisent une anticipation. Selon RFC 9460, le client devrait privilégier les enregistrements A ou AAAA déjà disponibles ; sinon, il devrait interroger le TargetName et utiliser ensuite les adresses obtenues. Une indication ne certifie ni la route, ni le passage de l’UDP, ni le comportement du pare-feu ou du NAT, ni l’écoute effective du protocole. Elle suggère un essai ; elle ne prouve pas l’acheminement des paquets.

Le périmètre d’authentification TLS ne change pas. Une délégation SVCB ne modifie pas l’origine à authentifier : le certificat reste vérifié pour le nom de service initial. Une réponse DNS peut donc être correcte et comprise, tandis que la validation du certificat, le SNI ou la poignée de main échoue sur la cible annoncée.

Pour HTTP/3, le RFC 9114 place le protocole applicatif au-dessus de QUIC, défini par le RFC 9000. Après le DNS viennent encore l’établissement QUIC, l’authentification TLS, les paramètres HTTP/3 et la réponse applicative. Chacune de ces transitions peut échouer. Les réduire à un voyant « HTTP/3 activé » fait disparaître la preuve qui localiserait la panne.

Le repli masque facilement cette perte. RFC 9460 prévoit que le client puisse rejeter un ensemble mal formé ou incompatible et revenir à une connexion sans SVCB. La requête visible par l’utilisateur peut donc réussir alors que la cible alternative n’a jamais été tentée, ou a échoué. C’est une protection de disponibilité, pas une preuve de validation opérationnelle.

À l’inverse, un échec unique ne condamne pas l’enregistrement. Le client peut ne pas gérer l’ALPN, voir une réponse propre à son résolveur, choisir une autre cible de même priorité, passer par un proxy, subir un blocage UDP local ou conserver des données DNS anciennes. L’aptitude opérationnelle est une affirmation par cohorte, pas une propriété universelle déduite d’un appareil.

Le journal de validation du point d’accès doit commencer par le nom demandé, le résolveur, le réseau, la version du client, le lieu d’observation et l’heure. Il conserve le RRset HTTPS complet, le résultat de validation DNS, le TTL et l’âge du cache ; la priorité et la cible choisies ; les paramètres compris ; les adresses résolues ou suggérées ; et la raison pour laquelle chaque entrée a été retenue, ignorée ou rejetée.

Il suit ensuite l’exécution : adresse, protocole et port tentés ; résultat QUIC ou TCP ; ALPN négocié ; nom du certificat et validation ; statut HTTP et empreinte de représentation ; repli éventuel. Il se termine par la cohorte, la durée, le résultat final et le composant autorisé à déclarer l’aptitude opérationnelle.

Le vocabulaire peut alors rester exact. « RR HTTPS observé » signifie qu’un résolveur a renvoyé l’ensemble. « Alternative choisie » signifie qu’un client a accepté une entrée ServiceMode. « HTTP/3 connecté » signifie que QUIC, TLS et HTTP/3 ont abouti. « Service livré » signifie que la transaction applicative attendue a réussi. Ces événements partagent une chronologie, sans que le premier fabrique les suivants.

Cette séparation aide le diagnostic. Une entrée ignorée appelle l’examen de la compatibilité et des clés obligatoires. Une adresse résolue suivie d’un échec QUIC pointe vers le chemin ou la politique de transport. Un échec TLS renvoie à l’autorité et au déploiement. Un succès obtenu seulement après repli préserve le service mais ne valide pas l’alternative.

Dans sa limite, l’enregistrement HTTPS est une preuve utile : il indique la liaison publiée et observée. L’aptitude opérationnelle commence lorsque le client identifié suit cette liaison et produit un résultat applicatif authentifié.

Sources

RFC 9460 — Enregistrements SVCB et HTTPS; RFC 9114 — HTTP/3; RFC 9000 — QUIC.