Le problème de découverte HTTP/3 dont personne ne parle

Voici ce qui se passe sur des millions de sites en ce moment : un visiteur tape votre domaine dans son navigateur. Le navigateur résout le DNS, ouvre une connexion TCP, termine le handshake TLS, envoie une requête HTTP... et c'est seulement à ce moment-là qu'il apprend « au fait, je supporte aussi HTTP/3 ! » Le protocole qui aurait tout accéléré ? Il arrive trop tard.

Ce n'est pas une limitation des navigateurs. C'est une contrainte architecturale fondamentale. La méthode traditionnelle pour annoncer le support HTTP/3 passe par le header HTTP Alt-Svc, qui ne peut atteindre les clients qu'après l'établissement de la connexion. À ce stade, vous êtes déjà engagé avec HTTP/1.1 ou HTTP/2.

Le record DNS HTTPS (RFC 9460)

Les choses deviennent intéressantes ici. Le record HTTPS, normalisé en novembre 2023, fait quelque chose de remarquable : il vous permet d'annoncer le support HTTP/3 avant que le navigateur n'ouvre la moindre connexion.

Quand un client effectue une résolution DNS — qu'il allait faire de toute façon — il peut apprendre en même temps :

• Quels protocoles ALPN vous supportez (h3, h2, http/1.1)
• Vos clés publiques ECH (Encrypted Client Hello)
• Des indices d'adresses IP pour commencer à se connecter immédiatement

Cela signifie que la toute première connexion à votre site peut utiliser QUIC et HTTP/3. Pas de handshake gaspillé. Pas de round trip perdu à découvrir un protocole que vous auriez pu utiliser dès le départ.

Pourquoi c'est plus important qu'on ne le pense

Pensez à chaque nouveau visiteur de votre site. Il n'a pas de connexion en cache. Il n'a pas appris votre support HTTP/3 lors de visites précédentes. Il part de zéro, et avec l'ancienne méthode Alt-Svc, il paie une pénalité de latence juste pour découvrir ce que vous supportez.

Avec un record HTTPS, cette découverte se fait pendant la requête DNS qu'il effectue de toute façon. La négociation du protocole a lieu avant l'établissement de la connexion, pas après.

Mais attendez, il y a mieux : Encrypted Client Hello

Le record HTTPS résout un autre problème critique que les headers HTTP ne peuvent absolument pas toucher. Encrypted Client Hello (ECH) chiffre le ClientHello TLS lui-même, y compris le nom de serveur SNI. Cela empêche les observateurs réseau de voir quel site spécifique vous consultez.

Voilà le hic : vous avez besoin de la clé publique ECH avant d'envoyer le premier ClientHello. Mais il n'y a pas encore de connexion pour recevoir cette clé. C'est un problème de l'œuf et de la poule que seul un canal hors-bande peut résoudre — et le record DNS HTTPS est ce canal.

Les headers HTTP ne pourront jamais livrer ECH. Le DNS le peut.

Publier votre record HTTPS

Curieux de voir à quoi ça ressemble ? Voici un record HTTPS complet en ServiceMode :

example.com.  3600  IN  HTTPS  1  .  alpn="h3,h2"  ipv4hint=203.0.113.10  ipv6hint=2001:db8::10

Décomposons :

• example.com. — Votre domaine (qualifié avec le point final)
• 3600 — TTL en secondes (durée de cache par les resolvers)
• HTTPS — Le type d'enregistrement
• 1 — Une priorité de 1 ou plus signifie ServiceMode (porte des paramètres)
• . — Hôte cible ; un point signifie « utiliser le nom lui-même »
• alpn="h3,h2" — Protocoles supportés, le meilleur en premier
• ipv4hint / ipv6hint — Indices d'adresses pour un démarrage précoce de la connexion

Chez NameOcean, nous facilitons de plus en plus la gestion de ces enregistrements aux côtés de votre configuration DNS. C'est un signal supplémentaire que nous surveillons où va la performance web.

Et les anciens clients ?

Publier un record HTTPS est strictement additif. Les clients qui ne le comprennent pas l'ignorent simplement et reviennent aux requêtes A/AAAA ordinaires. Ils pourraient manquer l'optimisation HTTP/3, mais rien ne casse.

Cela signifie que vous pouvez publier votre record HTTPS aujourd'hui sans vous soucier de la compatibilité. C'est une amélioration progressive — les navigateurs modernes le lisent, les anciens ne le remarquent même pas.

Devriez-vous supprimer votre header Alt-Svc ?

Non. Continuez à l'envoyer.

Considérez le header Alt-Svc comme un fallback pour tout ce qui ne reçoit pas votre record HTTPS : navigateurs anciens, certaines configurations de resolvers, ou réseaux qui filtrent les réponses DNS. Avec les deux en place, vous êtes couvert de tous les côtés :

• Navigateurs modernes + resolvers compatibles HTTPS → Découvrent HTTP/3 depuis le DNS, se connectent immédiatement avec QUIC
• Clients anciens ou DNS filtré → Retombent sur le header Alt-Svc après la connexion initiale
• Visites suivantes → Encore mieux ; les connexions HTTP/3 peuvent reprendre avec 0-RTT, mettant la première requête sur le fil sans handshake du tout

Le mot de la fin

Le record DNS HTTPS est l'une de ces optimisations rares qui coûtent presque rien à implémenter mais qui peuvent améliorer significativement la performance de connexion pour chaque nouveau visiteur de votre site. C'est un petit changement de configuration qui place la découverte HTTP/3 exactement là où elle doit être : avant le premier octet envoyé, pas après.

Si vous utilisez un CDN, vérifiez s'ils publient déjà ceci pour vous — Cloudflare le fait automatiquement pour les zones proxées. Si vous gérez votre propre DNS, ajouter un record HTTPS est une tâche de quinze minutes que vos visiteurs apprécieront à chaque nouvelle connexion.

Le web se dirige vers HTTP/3. Assurez-vous que votre DNS est du voyage.

Prêt à optimiser votre configuration DNS ? Chez NameOcean, nous fournissons les outils et les conseils pour garder votre infrastructure à la pointe. Les premières connexions de vos visiteurs n'ont pas à attendre.