Het HTTP/3-ontdekkingsprobleem waar niemand het over heeft

Stel je dit eens voor: een bezoeker typt je domein in de browser. De browser lost de DNS op, opent een TCP-verbinding, doet een TLS-handshake, stuurt een HTTP-verzoek... en dan pas krijgt hij te horen: "hé, ik ondersteun ook HTTP/3!" Het protocol dat alles sneller had gemaakt? Het arriveert te laat.

Dit is geen browserbeperking—het zit diep in de architectuur. De traditionele manier om HTTP/3-ondersteuning bekend te maken is via de Alt-Svc HTTP-header. Maar die kan clients pas bereiken nadat ze al een verbinding hebben opgezet. Tegen die tijd heb je je al vastgelegd op HTTP/1.1 of HTTP/2.

De HTTPS DNS-record (RFC 9460) lost het op

En hier wordt het spannend. De HTTPS resource record, gestandaardiseerd in november 2023, doet iets bijzonders: je kunt er HTTP/3-ondersteuning mee aankondigen voordat de browser ook maar iets opent.

Wanneer een client DNS-lookup uitvoert—iets wat hij toch al zou doen—kan hij tegelijk te weten komen:

• Welke ALPN-protocollen je ondersteunt (h3, h2, http/1.1)
• Je ECH (Encrypted Client Hello) publieke sleutels
• IP-adreshints om direct te beginnen met verbinden

Dit betekent dat de allereerste verbinding naar je site QUIC en HTTP/3 kan gebruiken. Geen verspilde handshake. Geen round trip om een protocol te ontdekken dat je vanaf het begin had kunnen gebruiken.

Waarom dit belangrijker is dan je denkt

Denk aan elke nieuwe bezoeker van je site. Die heeft geen gecachte verbinding. Die heeft niets geleerd over je HTTP/3-ondersteuning van eerdere bezoeken. Hij begint helemaal opnieuw, en met de oude Alt-Svc-aanpak betaalt hij een latency-boete om te ontdekken wat je ondersteunt.

Met een HTTPS record gebeurt die ontdekking tijdens de DNS-lookup die toch al plaatsvindt. De protocolonderhandeling gebeurt vóór de verbinding, niet erna.

Maar er is meer: Encrypted Client Hello

De HTTPS record lost nog een kritiek probleem op waar HTTP-headers simpelweg niet bij kunnen. Encrypted Client Hello (ECH) versleutelt de TLS ClientHello zelf, inclusief de SNI-servernaam. Dit voorkomt dat netwerktoeschouwers kunnen zien naar welke specifieke site je gaat.

Hier is het addertje: je hebt de ECH publieke sleutel nodig voordat je de eerste ClientHello stuurt. Maar er is nog geen verbinding om die sleutel door te ontvangen. Dit is een kip-en-ei-probleem dat alleen een out-of-band kanaal kan oplossen—en de HTTPS DNS record is dat kanaal.

HTTP-headers zullen nooit ECH kunnen leveren. DNS wel.

Je HTTPS record publiceren

Nieuwsgierig hoe dat eruitziet? Hier is een compleet ServiceMode HTTPS record:

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

En wat het betekent:

• example.com. — Je domein (volledig gekwalificeerd met de punt)
• 3600 — TTL in seconden (hoe lang resolvers dit mogen cachen)
• HTTPS — Het recordtype
• 1 — Prioriteit 1 of hoger betekent ServiceMode (draagt parameters)
• . — Doelhost; een punt betekent "gebruik de ownernaam zelf"
• alpn="h3,h2" — Ondersteunde protocollen, beste eerst
• ipv4hint / ipv6hint — Adreshints voor vroege verbindingsstart

Bij NameOcean zorgen we ervoor dat je dit soort records makkelijk kunt beheren, naast je andere DNS-configuratie. Het is nog een signaal dat we scherp zijn op waar webprestaties naartoe gaan.

En oudere clients?

Een HTTPS record publiceren is puur additief. Clients die het niet begrijpen, negeren het simpelweg en vallen terug op gewone A/AAAA-lookups. Ze missen misschien de HTTP/3-optimalisatie, maar er gaat niets kapot.

Dit betekent dat je vandaag je HTTPS record kunt publiceren zonder je zorgen te maken over compatibiliteit. Het is een progressieve verbetering—moderne browsers lezen het, oudere merken het niet eens.

Moet je je Alt-Svc header verwijderen?

Nee. Blijf hem sturen.

Denk aan de Alt-Svc header als fallback voor alles wat je HTTPS record niet ontvangt: oudere browsers, bepaalde resolver-configuraties, of netwerken die DNS-responsen filteren. Met beide op hun plek ben je van alle kanten gedekt:

• Moderne browsers + HTTPS-bewuste resolvers → Ontdekken HTTP/3 via DNS, maken direct verbinding met QUIC
• Oudere clients of gefilterde DNS → Vallen terug op Alt-Svc header na initiële verbinding
• Vervolgbezoeken → Nog beter; HTTP/3-verbindingen kunnen hervatten met 0-RTT, waarbij het eerste verzoek op de lijn gaat zonder handshake

De conclusie

De HTTPS DNS record is een van die zeldzame optimalisaties die bijna niets kosten om te implementeren, maar de verbindingsprestaties voor elke nieuwe bezoeker van je site merkbaar kunnen verbeteren. Het is een kleine configuratiewijziging die HTTP/3-ontdekking precies daar neerzet waar het hoort: vóór de eerste byte wordt verzonden, niet erna.

Als je een CDN draait, check dan of die dit al voor je publiceert—Cloudflare doet dit automatisch voor geproxyde zones. Als je je eigen DNS beheert, is een HTTPS record toevoegen een kwartier taak waar je bezoekers op elke koude verbinding profijt van hebben.

Het web beweegt naar HTTP/3. Zorg ervoor dat je DNS meegaat.

Wil je je DNS-configuratie optimaliseren? Bij NameOcean bieden we de tools en begeleiding om je infrastructuur aan de frontier te houden. De eerste verbindingen van je bezoekers hoeven niet te wachten.