Zusammenfassung

  • SVCB- und HTTPS-Records bündeln alternative Endpunkte mit ihren Parametern und tragen eine Empfehlung des Herausgebers. DNSSEC kann diese Veröffentlichung authentisieren, nicht aber Clientfähigkeit, Erreichbarkeit, TLS-Identität oder Anwendungserfolg.
  • Der Client behält die Ausführungsentscheidung: Er verwirft fehlerhafte und inkompatible Records, wertet Pflichtschlüssel aus, mischt Gleichstände, beachtet Proxy- und Adresspolitik, versucht Alternativen, fällt gegebenenfalls zurück und prüft den ursprünglichen Dienstnamen.

Die schwierigste Abweichung ist eine, bei der alle Beteiligten formal richtig handeln. Ein signiertes HTTPS-RRset nennt HTTP/3 als erste, HTTP/2 als zweite Option. Ein moderner Client nutzt die erste. Ein älterer versteht einen obligatorischen Parameter nicht und nimmt die zweite. Ein dritter hat bereits eine passende Verbindung zur zweiten Option begonnen und verwendet sie weiter.

Wer nur das RRset betrachtet, sieht eine Präferenz. Wer den laufenden Verkehr betrachtet, sieht mehrere Ergebnisse. Dazwischen liegt kein Widerspruch, sondern das vom Standard vorgesehene Entscheidungsfeld des Clients.

RFC 9460 definiert SVCB als RR-Typ 64 und HTTPS als SVCB-kompatiblen Typ 65. Beide liefern Verbindungsinformationen, bevor die Anwendung zunächst einen womöglich ungünstigen Standardpfad benutzen muss. Der Herausgeber kann Alternativen beschreiben, ohne dass unabhängige DNS-Antworten Parameter verschiedener Betriebsumgebungen vermischen.

SvcPriority null bedeutet AliasMode: Ein Dienst verweist auf einen TargetName. Positive Werte bedeuten ServiceMode: TargetName und SvcParams im selben Record gehören als Endpunktpaket zusammen. AliasMode gilt nur für den abgefragten SVCB-kompatiblen Typ. Anders als CNAME schreibt es nicht sämtliche RR-Typen um und verlegt auch nicht die HTTPS-Origin.

Gerade am Zonen-Apex ist das nützlich. Es bleibt aber eine teilnehmende Technik. Alte Clients brauchen weiter nutzbare A- und AAAA-Records; Alias-Ketten haben Implementierungsgrenzen. Die veröffentlichte Option ist kein Befehl an Software, die sie nicht kennt.

In ServiceMode filtert der Client. Fehlerhafte Drahtdaten können das ganze RRset unbrauchbar machen. Widersprüchliche erkannte Parameter disqualifizieren einen Record. Unbekannte Schlüssel dürfen meist ignoriert werden, außer mandatory erklärt sie für die Funktionsfähigkeit dieses Endpunkts als erforderlich. Dann ist ein Client ohne Verständnis dieses Schlüssels inkompatibel.

Das ist ein sauberer Erweiterungsvertrag. Optionale Neuerungen brechen ältere Clients nicht sofort. Tatsächlich notwendige Eigenschaften können zugleich vor einem halbfunktionalen Versuch geschützt werden. Wer mandatory nur als Upgrade-Druck benutzt, macht aus einer Produktpräferenz bewusst einen Ausschluss.

Das am 25. Juni 2026 aktualisierte IANA-Register für SVCB Service Parameters enthält neben mandatory, ALPN, Unterdrückung des Standard-ALPN, Port und IPv4/IPv6-Hinweisen inzwischen ECH, DoH-Pfad, OHTTP, TLS-Gruppen, DNS-over-CoAP-Pfad, PvD und eine Betreiberzuversicht je Nameserver-Transport. Registrierung schafft Nummer und Bedeutung. Sie beweist weder breite Implementierung noch Eignung in jedem Protokoll-Mapping.

Auch SvcPriority ist begrenzt. Die kleinere positive Zahl ist die Empfehlung des Domaininhabers. Bei gleicher Priorität soll der Client die Records zufällig mischen, um gleichmäßig zu verteilen; SRV-Gewichte gibt es nicht. Üblicherweise versucht er höher bevorzugte kompatible Endpunkte zuerst und geht bei Fehlern weiter.

RFC 9460 erlaubt trotzdem parallele Versuche, Vorabruf mehrerer TargetNames, die Bevorzugung sofort nutzbarer Records ohne Zusatzabfrage und die Fortsetzung einer bereits laufenden kompatiblen Verbindung. Eine Zone beeinflusst damit den Auswahlraum, sagt aber keine einzelne Verbindung voraus.

ALPN trennt Anzeige und Aushandlung. Der Parameter listet angebotene Protokollsuiten. Der Client behält unterstützte Werte; RFC 7301 regelt anschließend die Auswahl im TLS-Handshake. Ein h3 im DNS aktiviert weder QUIC im Client noch UDP im Netz und garantiert keinen erfolgreichen Server-Handshake.

IP-Hinweise sind ebenso vorläufig. Liegen A oder AAAA vor, soll der Client ipv4hint und ipv6hint ignorieren. Andernfalls fragt er den TargetName trotzdem ab und kann von einer Hinweisadresse auf die wirkliche Antwort wechseln. Ein Hinweis als dauerhafte Adressautorität kann Geosteuerung oder Lastverteilung unterlaufen.

Zwischen mehreren Adressen kann der Client nach Happy Eyeballs v2 IPv6 und IPv4 gegeneinander antreten lassen. Der Sieger hängt vom aktuellen Pfad und Timing ab. Die Zone liefert Kandidaten; das Netz liefert Beobachtung.

DNSSEC authentisiert nur die Publikationsschicht. HTTPS-Records sind nicht automatisch echt. RFC 9460 modelliert DNS als potenziell nicht vertrauenswürdig und lässt Signierung und Prüfung optional. Schützt ein Client A/AAAA, sollte er dieselbe Politik auf SVCB anwenden, damit eine Fälschung den Schutz nicht umgeht. RFC 4035 definiert die Validierungszustände.

Ein Secure-RRset belegt, dass die signierte Zone diesen Inhalt veröffentlicht hat. Es belegt nicht, dass der Endpunkt erreichbar, der Pflichtschlüssel implementiert, der Proxy bereit oder das Zertifikat gültig ist. Authentische Empfehlung und erfolgreiche Verbindung sind unterschiedliche Tatsachen.

Der TargetName wird außerdem nicht zur Dienstidentität. TLS-SNI und HTTP Host beziehungsweise :authority nennen weiterhin die ursprüngliche Origin. RFC 9525 stellt klar, dass SVCB/HTTPS die bestehenden PKIX-Regeln für HTTP und DNS-over-TLS nicht verändern. Ein CDN kann die Verbindung terminieren, muss aber die ursprüngliche Identität nachweisen.

Der Vergleich mit Alt-Svc hält diese Grenze stabil. Alt-Svc kann Host, Port und Protokoll verändern, ohne die Origin zu ersetzen; der Client wählt nach eigenen Sicherheitskriterien. HTTPS RR stellt Ähnliches bereits über DNS bereit und verwendet TTL, Alt-Svc kommt über HTTP und verwendet ma. Die Origin- und Authority-Semantik aus RFC 9110 steht über beiden Verbindungswegen.

Fallback ermöglicht schrittweise Einführung. Für bestehende Protokolle wie HTTP ist SVCB normalerweise optional: Scheitern kompatible Alternativen, darf der Client konventionell verbinden. Das erhält Erreichbarkeit, kann aber ECH, HTTP/3 oder eine andere Schutzwirkung verlieren. RFC 7838 warnt bei alternativen Diensten ebenfalls vor Downgrade. Leistungsvorteile und unverzichtbare Sicherheitsuntergrenzen brauchen getrennte Regeln.

Proxys verschieben zusätzlich die Auflösung. Ein namensbasierter Proxy kann A/AAAA selbst ermitteln. Fragt der Client SVCB separat ab, offenbart er das Ziel womöglich einer weiteren Partei. Ohne geeignete private Auflösung muss ein optionaler Client SVCB abschalten; ein abhängiger Client muss die Konfiguration ablehnen. Bei Nutzung umfasst Kompatibilität auch den Proxy und dessen Netzstandort.

RFC 9461 bildet SVCB auf DoT, DoH und DoQ ab. Das Beispiel zeigt, dass ein gemeinsames Format kein universelles Verhalten erzeugt. Jedes Mapping muss sichere Schlüssel, Identität und Fallback festlegen.

Heng Lus Trennung von laufendem Code, minimaler Anfangsspezifikation und lokalisierter Zukunftsentscheidung sowie Realitätsebenen ordnet die Prüfung. Standard, Zonenpublikation, Resolverantwort, Clientfilter, TLS-Verhandlung und Anwendungsergebnis benötigen jeweils eigene Belege.

Darum endet ein Audit nicht bei Typ 65. Es verbindet RRset und DNSSEC mit Clientversion, verstandenen Schlüsseln, Proxymodus, gewähltem Record, Adressversuchen, ALPN, Zertifikat, Fallbackgrund und Anwendungsergebnis. Der Herausgeber beweist das Angebot; der laufende Pfad beweist die Verbindung.