English
DeutschHTTPS-Einträge im DNS: Wie HTTP/3 entdeckt wird
Management Summary
DNS hilft dem Browser, Verbindungsinformationen zu einem Websitenamen zu finden. Ein HTTPS-Eintrag ergänzt Angaben, die HTTP/3 als neueres Übertragungsverfahren schon vor dem ersten Seitenabruf ankündigen können. Dadurch wird ein vorhandener Verbindungsweg früher erkennbar. Die Ankündigung schaltet den Dienst jedoch nicht selbst ein und verspricht keine schnelleren Seiten. Ob die Verbindung genutzt wird, hängt von Browser, Netz und Server ab; gespeicherte Angaben können spätere Änderungen verzögern.
Inhalt
HTTP/3 transportiert HTTP über QUIC und damit über UDP. Ein Client kann QUIC direkt versuchen, auch ohne vorherige Ankündigung. Ob dieser Versuch gelingt, hängt jedoch vom Endpunkt und vom Netzweg ab. Ein Fehlschlag kann schnell eintreten oder erst durch ein Zeitlimit auffallen.
Für die gezielte Auswahl helfen zwei Informationsquellen: Alt-Svc nennt einen alternativen Dienst in einer HTTP-Antwort; ein HTTPS-Eintrag im DNS kann die passenden Verbindungsparameter bereits vor dem ersten HTTP-Abruf liefern. Beide Verfahren kündigen Möglichkeiten an, garantieren aber keine erreichbare oder schnellere Verbindung.
Alt-Svc hilft auch innerhalb derselben Seitenansicht
Der Header Alt-Svc: h3=":443"; ma=86400 kündigt einen gleichwertigen HTTP/3-Dienst am selben Host auf UDP-Port 443 an. ma gibt die Gültigkeitsdauer für neue Verbindungsversuche in Sekunden an. Die Alternative ist optional; die Zertifikatsprüfung für den ursprünglichen Host bleibt erforderlich.
Ohne früheren Cache-Eintrag oder andere Information wird der Header häufig zunächst über HTTP/1.1 oder HTTP/2 empfangen. Nach dem Lesen kann ein unterstützender Client eine zusätzliche QUIC-Verbindung aufbauen. Dafür ist kein späterer Websitebesuch erforderlich: Auch weitere Ressourcen derselben Seite können bereits profitieren. Die ursprüngliche TCP-Verbindung muss dafür nicht erst geschlossen werden.
Was ein HTTPS-Eintrag ergänzt
Der DNS-Typ HTTPS hat die Nummer 65 und gehört zum SVCB-Verfahren. Für eine gewöhnliche HTTPS-Adresse auf Port 443 erfolgt die Abfrage unter dem Hostnamen. Ein ServiceMode-Eintrag beschreibt ein mögliches Verbindungsziel: Servername, Port und unterstützte Anwendungsprotokolle wie HTTP/3. Für diese Protokolle werden ALPN-Kennungen verwendet. AliasMode verweist dagegen auf einen weiteren Namen, dessen Einträge zusätzlich aufzulösen sind.
alpn="h3,h2" kündigt HTTP/3 und HTTP/2 an. Ein kompatibler Client kann damit schon den ersten HTTP-Abruf über QUIC versuchen. Auswahl, parallele Verbindungsversuche, Cache-Zustand und Netzbedingungen entscheiden über den tatsächlichen Ablauf. Ein DNS-Eintrag schaltet HTTP/3 am Server nicht ein.
ipv4hint und ipv6hint sind Adresshinweise für einen frühen Verbindungsversuch. Vorhandene A-/AAAA-Antworten haben Vorrang; andernfalls sollen entsprechende Abfragen weiterhin stattfinden. Die Hinweise ersetzen diese Auflösung deshalb nicht grundsätzlich.
Der Parameter ech kann eine ECH-Konfigurationsliste mit öffentlichem Schlüssel und weiteren Angaben transportieren. Bei unterstützenden Clients und Servern schützt ECH unter anderem den inneren TLS-Servernamen. Eine DNS-Ankündigung beweist noch keine erfolgreiche ECH-Verwendung. Unverschlüsselte DNS-Abfragen oder sichtbare Zieladressen können weiterhin Informationen verraten; die Konfiguration kann außerdem auf anderen Wegen bereitgestellt werden.
Historische Ergebnisse aus 20 Domains
Die gespeicherten Werkzeugergebnisse vom 5. September 2026 wurden bei der Überarbeitung erneut ausgewertet. Die folgende Tabelle beschreibt diesen damaligen Messlauf, keine aktuelle Anbietermessung und keinen repräsentativen Marktanteil.
| Historische Beobachtung | Domains |
|---|---|
| HTTPS-Eintrag vorhanden | 3 |
| HTTPS-Eintrag mit h3 | 2 |
| Alt-Svc mit h3 | 7 |
| Beide HTTP/3-Ankündigungen | 2 |
| Nur Alt-Svc mit h3 | 5 |
| Nur HTTPS-Eintrag mit h3 | 0 |
Die beiden Domains mit h3 im HTTPS-Eintrag hatten auch einen entsprechenden Alt-Svc-Header. Das galt nicht für jeden HTTPS-Eintrag: Der dritte Eintrag führte nur h2 auf und hatte keinen Alt-Svc-Header. Sieben gegenüber zwei ergibt Faktor 3,5 für die beobachteten HTTP/3-Ankündigungen; sieben gegenüber allen drei HTTPS-Einträgen wäre dagegen nur rund 2,3.
Bei fünf Alt-Svc-Ankündigungen betrug ma 86.400 Sekunden, bei zwei 2.592.000 Sekunden. In den ausgewerteten DNS-Ergebnissen war kein ech-Parameter erkannt worden. Das ist keine Messung ausgehandelter ECH-Verbindungen; die Grenzen der damaligen DNS-Auswertung sind zusätzlich zu beachten.
Keine Ursache aus einem einzelnen Fehler ableiten
Der h2-only-Eintrag gehörte im historischen Datensatz zu stackoverflow.com. Der erzwungene HTTP/3-Test endete nach 63 Millisekunden mit „QUIC connection has been shut down“. Daraus folgt keine allgemeine Aussage über sämtliche Endpunkte oder die bewusste Absicht des Betreibers. Ein gültiger HTTPS-Eintrag ohne h3 ist für sich genommen aber kein Konfigurationsfehler.
Bei zwei angekündigten Angeboten trat ein Zeitlimit auf, während andere HTTP/3-Verbindungen im selben Lauf gelangen. Das belegt die grundsätzliche QUIC-Fähigkeit des Messaufbaus, erklärt aber nicht jeden Fehler. Bei google.com waren sogar Verbindungs- und TLS-Zeiten aufgezeichnet, bevor der Abruf ohne empfangene Antwort auslief. Nicht jedes Zeitlimit bedeutet daher eine blockierte UDP-Verbindung.
Aussagekräftige Fehlerberichte nennen URL, getesteten Endpunkt, IP-Familie, Client-Version, Messzeit und Standort. Ein fehlgeschlagener Versuch von einem Messpunkt beweist keinen weltweiten Ausfall.
TTL und ma sind unterschiedliche Cache-Regeln
Die TTL begrenzt, wie lange eine DNS-Antwort normalerweise aus einem Zwischenspeicher wiederverwendet werden darf. Die rekursiven DNS-Antworten enthielten bei den beiden h3-Einträgen TTL-Werte von 20 und 21.474 Sekunden. Solche Werte können die verbleibende Cache-Zeit zeigen. Daraus lässt sich die ursprünglich konfigurierte TTL nicht sicher ableiten – ebenso wenig eine bewusste Entscheidung für maximale Beweglichkeit oder minimale Last.
Eine kurze konfigurierte TTL erleichtert Änderungen, erhöht aber möglicherweise die Abfragelast. Lange Werte erschweren schnelle Korrekturen. Zusätzlich erlaubt DNS „serve-stale“ unter bestimmten Fehlerbedingungen auch abgelaufene Daten. Eine TTL ist deshalb keine weltweite Umschaltgarantie. Auch ma ist eine definierte Gültigkeitsgrenze für neue alternative Verbindungen, keine bloße Empfehlung; bestehende Verbindungen müssen beim Ablauf nicht beendet werden.
Ankündigung und Erreichbarkeit getrennt prüfen
Die Beispiele verwenden einen Platzhalter. Die erste Anfrage zeigt Antwort-Header eines GET-Abrufs, anschließend folgt eine DNS-Abfrage. Der letzte Befehl benötigt einen curl-Build mit HTTP/3-Unterstützung; curl --version zeigt die Fähigkeiten.
curl --silent --show-error --max-time 15 --dump-header - \
--output /dev/null https://example.com/
dig +noall +answer HTTPS example.com
kdig -t HTTPS example.com
curl --version
curl --http3-only --silent --show-error --max-time 15 \
--output /dev/null --write-out 'HTTP %{http_version}\n' \
https://example.com/Ein --http3-only-Abruf testet QUIC ohne TCP-Rückfall. Das ist kein vollständiger Nachweis, dass ein Browser den HTTPS-Eintrag entdeckt und dessen alternatives Ziel auswählt. Bei abweichendem Zielnamen oder Port muss genau dieser Endpunkt gesondert geprüft werden. Weiterleitungen können außerdem zu einem anderen Host führen und benötigen eine eigene Einordnung.
Der HTTP/3- und Alt-Svc-Discovery-Prüfer kombiniert DNS-Anzeige, Protokollversuche und einen weiteren Abruf mit Alt-Svc-Cache. Die geprüfte Implementierung folgt jedoch keinem HTTPS-Alias, übernimmt DNS-Ziel und DNS-Port nicht in den direkten QUIC-Test und behandelt abgeschnittene DNS-Antworten nicht vollständig. Der zweite Abruf ist ein curl-Test, kein vollständiger Browserbesuch. Einzelbefunde bleiben nützlich; eine umfassende DNS-Discovery-Prüfung ist damit nicht belegt.
Die Unterscheidung zwischen erzwungenem Protokolltest und tatsächlichem Clientverhalten behandelt auch HTTP/3 beim ersten Besuch: Wie ein Client das Protokoll entdeckt und was zwanzig Seiten geantwortet haben.
Fragen und Antworten
Reicht das Anlegen des DNS-Eintrags?
Nein. Der angekündigte Endpunkt muss das Protokoll tatsächlich unterstützen, ein passendes Zertifikat liefern und auf dem angegebenen UDP-Port erreichbar sein. DNS, TLS-Konfiguration, Webserver beziehungsweise CDN und Firewall müssen zusammenpassen. Der Eintrag allein erzeugt keinen QUIC-Dienst.
Wie gelingt eine kontrollierte Umstellung?
Zuerst den Dienst und den vorgesehenen UDP-Port bereitstellen, dann aus geeigneten externen Netzen prüfen und anschließend DNS beziehungsweise Alt-Svc veröffentlichen. HTTP/3 ist nicht auf Port 443 beschränkt. Beim Rückzug frühzeitig Cache-Zeiten berücksichtigen, die Ankündigungen ändern und für erreichbare Clients gegebenenfalls Alt-Svc: clear senden. Bestehende Verbindungen und noch gespeicherte Konfigurationen benötigen eine Übergangsphase; bloßes Entfernen eines Headers löscht fremde Caches nicht sofort.
Verhindert EDNS0 jede abgeschnittene Antwort?
Nein. EDNS0 erlaubt die Ankündigung einer größeren UDP-Nutzlast. Große Antworten können trotzdem abgeschnitten werden oder auf dem Netzweg scheitern; das TC-Bit und ein geeigneter Rückfall, üblicherweise auf DNS über TCP, gehören zur Fehlerbehandlung. Nicht jeder HTTPS-Eintrag mit ECH überschreitet zwangsläufig 512 Byte.
Was bedeutet TYPE65 in der Ausgabe?
Ein älteres Werkzeug kann den unbekannten DNS-Typ in generischer Form mit Rohdaten anzeigen. Eine aktuelle Version von dig oder kdig stellt bekannte HTTPS-Parameter lesbarer dar. Die bloße Anzeige eines ech-Feldes bestätigt weiterhin keine erfolgreiche ECH-Verbindung.
Passend dazu
