7.1. "alpn" e "no-default-alpn"

I SvcParamKeys "alpn" e "no-default-alpn" insieme indicano l'insieme degli identificatori di protocollo di negoziazione del protocollo a livello applicativo (ALPN) e dei protocolli di trasporto associati supportati da questo endpoint di servizio (l'"insieme ALPN SVCB").

Come con Alt-Svc, ogni identificatore di protocollo ALPN viene utilizzato per identificare il protocollo applicativo e la suite di protocolli associata supportata dall'endpoint (la "suite di protocolli"). La presenza di un identificatore di protocollo ALPN nell'insieme ALPN SVCB indica che questo endpoint di servizio, descritto da TargetName e dagli altri parametri (ad esempio, "port"), offre servizio con la suite di protocolli associata a questo identificatore ALPN.

I client filtrano l'insieme degli identificatori ALPN per corrispondere alle suite di protocolli che supportano, e questo informa il protocollo di trasporto sottostante utilizzato (come QUIC su UDP o TLS su TCP). Gli identificatori di protocollo ALPN che non identificano in modo univoco una suite di protocolli (ad esempio, una sequenza di identificazione che può essere utilizzata sia con TLS che con DTLS) non sono compatibili con questo SvcParamKey e non devono essere inclusi nell'insieme ALPN SVCB.

7.1.1. Rappresentazione

Gli ALPN sono identificati dalla loro "sequenza di identificazione" registrata (alpn-id), che è una sequenza di 1-255 ottetti.

alpn-id = 1*255OCTET

Per "alpn", il valore di presentazione deve essere un elenco separato da virgole di uno o più alpn-id. Le implementazioni di file di zona possono vietare i caratteri "," e "\" negli ID ALPN invece di implementare la procedura di escape dell'elenco di valori, affidandosi al formato di chiave opaco (ad esempio, key1=\002h2) nel caso in cui questi caratteri siano necessari.

Il valore in formato di trasmissione per "alpn" consiste di almeno un alpn-id preceduto dalla sua lunghezza come singolo ottetto, e queste coppie lunghezza-valore sono concatenate per formare il SvcParamValue. Queste coppie devono riempire esattamente il SvcParamValue; altrimenti, il SvcParamValue è malformato.

Per "no-default-alpn", i valori di presentazione e formato di trasmissione devono essere vuoti. Quando "no-default-alpn" è specificato in un RR, anche "alpn" deve essere specificato affinché il RR sia "auto-coerente" (Sezione 2.4.3).

Ogni schema che utilizza questo SvcParamKey definisce un "insieme predefinito" di ID ALPN supportati da quasi tutti i client e server; questo insieme può essere vuoto. Per determinare l'insieme ALPN SVCB, il client inizia con l'elenco degli alpn-id dal SvcParamKey "alpn", e aggiunge l'insieme predefinito a meno che il SvcParamKey "no-default-alpn" non sia presente.

7.1.2. Uso

Per stabilire una connessione all'endpoint, i client devono:

1. Sia SVCB-ALPN-Intersection l'insieme dei protocolli nell'insieme ALPN SVCB che il client supporta.

2. Sia Intersection-Transports l'insieme dei trasporti (ad esempio, TLS, DTLS, QUIC) implicati dai protocolli in SVCB-ALPN-Intersection.

3. Per ogni trasporto in Intersection-Transports, costruire una ProtocolNameList contenente le sequenze di identificazione di tutti i protocolli ALPN supportati dal client per quel trasporto, senza riguardo all'insieme ALPN SVCB.

Ad esempio, se l'insieme ALPN SVCB è ["http/1.1", "h3"] e il client supporta HTTP/1.1, HTTP/2 e HTTP/3, il client potrebbe tentare di connettersi utilizzando TLS su TCP con una ProtocolNameList di ["http/1.1", "h2"] e potrebbe anche tentare una connessione utilizzando QUIC con una ProtocolNameList di ["h3"].

Una volta che il client ha costruito un ClientHello, la negoziazione del protocollo in quell'handshake procede come specificato in [ALPN], senza riguardo all'insieme ALPN SVCB.

I client possono implementare una procedura di fallback, utilizzando un trasporto meno preferito se i trasporti più preferiti non riescono a connettersi. Questo comportamento di fallback è vulnerabile alla manipolazione da parte di un attaccante di rete che blocca i trasporti più preferiti, ma potrebbe essere necessario per la compatibilità con le reti esistenti.

Con questa procedura in atto, un attaccante che può modificare il DNS e il traffico di rete può impedire una connessione di trasporto riuscita ma non può altrimenti interferire con la selezione del protocollo ALPN. Questa procedura garantisce anche che ogni ProtocolNameList includa almeno un protocollo dall'insieme ALPN SVCB.

I client non dovrebbero tentare la connessione a un endpoint di servizio il cui insieme ALPN SVCB non contiene alcun protocollo supportato.

Per garantire la coerenza del comportamento, i client possono rifiutare l'intero SVCB RRset e ricorrere all'instaurazione di connessione di base se tutti gli RR compatibili indicano "no-default-alpn", anche se la connessione avrebbe potuto avere successo utilizzando un protocollo ALPN non predefinito.

Gli operatori di zona dovrebbero assicurarsi che almeno un RR in ogni RRset supporti i trasporti predefiniti. Questo consente la compatibilità con il maggior numero di client.