Zusammenfassung

  • Ein HTTPS Resource Record veröffentlicht Verbindungsanweisungen, führt aber keinen Verbindungstest aus.
  • Die Auswahl hängt von Priorität, verstandenen Parametern, Auflösung und Clientfähigkeiten ab.
  • Adresshinweise, ALPN-Angebote und Erfolg nach einem Rückfall sind getrennte Nachweise.
  • Bereitschaft verlangt ein Prüfprotokoll, das das beobachtete RRset mit einer authentifizierten Anwendungsantwort jeder wichtigen Clientgruppe verbindet.

Stellen wir uns eine Bereitstellungsanzeige vor, die grün wird, sobald ein neuer HTTPS-Eintrag im DNS erscheint. Er kündigt HTTP/3 an und enthält einen IPv6-Adresshinweis. Ein gewöhnlicher Browser-Monitor lädt die Seite weiter, also gilt die Migration als abgeschlossen. Doch alle HTTP/3-Versuche einer Mobilfunkgruppe scheitern. Diese Nutzer erreichen den Dienst nur, weil ihre Clients auf HTTP/2 am bisherigen Endpunkt zurückfallen.

Der DNS-Eintrag war nicht falsch. Falsch war die Gleichsetzung von Veröffentlichung und Auslieferung.

RFC 9460 definiert SVCB- und HTTPS-Einträge, damit Clients alternative Endpunkte und Verbindungsparameter vor dem üblichen Aufbau erfahren. Das kann Latenz senken, direkte HTTP/3-Verbindungen ermöglichen, andere Ports nennen und zusammengehörige Parameter binden. Es ist wertvolle Steuerungsinformation, keine synthetische Transaktion.

Die Struktur beeinflusst die Wahl. SvcPriority null bezeichnet AliasMode, also die Delegation an einen anderen Namen. Ein Wert ungleich null bezeichnet ServiceMode und bindet TargetName an Parameter. Niedrigere Werte werden bevorzugt, Einträge gleicher Priorität jedoch zufällig gemischt. „HTTPS RR vorhanden“ bewahrt weder die nutzbare Option noch die tatsächliche Auswahl oder ihren Grund.

Kompatibilität zieht eine weitere Grenze. mandatory nennt Schlüssel, die der Client verstehen muss. Ist einer unbekannt, ist dieser Eintrag für ihn unbrauchbar. alpn bietet Anwendungsprotokolle an; no-default-alpn kann das vom URI-Schema normalerweise implizierte Protokoll entfernen. Dasselbe korrekte RRset kann daher je nach Browser, Betriebssystem, Bibliothek oder Geräterichtlinie andere Optionen ergeben.

ipv4hint und ipv6hint werden leicht überschätzt. Sie erlauben einen optimistischen Start. Nach RFC 9460 soll ein Client lokal vorhandene A- oder AAAA-Einträge bevorzugen; andernfalls soll er den TargetName abfragen und die erhaltenen Adressen für spätere Verbindungen verwenden. Ein Hinweis beweist weder Route noch UDP-Durchlass, NAT- oder Firewallverhalten oder einen lauschenden Zielprozess. Er sagt, wo ein Versuch beginnen kann; er weist keine Paketzustellung nach.

Auch die TLS-Autorität bleibt unverändert. Ein SVCB-Alias ändert nicht den zu authentifizierenden Ursprung. Der Client prüft das Zertifikat weiterhin für den ursprünglichen Dienstnamen. Eine DNS-Antwort kann also vorhanden und verstanden sein, während Zertifikat, SNI oder TLS-Handshake am angebotenen Ziel scheitern.

Für HTTP/3 setzt RFC 9114 das Anwendungsprotokoll auf QUIC, das RFC 9000 definiert. Nach DNS folgen noch QUIC-Aufbau, TLS-Authentifizierung, HTTP/3-Einstellungen und Anwendungsantwort. Jeder Übergang kann separat scheitern. Ein einziges Feld „HTTP/3 aktiviert“ löscht den Nachweis, der den Fehler lokalisieren könnte.

Der Rückfall verbirgt die Lücke. RFC 9460 sieht vor, dass Clients fehlerhafte oder inkompatible Einträge verwerfen und zum Aufbau ohne SVCB zurückkehren. Eine Nutzeranfrage kann erfolgreich sein, obwohl der alternative Endpunkt nie versucht wurde oder bereits scheiterte. Das schützt Verfügbarkeit, bestätigt aber nicht die Abnahme.

Umgekehrt beweist ein einzelner Fehler keinen allgemeinen Defekt. Der Client unterstützt vielleicht das ALPN nicht, sieht eine resolverabhängige Antwort, wählt ein anderes Ziel gleicher Priorität, nutzt einen Proxy, erlebt lokale UDP-Sperren oder hält alte DNS-Daten. Bereitschaft ist eine Aussage über eine Clientgruppe, keine aus einem Gerät abgeleitete Universalgröße.

Ein Prüfprotokoll der Endpunktbereitschaft beginnt mit Dienstname, Resolver, Netzwerk, Clientversion, Beobachtungspunkt und Zeit. Es enthält das vollständige HTTPS-RRset, DNS-Validierung, TTL und Cachealter, gewählte Priorität, Ziel und unterstützte Parameter, alle aufgelösten oder vorgeschlagenen Adressen sowie den Grund für Annahme, Überspringen oder Ablehnung jedes Eintrags.

Dann folgt die Ausführung: versuchte Adresse, Protokoll und Port; QUIC- oder TCP-Ergebnis; ausgehandeltes ALPN; Zertifikatsname und Prüfung; HTTP-Status und Fingerabdruck der HTTP-Repräsentation; eventueller Rückfall. Clientgruppe, Dauer, Endergebnis und die für die Bereitschaftsentscheidung verantwortliche Systemkomponente schließen das Protokoll ab.

„HTTPS RR beobachtet“ bedeutet dann nur, dass der Resolver das RRset lieferte. „Alternative gewählt“ heißt, dass der Client eine ServiceMode-Option annahm. „HTTP/3 verbunden“ setzt QUIC, TLS und HTTP/3 voraus. „Dienst geliefert“ verlangt die beabsichtigte Anwendungstransaktion. Alle Ereignisse gehören auf eine Zeitachse, doch das erste darf die folgenden nicht erzeugen.

Die Trennung verbessert die Diagnose. Ignorierte Einträge führen zu Kompatibilität und Pflichtschlüsseln. Auflösung mit QUIC-Fehler führt zu Pfad und Transportpolitik. TLS-Fehler führen zu Autorität und Bereitstellung. Erfolg erst nach Rückfall hält den Dienst verfügbar, aber die Alternative bleibt unbestätigt.

Innerhalb seiner Grenze ist der HTTPS-Eintrag ein nützlicher Nachweis: Er zeigt die veröffentlichte und beobachtete Dienstbindung. Endpunktbereitschaft beginnt, wenn ein identifizierter Client ihr folgt und ein authentifiziertes Anwendungsergebnis liefert.

Quellen

RFC 9460 — SVCB- und HTTPS-Einträge; RFC 9114 — HTTP/3; RFC 9000 — QUIC.