Zusammenfassung

  • Eine kleinere SvcPriority bedeutet nur unter verwendbaren Records Vorrang. Zuvor scheiden fehlerhafte, widersprüchliche oder inkompatible Einträge aus; ein unbekannter Pflichtschlüssel kann deshalb die scheinbare Nummer eins unzulässig machen.
  • AliasMode delegiert Diensterkennung, ohne den Ursprung zu ändern. ServiceMode bindet Ziel und Parameter. Adresshinweise, angekündigtes ALPN und selbst authentisiertes DNS bleiben Eingaben; A/AAAA, Zertifikat für den Ursprungsnamen, ausgehandeltes ALPN und Anwendungsergebnis liefern spätere Belege.

Vorrang ohne Zulassung

Ein Origin veröffentlicht zwei HTTPS-ServiceMode-Records. Priorität 1 verweist auf eine neue Edge-Plattform und markiert eine experimentelle Erweiterung als mandatory. Priorität 2 beschreibt die bisherige Plattform mit Parametern, welche die installierten Clients verstehen. Das Betriebsdashboard nennt Nummer eins den bevorzugten Endpunkt.

Für einen Client ohne diese Erweiterung gehört der Record gar nicht zur Auswahl. RFC 9460 verlangt, einen ServiceMode-Record zu ignorieren, wenn nicht alle Pflichtschlüssel verstanden werden. Der Client darf Priorität 2 verwenden. Er hat den Vorrang nicht umgedreht; er hat zuerst die Zulässigkeit bestimmt.

Das Szenario ist analytisch und keiner Browser- oder CDN-Marke zugeschrieben. Ein DNS-Inhaber kann Verbindungspläne anbieten. Er kann nicht jedem Client die nötige Fähigkeit verleihen, einen Port im Netz öffnen, dem Server eine Aushandlung befehlen oder ein Providerzertifikat zur Identität des Ursprungs machen.

Zwei Modi begrenzen die Delegation

RFC 9460 definiert SVCB als RR-Typ 64 und HTTPS als Typ 65. Ein Eintrag enthält SvcPriority, TargetName und optionale SvcParams. Null bedeutet AliasMode, ein Wert größer null ServiceMode.

AliasMode delegiert die Ermittlung eines bestimmten Dienstes an einen anderen Namen. Damit wird insbesondere dienstspezifisches Aliasing am Zonenapex möglich, wo CNAME nicht eingesetzt werden kann. Andere RR-Typen desselben Namens bleiben unberührt. Parameter im AliasMode werden ignoriert, und Implementierungen müssen die Kettenlänge begrenzen.

Auch die Identität wandert nicht mit. Nach dem Folgen eines Provider-TargetName sendet der HTTPS-Client weiterhin den ursprünglichen Dienstnamen in SNI, prüft das Zertifikat dagegen und behält ihn in HTTP Host beziehungsweise :authority. Delegiert wird der Entdeckungsweg, nicht das Vertrauen des Lesers.

ServiceMode bindet Ziel, Port, Protokollangebot, Adresshinweise und Erweiterungen zu einem Kandidaten. Mehrere CDNs können so unterschiedliche, intern passende Pläne veröffentlichen. Die Bindung verhindert das zufällige Mischen fremder Parameter und Adressen, beweist aber weder Erreichbarkeit noch gleichen Auslieferungsstand.

Erst verwerfen, dann ordnen

Fehlerhafte Wire-Daten können das gesamte RRset ungültig machen und zum Verfahren ohne SVCB führen. Widersprüchliche bekannte Parameter machen einen Record inkonsistent. Ein gewöhnlicher unbekannter Schlüssel darf ignoriert werden; steht er in mandatory, ist der Record für diesen Client inkompatibel.

Erst die verbleibenden Records werden nach Priorität versucht. Kleinere Zahlen kommen zuerst, Einträge gleicher Priorität werden für gleichmäßige Verteilung zufällig gemischt. Anders als bei SRV gibt es kein Betreibergewicht. Niedrige Zahl heißt daher „bevorzugen, wenn kompatibel“, nicht „bedingungslos befolgen“.

mandatory zwingt den Server zu nichts. Es erklärt, dass ein Ignorieren des genannten Schlüssels den Plan verfälscht. Jeder genannte Schlüssel muss im selben Record vorkommen; mandatory darf sich nicht selbst nennen. Bei HTTPS sind port und no-default-alpn bei Vorhandensein automatisch Pflicht. Wer sie ignoriert, verbindet entweder zum falschen Listener oder führt ein bewusst ausgeschlossenes Standardprotokoll wieder ein.

DNS-Ankündigung und Handshake-Ergebnis

alpn beschreibt Protokollsuiten, die der Endpunkt anbietet, und kann einen direkten HTTP/3- oder HTTP/2-Versuch vorbereiten. Die wirkliche Auswahl erfolgt weiterhin im Handshake. DNS kann früher ausgerollt sein als die Edge, UDP kann blockiert sein oder ein Standort kann eine ältere Generation betreiben.

Eine Untersuchung hält deshalb beide Werte fest: das DNS-ALPN-Set und das tatsächlich ausgehandelte Protokoll. Ebenso nennt port den Versuchsort, während Clientrichtlinie oder Firewall ihn ablehnen können.

ipv4hint und ipv6hint verkürzen Wartezeit, ersetzen aber A/AAAA des TargetName nicht. Sind Adressantworten lokal vorhanden, soll der Client die Hints ignorieren. Sonst fragt er den Zielnamen dennoch ab und verwendet diese Ergebnisse künftig. Ein früher Hint kann später einer geoabhängigen Adresse weichen.

Der Nachweis muss daher die Herkunft der IP enthalten: Hint, Answer, Additional, Cache oder Proxyauflösung, samt TTL und Netz. Nur die Ziel-IP zu protokollieren verwischt geplantes Racing, veralteten Zustand, Provider-Split und feindliche Umleitung.

Der Ursprungsname bleibt die Identität

RFC 9460 rechnet mit SVCB/HTTPS über nicht vertrauenswürdiges DNS. DNSSEC kann Herkunft und Integrität des RRsets bestätigen, ist aber optional. Auch eine gültige DNSSEC-Antwort beweist nicht, dass das Ziel lebt, das angekündigte Protokoll ausführt oder richtige Inhalte liefert.

Der alternative Endpunkt muss sich für den ursprünglichen Dienst authentisieren. Ein Zertifikat nur für den Provider-TargetName reicht nicht. DNS steuert Entdeckung, TLS die Peer-Identität, ALPN das Ergebnis dieser Verbindung und HTTP die Origin-Autorität samt Antwort. Kein grüner Status darf für alle Ebenen sprechen.

Da HTTP älter als SVCB ist, können Clients bei gewöhnlicher Abwesenheit auf klassische Verbindung zurückfallen. Scheitert jedoch eine geschützte SVCB-Auflösung an Authentisierung, SERVFAIL, geschütztem Transport oder Timeout, sollte der Versuch enden, damit ein Angreifer Parameter nicht selektiv entfernen kann. Bei ungeschütztem DNS darf die lokale Politik anders entscheiden.

In Multi-CDN-Zonen können CNAME, HTTPS und A/AAAA unterschiedliche Auslieferungsgenerationen sehen. Der Client muss die Adressen des tatsächlich gewählten TargetName auflösen. Running-Code Primacy bedeutet hier: Die gemeinsame Deklaration erhält Autorität durch kompatible Ausführung, nicht indem sie die eigenständigen Prüfungen von TLS und HTTP verdrängt.

Quellen