Der unterschätzte HTTPS-DNS-Eintrag: Das fehlende Puzzlestück für deine Website
Das HTTP/3-Entdeckungsproblem, über das niemand spricht
Stell dir folgendes Szenario vor, das sich gerade auf Millionen von Webseiten abspielt: Ein Besucher gibt deine Domain in seinen Browser ein. Der Browser löst den DNS-Eintrag auf, öffnet eine TCP-Verbindung, führt den TLS-Handshake durch, sendet eine HTTP-Anfrage... und erfährt erst dann: „Hey, ich unterstütze auch HTTP/3!" Das Protokoll, das alles beschleunigen sollte? Es kommt schlicht zu spät.
Das ist keine Browser-Einschränkung – es ist eine grundlegende architektonische Schwachstelle. Die traditionelle Methode, HTTP/3-Unterstützung bekanntzugeben, ist der Alt-Svc HTTP-Header. Dieser erreicht Clients aber erst, nachdem sie bereits eine Verbindung aufgebaut haben. Bis dahin hast du dich längst auf HTTP/1.1 oder HTTP/2 festgelegt.
Das HTTPS DNS-Record als Lösung (RFC 9460)
Hier wird es spannend. Der HTTPS Resource Record, standardisiert im November 2023, ermöglicht etwas Bemerkenswertes: Du kannst HTTP/3-Unterstützung bevor der Browser überhaupt eine Verbindung öffnet, bekanntgeben.
Wenn ein Client eine DNS-Auflösung durchführt – die er ohnehin vornehmen muss – erfährt er gleichzeitig:
- Welche ALPN-Protokolle du unterstützt (h3, h2, http/1.1)
- Deine ECH-Public-Keys (Encrypted Client Hello)
- IP-Hinweise für sofortigen Verbindungsaufbau
Das bedeutet: Die erste Verbindung zu deiner Seite kann sofort QUIC und HTTP/3 nutzen. Kein verschwendeter Handshake. Keine zusätzliche Runde, nur um ein Protokoll zu entdecken, das du von Anfang an hättest nutzen können.
Warum das wichtiger ist, als du denkst
Denk an jeden Erstbesucher deiner Seite. Er hat keine gecachte Verbindung. Er hat aus früheren Besuchen nichts über deine HTTP/3-Unterstützung gelernt. Er startet bei Null – und mit dem alten Alt-Svc-Ansatz zahlt er einen Latenzpreis allein für die Protokoll-Erkennung.
Mit einem HTTPS Record passiert diese Erkennung während des DNS-Lookups, den er sowieso durchführt. Die Protokollverhandlung findet vor dem Verbindungsaufbau statt, nicht danach.
Aber da ist noch mehr: Encrypted Client Hello
Der HTTPS Record löst noch ein weiteres kritisches Problem, das HTTP-Header schlicht nicht anfassen können. Encrypted Client Hello (ECH) verschlüsselt den gesamten TLS ClientHello – einschließlich des SNI-Servernamens. Das verhindert, dass Netzwerkbeobachter sehen, welche Seite du besuchst.
Hier liegt der Haken: Du brauchst den ECH Public Key, bevor du den ersten ClientHello sendest. Aber es gibt noch keine Verbindung, über die du diesen Schlüssel empfangen könntest. Ein klassisches Henne-Ei-Problem, das nur ein Out-of-Band-Kanal lösen kann – und genau so ein Kanal ist der HTTPS DNS Record.
HTTP-Header werden niemals ECH ausliefern können. DNS hingegen schon.
Deinen HTTPS Record veröffentlichen
Neugierig, wie das aussieht? Hier ein vollständiger ServiceMode HTTPS Record:
example.com. 3600 IN HTTPS 1 . alpn="h3,h2" ipv4hint=203.0.113.10 ipv6hint=2001:db8::10
Schauen wir uns das im Detail an:
example.com.– Deine Domain (vollqualifiziert mit dem abschließenden Punkt)3600– TTL in Sekunden (wie lange Resolver diesen Eintrag cachen dürfen)HTTPS– Der Record-Typ1– Priorität 1 oder höher bedeutet ServiceMode (enthält Parameter).– Ziel-Host; ein Punkt bedeutet „nutze den Ownernamen selbst"alpn="h3,h2"– Unterstützte Protokolle, das beste zuerstipv4hint/ipv6hint– Adresshinweise für frühzeitigen Verbindungsaufbau
Bei NameOcean machen wir es dir zunehmend einfach, diese Records zusammen mit deiner übrigen DNS-Konfiguration zu verwalten. Es ist ein weiteres Signal dafür, dass wir genau beobachten, wohin sich die Web-Performance entwickelt.
Was ist mit älteren Clients?
Ein HTTPS Record zu veröffentlichen ist rein additiv. Clients, die ihn nicht verstehen, ignorieren ihn einfach und greifen auf gewöhnliche A/AAAA-Lookups zurück. Sie verpassen zwar die HTTP/3-Optimierung, aber nichts geht kaputt.
Das bedeutet: Du kannst deinen HTTPS Record heute bedenkenlos veröffentlichen. Es handelt sich um eine progressive Verbesserung – moderne Browser lesen ihn, ältere bemerken ihn nicht einmal.
Solltest du deinen Alt-Svc Header entfernen?
Nein. Behalt ihn bei.
Sieh den Alt-Svc Header als Fallback für alles, das deinen HTTPS Record nicht empfängt: Legacy-Browser, bestimmte Resolver-Konfigurationen oder Netzwerke, die DNS-Antworten filtern. Mit beiden an Bord bist du von allen Seiten abgesichert:
- Moderne Browser + HTTPS-fähige Resolver → Entdecken HTTP/3 über DNS, verbinden sich sofort mit QUIC
- Ältere Clients oder gefiltertes DNS → Fallback auf Alt-Svc Header nach der initialen Verbindung
- Folgebesuche → Noch besser; HTTP/3-Verbindungen können mit 0-RTT fortgesetzt werden, sodass die erste Anfrage ohne jeden Handshake auf die Reise geht
Das Fazit
Der HTTPS DNS Record ist eine jener seltenen Optimierungen, die nahezu nichts kosten, aber für jeden neuen Besucher deiner Seite die Verbindungsperformance spürbar verbessern können. Eine kleine Konfigurationsänderung, die die HTTP/3-Erkennung genau dorthin bringt, wo sie hingehört: vor das erste gesendete Byte, nicht danach.
Wenn du einen CDN betreibst, prüfe, ob dieser den Record bereits für dich veröffentlicht – Cloudflare tut das für proxy-zones automatisch. Wenn du deinen eigenen DNS verwaltest, ist das Hinzufügen eines HTTPS Records eine Viertelstunden-Aufgabe, die deine Besucher bei jeder kalten Verbindung zu schätzen wissen.
Das Web bewegt sich in Richtung HTTP/3. Stell sicher, dass dein DNS mit dabei ist.