HTTP/3-problemet, ingen diskuterer

Forestil dig følgende situation på millioner af hjemmesider: En bruger indtaster dit domæne i browseren. Browseren slår DNS'en op, åbner en TCP-forbindelse, fuldfører et TLS-handshake, sender en HTTP-forespørgsel... og FØRST der opdager den "ej, jeg kan faktisk bruge HTTP/3!"

Det ironiske? Præcis den protokol, der kunne have gjort det hele hurtigere, kommer for sent.

Problemet sidder ikke i browseren. Det er en grundlæggende begrænsning i arkitekturen. Den traditionelle måde at fortælle om HTTP/3-support på er via Alt-Svc HTTP-headeren. Men den kan kun nå klienter EFTER, at de allerede har etableret en forbindelse. På det tidspunkt har du allerede commitet til HTTP/1.1 eller HTTP/2.

HTTPS DNS-recorden (RFC 9460)

Her bliver det interessant. HTTPS resource record, standardiseret i november 2023, gør noget genialt: Den lader dig fortælle om HTTP/3-support FØR, browseren overhovedet åbner en forbindelse.

Når en klient foretager DNS-opslag — noget den alligevel skal gøre — kan den samtidig få at vide:

• Hvilke ALPN-protokoller du understøtter (h3, h2, http/1.1)
• Dine ECH (Encrypted Client Hello) offentlige nøgler
• IP-hints, så den kan begynde at forbinde med det samme

Det betyder, at selve den første forbindelse til din side kan bruge QUIC og HTTP/3. Ingen spildt handshake. Ingen ekstratur bare for at finde ud af, hvilken protokol du kunne have brugt fra start.

Hvorfor det betyder mere, end du tror

Tænk på alle førstegangsbesøgende på din side. De har ingen cachede forbindelser. De har ikke lært om din HTTP/3-support fra tidligere besøg. De starter fra scratch — og med den gamle Alt-Svc-metode betaler de en latens-straf bare for at finde ud af, hvad du understøtter.

Med en HTTPS-record sker denne opdagelse under selve DNS-opslaget. Protokolforhandlingen foregår FØR, du etablerer en forbindelse — ikke bagefter.

Men vent, der er mere: Encrypted Client Hello

HTTPS-recorden løser også et kritisk problem, som HTTP-headere simpelt hen ikke kan røre. Encrypted Client Hello (ECH) krypterer selve TLS ClientHello'en — inklusive SNI-servernavnet. Det forhindrer netværks-overvågere i at se, hvilken specifik side du besøger.

Her er haken: Du skal bruge ECH-offentlig nøgle FØR, du sender den første ClientHello. Men der er ingen forbindelse endnu til at modtage den nøgle gennem. Det er et høne-og-æg-problem, som kun en out-of-band kanal kan løse — og HTTPS DNS-recorden ER den kanal.

HTTP-headere vil aldrig kunne levere ECH. DNS kan.

Sådan publicerer du din HTTPS-record

Nysgerrig efter at se, hvordan det ser ud? Her er et komplet ServiceMode HTTPS-record:

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

Lad os bryde det ned:

• example.com. — Dit domæne (fuldt kvalificeret med punktummet til sidst)
• 3600 — TTL i sekunder (hvor længe resolvers må cache dette)
• HTTPS — Record-typen
• 1 — Prioritet 1 eller højere betyder ServiceMode (bærer parametre)
• . — Mål-værtsnavn; et punktum betyder "brug ejer-navnet selv"
• alpn="h3,h2" — Understøttede protokoller, bedste først
• ipv4hint / ipv6hint — Adresse-hints til tidlig forbindelsesstart

Hos NameOcean gør vi det stadig nemmere at håndtere den slags records sammen med din øvrige DNS-konfiguration. Det er endnu et signal på, at vi følger med, hvor webperformance er på vej hen.

Hvad med gamle klienter?

At publicere en HTTPS-record er udelukkende tilføjende. Klienter, der ikke forstår den, ignorerer den bare og falder tilbage til almindelige A/AAAA-lookups. De går glip af HTTP/3-optimering, men der sker intet galt.

Så du kan roligt publicere din HTTPS-record i dag uden at bekymre dig om kompatibilitet. Det er en progressiv forbedring — moderne browsere læser den, ældre lægger ikke mærke til den.

Skal du fjerne din Alt-Svc-header?

Nej. Bliv ved med at sende den.

Tænk på Alt-Svc-headeren som en fallback for alt, der ikke modtager din HTTPS-record: ældre browsere, visse resolver-konfigurationer eller netværk, der filtrerer DNS-svar. Med begge på plads er du dækket fra alle vinkler:

• Moderne browsere + HTTPS-bevidste resolvers → Opdager HTTP/3 fra DNS, forbinder med det samme via QUIC
• Ældre klienter eller filtreret DNS → Falder tilbage til Alt-Svc-header efter indledende forbindelse
• Efterfølgende besøg → Endnu bedre; HTTP/3-forbindelser kan genoptages med 0-RTT, så første request sendes uden handshake overhovedet

Konklusionen

HTTPS DNS-recorden er en af de sjældne optimeringer, der næsten intet koster at implementere — men som kan forbedre connection-performancen markant for enhver ny besøgende på din side. Det er en lille konfigurationsændring, der placerer HTTP/3-opdagelsen præcis, hvor den hører hjemme: før den første byte sendes, ikke efter.

Hvis du kører en CDN, så tjek om de allerede publicerer dette for dig — Cloudflare gør det automatisk for proxied zones. Hvis du administrerer din egen DNS, er det en kvarters opgave at tilføje en HTTPS-record, som dine besøgende vil sætte pris på ved hver kold forbindelse.

Nettet bevæger sig mod HTTP/3. Sørg for, at din DNS er med på rejsen.

Parat til at optimere din DNS-konfiguration? Hos NameOcean leverer vi værktøjerne og vejledningen til at holde din infrastruktur på forkant. Dine besøgendes første forbindelser behøver ikke at vente.