7.1. "alpn" und "no-default-alpn"

Die SvcParamKeys "alpn" und "no-default-alpn" geben zusammen die Menge der Application-Layer Protocol Negotiation (ALPN) Protokollidentifikatoren und zugehörigen Transportprotokolle an, die von diesem Dienstendpunkt unterstützt werden (die "SVCB ALPN-Menge").

Wie bei Alt-Svc wird jeder ALPN-Protokollidentifikator verwendet, um das Anwendungsprotokoll und die zugehörige Protokollsuite zu identifizieren, die vom Endpunkt unterstützt werden (die "Protokollsuite"). Das Vorhandensein eines ALPN-Protokollidentifikators in der SVCB ALPN-Menge zeigt an, dass dieser Dienstendpunkt, beschrieben durch TargetName und die anderen Parameter (z.B. "port"), Dienste mit der Protokollsuite anbietet, die mit diesem ALPN-Identifikator verbunden ist.

Clients filtern die Menge der ALPN-Identifikatoren, um sie mit den von ihnen unterstützten Protokollsuiten abzugleichen, und dies bestimmt das verwendete zugrunde liegende Transportprotokoll (wie QUIC über UDP oder TLS über TCP). ALPN-Protokollidentifikatoren, die keine Protokollsuite eindeutig identifizieren (z.B. eine Identifikationssequenz, die sowohl mit TLS als auch mit DTLS verwendet werden kann), sind mit diesem SvcParamKey nicht kompatibel und dürfen nicht in die SVCB ALPN-Menge aufgenommen werden.

7.1.1. Darstellung

ALPNs werden durch ihre registrierte "Identifikationssequenz" (alpn-id) identifiziert, die eine Sequenz von 1-255 Oktetten ist.

alpn-id = 1*255OCTET

Für "alpn" muss der Darstellungswert eine durch Kommas getrennte Liste von einem oder mehreren alpn-ids sein. Zonendatei-Implementierungen können die Zeichen "," und "\" in ALPN-IDs verbieten, anstatt das Wert-Listen-Escape-Verfahren zu implementieren, und sich auf das opake Schlüsselformat (z.B. key1=\002h2) verlassen, falls diese Zeichen benötigt werden.

Der Übertragungsformatwert für "alpn" besteht aus mindestens einer alpn-id mit einem Längenpräfix als einzelnes Oktett, und diese Längen-Wert-Paare werden verkettet, um den SvcParamValue zu bilden. Diese Paare müssen den SvcParamValue genau ausfüllen; andernfalls ist der SvcParamValue fehlerhaft.

Für "no-default-alpn" müssen die Darstellungs- und Übertragungsformatwerte leer sein. Wenn "no-default-alpn" in einem RR angegeben wird, muss auch "alpn" angegeben werden, damit der RR "selbstkonsistent" ist (Abschnitt 2.4.3).

Jedes Schema, das diesen SvcParamKey verwendet, definiert eine "Standardmenge" von ALPN-IDs, die von nahezu allen Clients und Servern unterstützt werden; diese Menge kann leer sein. Um die SVCB ALPN-Menge zu bestimmen, beginnt der Client mit der Liste der alpn-ids aus dem "alpn" SvcParamKey, und er fügt die Standardmenge hinzu, es sei denn, der "no-default-alpn" SvcParamKey ist vorhanden.

7.1.2. Verwendung

Um eine Verbindung zum Endpunkt herzustellen, müssen Clients:

1. SVCB-ALPN-Intersection als die Menge der Protokolle in der SVCB ALPN-Menge definieren, die der Client unterstützt.

2. Intersection-Transports als die Menge der Transporte (z.B. TLS, DTLS, QUIC) definieren, die von den Protokollen in SVCB-ALPN-Intersection impliziert werden.

3. Für jeden Transport in Intersection-Transports eine ProtocolNameList konstruieren, die die Identifikationssequenzen aller vom Client für diesen Transport unterstützten ALPN-Protokolle enthält, ohne Rücksicht auf die SVCB ALPN-Menge.

Wenn beispielsweise die SVCB ALPN-Menge ["http/1.1", "h3"] ist und der Client HTTP/1.1, HTTP/2 und HTTP/3 unterstützt, könnte der Client versuchen, sich mit TLS über TCP mit einer ProtocolNameList von ["http/1.1", "h2"] zu verbinden, und könnte auch eine Verbindung mit QUIC mit einer ProtocolNameList von ["h3"] versuchen.

Sobald der Client ein ClientHello konstruiert hat, verläuft die Protokollverhandlung in diesem Handshake wie in [ALPN] spezifiziert, ohne Rücksicht auf die SVCB ALPN-Menge.

Clients können ein Fallback-Verfahren implementieren und einen weniger bevorzugten Transport verwenden, wenn bevorzugtere Transporte keine Verbindung herstellen können. Dieses Fallback-Verhalten ist anfällig für Manipulation durch einen Netzwerkangreifer, der die bevorzugteren Transporte blockiert, kann aber für die Kompatibilität mit bestehenden Netzwerken notwendig sein.

Mit diesem Verfahren kann ein Angreifer, der DNS und Netzwerkverkehr ändern kann, eine erfolgreiche Transportverbindung verhindern, aber nicht auf andere Weise in die ALPN-Protokollauswahl eingreifen. Dieses Verfahren stellt auch sicher, dass jede ProtocolNameList mindestens ein Protokoll aus der SVCB ALPN-Menge enthält.

Clients sollten nicht versuchen, eine Verbindung zu einem Dienstendpunkt herzustellen, dessen SVCB ALPN-Menge keine unterstützten Protokolle enthält.

Um Verhaltenskonsistenz zu gewährleisten, können Clients das gesamte SVCB RRset ablehnen und auf die grundlegende Verbindungsherstellung zurückfallen, wenn alle kompatiblen RRs "no-default-alpn" anzeigen, selbst wenn die Verbindung mit einem nicht standardmäßigen ALPN-Protokoll erfolgreich hätte sein können.

Zonenbetreiber sollten sicherstellen, dass mindestens ein RR in jedem RRset die Standardtransporte unterstützt. Dies ermöglicht Kompatibilität mit der größten Anzahl von Clients.