Passa al contenuto principale

4. Specifications (Specifiche)

4.1. Connection Establishment (Stabilimento della connessione)​

Le connessioni DoQ sono stabilite come descritto nella specifica di trasporto QUIC [RFC9000]. Durante lo stabilimento della connessione, il supporto DoQ è indicato selezionando il token di negoziazione del protocollo a livello applicativo (ALPN) "doq" nell'handshake crittografico.

4.1.1. Port Selection (Selezione della porta)​

Per impostazione predefinita, un server DNS che supporta DoQ deve (MUST) ascoltare e accettare connessioni QUIC sulla porta UDP dedicata 853 (Sezione 8), a meno che non vi sia un accordo reciproco per utilizzare un'altra porta.

Per impostazione predefinita, un client DNS che desidera utilizzare DoQ con un determinato server deve (MUST) stabilire una connessione QUIC alla porta UDP 853 sul server, a meno che non vi sia un accordo reciproco per utilizzare un'altra porta.

Le connessioni DoQ non devono (MUST NOT) utilizzare la porta UDP 53. Questa raccomandazione contro l'uso della porta 53 per DoQ è volta a evitare confusione tra DoQ e l'uso di DNS su UDP [RFC1035].

4.2. Stream Mapping and Usage (Mappatura e utilizzo dei flussi)​

Il mapping del traffico DNS sui flussi QUIC sfrutta le funzionalità dei flussi QUIC dettagliate nella Sezione 2 di [RFC9000].

Tutti i messaggi DNS (query e risposte) inviati su connessioni DoQ devono (MUST) essere codificati come un campo di lunghezza di 2 ottetti seguito dal contenuto del messaggio come specificato in [RFC1035].

Il client deve (MUST) selezionare il prossimo flusso bidirezionale avviato dal client disponibile per ogni query successiva su una connessione QUIC. Il client deve (MUST) inviare la query DNS sul flusso selezionato e deve (MUST) indicare tramite il meccanismo STREAM FIN che non verranno inviati ulteriori dati su quel flusso.

Il server deve (MUST) inviare la risposta o le risposte sullo stesso flusso e deve (MUST) indicare, dopo l'ultima risposta, tramite il meccanismo STREAM FIN che non verranno inviati ulteriori dati su quel flusso.

4.2.1. DNS Message IDs (ID dei messaggi DNS)​

Quando si inviano query su una connessione QUIC, l'ID del messaggio DNS deve (MUST) essere impostato su 0. La mappatura dei flussi per DoQ consente una correlazione non ambigua di query e risposte, quindi il campo ID del messaggio non è necessario.

4.3. DoQ Error Codes (Codici di errore DoQ)​

Sono definiti i seguenti codici di errore:

  • DOQ_NO_ERROR (0x0): Nessun errore
  • DOQ_INTERNAL_ERROR (0x1): Errore interno
  • DOQ_PROTOCOL_ERROR (0x2): Errore di protocollo
  • DOQ_REQUEST_CANCELLED (0x3): Richiesta annullata
  • DOQ_EXCESSIVE_LOAD (0x4): Carico eccessivo
  • DOQ_UNSPECIFIED_ERROR (0x5): Errore non specificato
  • DOQ_ERROR_RESERVED (0xd098ea5e): Riservato per i test

4.3.1. Transaction Cancellation (Annullamento della transazione)​

Se un client DoQ desidera annullare una richiesta in corso, deve (MUST) emettere un STOP_SENDING QUIC e dovrebbe (SHOULD) utilizzare il codice di errore DOQ_REQUEST_CANCELLED.

4.3.2. Transaction Errors (Errori di transazione)​

I server normalmente completano le transazioni inviando una risposta DNS sul flusso della transazione. Se un server non è in grado di inviare una risposta DNS a causa di un errore interno, dovrebbe (SHOULD) emettere un frame QUIC RESET_STREAM con codice di errore DOQ_INTERNAL_ERROR.

4.3.3. Protocol Errors (Errori di protocollo)​

Gli errori di protocollo includono la ricezione di un messaggio con un ID di messaggio diverso da zero, la ricezione di un STREAM FIN prima di tutti i dati attesi o altre violazioni del protocollo. Se un peer incontra tale errore, dovrebbe (SHOULD) interrompere forzatamente la connessione utilizzando il meccanismo CONNECTION_CLOSE di QUIC con codice di errore DOQ_PROTOCOL_ERROR.

4.3.4. Alternative Error Codes (Codici di errore alternativi)​

L'uso di un codice di errore in un contesto imprevisto o la ricezione di un codice di errore sconosciuto deve (MUST) essere trattato come equivalente a DOQ_UNSPECIFIED_ERROR.

4.4. Connection Management (Gestione della connessione)​

I client e i server che implementano DoQ dovrebbero (SHOULD) negoziare l'uso del timeout di inattività. I client dovrebbero (SHOULD) monitorare il tempo di inattività sulla loro connessione e stabilire una nuova connessione se il timeout di inattività si sta avvicinando.

4.5. Session Resumption and 0-RTT (Ripresa della sessione e 0-RTT)​

Un client può (MAY) sfruttare i meccanismi di ripresa della sessione e 0-RTT se il server li supporta. Il meccanismo 0-RTT non deve (MUST NOT) essere utilizzato per inviare richieste DNS che non sono transazioni "riproducibili". Solo le transazioni con OPCODE di QUERY o NOTIFY sono considerate riproducibili.

4.6. Message Sizes (Dimensioni dei messaggi)​

Le query e le risposte DoQ sono inviate su flussi QUIC, che teoricamente possono trasportare fino a 2^62 byte. Tuttavia, i messaggi DNS sono limitati a una dimensione massima di 65535 byte. Le implementazioni DoQ assumono sempre che la dimensione massima del messaggio sia 65535 byte.

Ultimo aggiornamento il