5. Dettagli del Protocollo (Protocol Details)
Il flusso complessivo delle Operazioni DNS con Stato (DNS Stateful Operations) attraversa una serie di fasi:
Stabilimento della Connessione (Connection Establishment): Un client stabilisce una connessione a un server (Sezione 4.2).
Connesso ma Senza Sessione (Connected but Sessionless): Esiste una connessione, ma una Sessione DSO non è stata stabilita. I messaggi DNS possono essere inviati dal client al server e le risposte DNS possono essere inviate dal server al client. In questo stato, un client che desidera utilizzare DSO può tentare di stabilire una Sessione DSO (Sezione 5.1). La gestione standard del timeout di inattività DNS-over-TCP è attiva [RFC7766] (vedere Sezione 7.1.2 di questo documento).
Stabilimento Sessione DSO in Corso (DSO Session Establishment in Progress): Un client ha inviato una richiesta DSO negli ultimi 30 secondi, ma non ha ancora ricevuto una risposta DSO per quella richiesta. In questa fase, il client può inviare ulteriori richieste DSO e ulteriori richieste DNS, ma NON DEVE inviare messaggi DSO unidirezionali (Sezione 5.1).
Timeout Stabilimento Sessione DSO: Un client ha inviato una richiesta DSO e dopo 30 secondi non ha ancora ricevuto alcuna risposta DSO per quella richiesta. Ciò significa che il server è ora in uno stato indeterminato. Il client interrompe forzatamente la connessione. Il client PUÒ riconnettersi senza utilizzare DSO, se appropriato.
Stabilimento Sessione DSO Fallito (DSO Session Establishment Failed): Un client ha inviato una richiesta DSO e ha ricevuto una risposta DSO corrispondente con un RCODE diverso da zero. Ciò significa che il tentativo di stabilire la Sessione DSO non è riuscito. A questo punto, il client è autorizzato a continuare a operare senza una Sessione DSO (Connesso ma Senza Sessione) ma non invia ulteriori messaggi DSO (Sezione 5.1).
Sessione DSO Stabilita (DSO Session Established): Un client ha inviato una richiesta DSO e ha ricevuto una risposta DSO corrispondente con RCODE impostato su NOERROR (0). Una Sessione DSO è stata ora stabilita con successo. Sia il client che il server possono inviare messaggi DSO e messaggi DNS; entrambi possono inviare risposte in risposta ai messaggi che ricevono (Sezione 5.2). Il timer di inattività (Sezione 6.4) è attivo; il timer keepalive (Sezione 6.5) è attivo. La gestione standard del timeout di inattività DNS-over-TCP non è più attiva [RFC7766] (vedere Sezione 7.1.2 di questo documento).
Spegnimento del Server (Server Shutdown): Il server ha deciso di terminare con garbo la sessione e ha inviato al client un messaggio Retry Delay (Sezione 6.6.1). Potrebbero esserci ancora messaggi non elaborati dal client; il server li ignorerà. Il server non invierà ulteriori messaggi al client (Sezione 6.6.1.1).
Spegnimento del Client (Client Shutdown): Il client ha deciso di disconnettersi, sia perché non ha più bisogno di servizio, la connessione è inattiva (Sezione 6.4.1) o perché il server gli ha inviato un messaggio Retry Delay (Sezione 6.6.1). Il client chiude la connessione con garbo (Sezione 5.3).
Riconnessione (Reconnect): Il client si è disconnesso in seguito a uno spegnimento del server. Il client attende che il Retry Delay specificato dal server scada (Sezione 6.6.3) oppure contatta un'istanza server diversa. Se il client non ha più bisogno di servizio, non si riconnette.
Interruzione Forzata (Forcibly Abort): Il client o il server ha rilevato un errore di protocollo e ulteriori comunicazioni avrebbero un comportamento indefinito. Il client o il server interrompe forzatamente la connessione (Sezione 5.3).
Attesa Riconnessione dopo Interruzione (Abort Reconnect Wait): Il client ha interrotto forzatamente la connessione ma ha ancora bisogno di servizio. Oppure, il server ha interrotto forzatamente la connessione, ma il client ha ancora bisogno di servizio. Il client si connette a un'istanza di servizio diversa (Sezione 9.1) oppure attende per riconnettersi (Sezione 6.6.3.1).
5.1. Stabilimento Sessione DSO (DSO Session Establishment)
Affinché una sessione possa essere stabilita tra un client e un server, il client deve prima stabilire una connessione al server utilizzando un trasporto applicabile (vedere Sezione 4.2).
In alcuni ambienti, può essere noto in anticipo tramite mezzi esterni che sia il client che il server supportano DSO, e in questi casi sia il client che il server possono avviare messaggi DSO in qualsiasi momento. In questo caso, la sessione viene stabilita non appena viene stabilita la connessione; ciò è denominato stabilimento di Sessione DSO implicito.
Tuttavia, nel caso tipico un server non saprà in anticipo se un client supporta DSO, quindi in generale, a meno che non sia noto in anticipo con altri mezzi che un client supporta DSO, un server NON DEVE avviare messaggi di richiesta DSO o messaggi DSO unidirezionali fino a quando una Sessione DSO non sia stata stabilita reciprocamente da almeno uno scambio richiesta/risposta DSO riuscito avviato dal client, come descritto di seguito. Ciò è denominato stabilimento di Sessione DSO esplicito.
Fino a quando una Sessione DSO non sia stata stabilita implicitamente o esplicitamente, un client NON DEVE avviare messaggi DSO unidirezionali.
Una Sessione DSO viene stabilita su una connessione tramite il client che invia un messaggio di richiesta DSO, come un messaggio di richiesta DSO Keepalive (Sezione 7.1), e riceve una risposta con un MESSAGE ID corrispondente e RCODE impostato su NOERROR (0), indicando che la richiesta DSO è riuscita.
Alcuni messaggi DSO sono consentiti come dati anticipati (early data) (Sezione 11.1). Altri no. I messaggi unidirezionali non sono mai consentiti come dati anticipati, a meno che non esista una Sessione DSO implicita.
Se un server riceve un messaggio DSO in dati anticipati il cui TLV Primario non è consentito apparire nei dati anticipati, il server DEVE interrompere forzatamente la connessione. Se un client riceve un messaggio DSO in dati anticipati e non esiste una Sessione DSO implicita, il client DEVE interrompere forzatamente la connessione. Ciò può essere applicato solo su connessioni TLS; pertanto, i server NON DEVONO abilitare TCP Fast Open (TFO) quando sono in ascolto per una connessione che non richiede TLS.
5.1.1. Fallimento Stabilimento Sessione DSO
Se il RCODE di risposta è impostato su NOTIMP (4), o in pratica su qualsiasi valore diverso da NOERROR (0) o DSOTYPENI (definito di seguito), allora il client DEVE presumere che il server non implementi affatto DSO. In questo caso, il client è autorizzato a continuare a inviare messaggi DNS su quella connessione ma NON DEVE emettere ulteriori messaggi DSO su quella connessione.
Se il RCODE nella risposta è impostato su DSOTYPENI ("DSO-TYPE Not Implemented"; RCODE 11), ciò indica che il server supporta DSO ma non implementa il DSO-TYPE del TLV Primario in questo messaggio di richiesta DSO. Un server che implementa DSO NON DEVE restituire DSOTYPENI per un messaggio di richiesta DSO Keepalive perché il TLV Keepalive è obbligatorio da implementare. Ma in futuro, se un client tenta di stabilire una Sessione DSO utilizzando un messaggio di richiesta DSO che richiede risposta utilizzando un DSO-TYPE di nuova definizione che il server non comprende, ciò risulterebbe in una risposta DSOTYPENI. Se il server restituisce DSOTYPENI, allora una Sessione DSO non viene considerata stabilita. Il client è tuttavia autorizzato a continuare a inviare messaggi DNS sulla connessione, inclusi altri messaggi DSO come il DSO Keepalive, che può risultare in una risposta NOERROR riuscita, producendo lo stabilimento di una Sessione DSO.
Quando un messaggio DSO viene ricevuto da un server DNS esistente che non riconosce l'OPCODE DSO, esistono due altri possibili esiti: il server potrebbe non inviare alcuna risposta al messaggio DSO, oppure il server potrebbe interrompere la connessione.
Se il server non invia alcuna risposta al messaggio DSO, il client DOVREBBE attendere 30 secondi, dopo di che si presumerà che il server non supporti DSO. Se il server non risponde entro 30 secondi, si può presumere che non risponderà; ciò lo lascia in uno stato non specificato: non esiste alcuna specifica che richieda l'invio di una risposta a un messaggio sconosciuto, ma non esiste nemmeno alcuna specifica che indichi in quale stato si trovi il server se non viene inviata alcuna risposta. Pertanto, il client DEVE interrompere forzatamente la connessione al server. Il client PUÒ riconnettersi ma non utilizzare DSO, se appropriato (Sezione 6.6.3.1). Disconnettendosi e riconnettendosi, il client garantisce che il server sia in uno stato noto prima di inviare qualsiasi richiesta successiva.
Se il server interrompe la connessione, il client DOVREBBE contrassegnare quell'istanza di servizio come non supportante DSO e non tentare una connessione DSO per un certo periodo di tempo (almeno un'ora) dopo il tentativo fallito. Il client PUÒ riconnettersi ma non utilizzare DSO, se appropriato (Sezione 6.6.3.2).
5.1.2. Successo Stabilimento Sessione DSO
Quando il server riceve un messaggio di richiesta DSO da un client e trasmette una risposta NOERROR riuscita a quella richiesta, il server considera la Sessione DSO stabilita.
Quando il client riceve la risposta NOERROR del server al suo messaggio di richiesta DSO, il client considera la Sessione DSO stabilita.
Una volta stabilita una Sessione DSO, ciascuna estremità può inviare unilateralmente messaggi DSO appropriati in qualsiasi momento, e pertanto sia il client che il server possono essere l'iniziatore di un messaggio.
5.2. Operazioni dopo lo Stabilimento della Sessione DSO (Operations after DSO Session Establishment)
Una volta stabilita una Sessione DSO, i client e i server dovrebbero comportarsi come descritto in questa specifica per quanto riguarda i timeout di inattività e la terminazione della sessione, non come precedentemente prescritto nella specifica precedente per DNS-over-TCP [RFC7766].
Poiché un server che supporta le Operazioni DNS con Stato DEVE restituire un RCODE di "NOERROR" quando riceve un messaggio di richiesta DSO con TLV Keepalive, il TLV Keepalive è un candidato ideale per l'uso nello stabilimento di una Sessione DSO. Qualsiasi altra opzione che può avere successo solo quando inviata a un server del tipo desiderato è anche un buon candidato per l'uso nello stabilimento di una Sessione DSO. Per i client che implementano solo i DSO-TYPE definiti in questa specifica di base, l'invio di un TLV Keepalive è l'unico messaggio di richiesta DSO disponibile per avviare una Sessione DSO. Anche per i client che implementano altri DSO-TYPE futuri, per semplicità POSSONO scegliere di inviare sempre un messaggio di richiesta DSO Keepalive iniziale come loro modo di avviare una Sessione DSO. Una futura definizione di un nuovo DSO-TYPE che richiede risposta dà agli implementatori l'opzione di utilizzare quel nuovo DSO-TYPE se lo desiderano, ma non cambia il fatto che l'invio di un TLV Keepalive rimane un modo valido di avviare una Sessione DSO.
5.3. Terminazione Sessione DSO (DSO Session Termination)
Una Sessione DSO viene terminata quando la connessione sottostante viene chiusa. Le Sessioni DSO vengono "chiuse con garbo" a seguito della chiusura da parte del server di una Sessione DSO perché è sovraccarico, a causa della chiusura da parte del client della Sessione DSO perché ha finito, o a causa della chiusura da parte del client della Sessione DSO perché è inattiva. Le Sessioni DSO vengono "interrotte forzatamente" quando il client o il server chiude la connessione a causa di un errore di protocollo.
-
Dove questa specifica dice "chiudere con garbo", significa inviare un TLS close_notify (se è in uso TLS) seguito da un TCP FIN, o l'equivalente per altri protocolli. Dove questa specifica richiede che una connessione venga chiusa con garbo, il requisito di avviare quella chiusura con garbo viene posto sul client al fine di porre l'onere dello stato TIME-WAIT di TCP sul client piuttosto che sul server.
-
Dove questa specifica dice "interrompere forzatamente", significa inviare un TCP RST o l'equivalente per altri protocolli. Nell'API BSD Sockets, ciò viene ottenuto impostando l'opzione SO_LINGER a zero prima di chiudere il socket.
5.3.1. Gestione degli Errori di Protocollo (Handling Protocol Errors)
Nell'implementazione del protocollo, ci sono generalmente due tipi di errori con cui gli sviluppatori di software devono confrontarsi. Il primo riguarda situazioni che sorgono a causa di fattori nell'ambiente, come la perdita temporanea di connettività. Sebbene indesiderabili, queste situazioni non indicano un difetto nel software e sono situazioni da cui il software dovrebbe generalmente essere in grado di recuperare.
Il secondo riguarda situazioni che non dovrebbero mai verificarsi quando si comunica con un'implementazione DSO conforme. Se si verificano, indicano un grave difetto nell'implementazione del protocollo oltre a ciò che è ragionevole aspettarsi che il software possa recuperare. Questo documento descrive quest'ultima forma di condizione di errore come "errore fatale" e specifica che un'implementazione che incontra una condizione di errore fatale "DEVE interrompere forzatamente la connessione immediatamente".
5.4. Formato del Messaggio (Message Format)
Un messaggio DSO inizia con l'intestazione standard del messaggio DNS di dodici byte [RFC1035] con il campo OPCODE impostato sull'OPCODE DSO (6). Tuttavia, a differenza dei messaggi DNS standard, la sezione domanda, la sezione risposta, la sezione record di autorità e la sezione record aggiuntivi non sono presenti. I campi di conteggio corrispondenti (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) DEVONO essere impostati a zero durante la trasmissione.
Se viene ricevuto un messaggio DSO in cui uno qualsiasi dei campi di conteggio non è zero, allora DEVE essere restituito un FORMERR.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| MESSAGE ID |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
|QR | OPCODE (6) | Z | RCODE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| QDCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ANCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| NSCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| ARCOUNT (MUST be zero) |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO Data /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
5.4.1. Campi Intestazione DNS nei Messaggi DSO (DNS Header Fields in DSO Messages)
In un messaggio DSO unidirezionale, il campo MESSAGE ID DEVE essere impostato a zero. In un messaggio di richiesta DSO, il campo MESSAGE ID DEVE essere impostato su un valore univoco non zero che l'iniziatore non sta attualmente utilizzando per nessun'altra operazione attiva su questa connessione. Ai fini qui presenti, un MESSAGE ID è in uso in questa Sessione DSO se l'iniziatore lo ha utilizzato in un messaggio di richiesta DSO per il quale sta ancora aspettando una risposta, o se il client lo ha utilizzato per configurare un'operazione di lunga durata che non è stata ancora annullata. Ad esempio, un'operazione di lunga durata potrebbe essere una sottoscrizione Push Notification [Push] o una sottoscrizione interfaccia Discovery Relay [Relay].
Se un messaggio è un messaggio di richiesta DSO o un messaggio DSO unidirezionale è determinato solo dalla specifica del TLV Primario. Un riconoscimento non può essere richiesto includendo un MESSAGE ID non zero in un messaggio che è richiesto secondo il suo TLV Primario di essere unidirezionale. Né può essere impedito un riconoscimento inviando un MESSAGE ID di zero in un messaggio che è richiesto di essere un messaggio di richiesta DSO secondo il suo TLV Primario. Un risponditore che riceve uno di questi messaggi mal formati DEVE trattarlo come un errore fatale e interrompere forzatamente la connessione immediatamente.
In un messaggio di richiesta DSO o messaggio DSO unidirezionale, il bit Query/Response (QR) dell'intestazione DNS DEVE essere zero (QR=0). Se il bit QR non è zero, il messaggio non è un messaggio di richiesta DSO o un messaggio DSO unidirezionale.
In un messaggio di risposta DSO, il bit QR dell'intestazione DNS DEVE essere uno (QR=1). Se il bit QR non è uno, il messaggio non è un messaggio di risposta DSO.
In un messaggio di risposta DSO (QR=1), il campo MESSAGE ID NON DEVE essere zero e DEVE contenere una copia del valore del campo MESSAGE ID (non zero) nel messaggio di richiesta DSO a cui si risponde. Se viene ricevuto un messaggio di risposta DSO (QR=1) in cui il MESSAGE ID è zero, questo è un errore fatale e il destinatario DEVE interrompere forzatamente la connessione immediatamente.
Il campo OPCODE dell'intestazione DNS contiene il valore OPCODE DSO (6).
I bit Z sono attualmente inutilizzati nei messaggi DSO; sia nei messaggi di richiesta DSO che nelle risposte DSO, i bit Z DEVONO essere impostati a zero (0) durante la trasmissione e DEVONO essere ignorati alla ricezione.
In un messaggio di richiesta DSO (QR=0), il RCODE è impostato secondo la definizione della richiesta. Ad esempio, in un messaggio Retry Delay (Sezione 6.6.1), il RCODE indica il motivo della terminazione. Tuttavia, nella maggior parte dei messaggi di richiesta DSO (QR=0), tranne dove chiaramente specificato diversamente, il RCODE è impostato a zero durante la trasmissione e ignorato silenziosamente alla ricezione.
Il valore RCODE in un messaggio di risposta (QR=1) può essere uno dei seguenti valori:
| Codice | Mnemonico | Descrizione |
|---|---|---|
| 0 | NOERROR | Operazione elaborata con successo |
| 1 | FORMERR | Errore di formato |
| 2 | SERVFAIL | Il server non è riuscito a elaborare il messaggio di richiesta DSO a causa di un problema con il server |
| 4 | NOTIMP | DSO non supportato |
| 5 | REFUSED | Operazione rifiutata per motivi di policy |
| 11 | DSOTYPENI | Il DSO-Type del TLV Primario non è implementato |
L'uso dei RCODE sopra menzionati è probabilmente comune in DSO ma non preclude la definizione e l'uso di altri codici in documenti futuri che utilizzano DSO.
Se un documento che definisce un nuovo DSO-TYPE utilizza codici di risposta non definiti qui, allora quel documento DEVE specificare l'interpretazione specifica di quei valori RCODE nel contesto di quel nuovo TLV DSO.
Il campo RCODE è seguito dai quattro campi di conteggio a valore zero, seguiti dai Dati DSO.
5.4.2. Dati DSO (DSO Data)
L'intestazione standard del messaggio DNS di dodici byte con i suoi campi di conteggio a valore zero è seguita dai Dati DSO, espressi utilizzando la sintassi TLV, come descritto nella Sezione 5.4.4.
Un messaggio di richiesta DSO o un messaggio DSO unidirezionale DEVE contenere almeno un TLV. Il primo TLV in un messaggio di richiesta DSO o un messaggio DSO unidirezionale è denominato "TLV Primario" e determina la natura dell'operazione eseguita, incluso se si tratta di una richiesta DSO o di un'operazione DSO unidirezionale. In alcuni casi, può essere appropriato includere altri TLV in un messaggio di richiesta DSO o un messaggio DSO unidirezionale, come il TLV DSO Encryption Padding (Sezione 7.3). I TLV aggiuntivi seguono il TLV Primario. I TLV aggiuntivi non sono limitati a quanto definito in questo documento. Nuovi TLV Aggiuntivi possono essere definiti in futuro. Le loro definizioni descriveranno quando il loro uso è appropriato.
Un TLV Primario non riconosciuto risulta in una risposta di errore DSOTYPENI. I TLV Aggiuntivi non riconosciuti vengono ignorati silenziosamente, come descritto nelle Sezioni 5.4.5 e 8.2.
Un messaggio di risposta DSO può non contenere TLV, oppure può contenere uno o più TLV, appropriati alle informazioni comunicate.
Qualsiasi TLV con lo stesso DSO-TYPE del TLV Primario dal corrispondente messaggio di richiesta DSO sono TLV Primari di Risposta e DEVONO apparire per primi in un messaggio di risposta DSO. Un messaggio di risposta DSO può contenere più TLV Primari di Risposta, o un singolo TLV Primario di Risposta, o in alcuni casi, nessun TLV Primario di Risposta. Un TLV Primario di Risposta non è richiesto; per la maggior parte delle operazioni DSO il campo MESSAGE ID nell'intestazione del messaggio DNS è sufficiente per identificare il messaggio di richiesta DSO a cui si riferisce un particolare messaggio di risposta.
Qualsiasi altro TLV in un messaggio di risposta DSO sono TLV Aggiuntivi di Risposta, come il TLV DSO Encryption Padding (Sezione 7.3). I TLV Aggiuntivi di Risposta seguono i TLV Primari di Risposta, se presenti. I TLV Aggiuntivi di Risposta non sono limitati a quanto definito in questo documento. Nuovi TLV Aggiuntivi di Risposta possono essere definiti in futuro. Le loro definizioni descriveranno quando il loro uso è appropriato. I TLV Aggiuntivi di Risposta non riconosciuti vengono ignorati silenziosamente, come descritto nelle Sezioni 5.4.5 e 8.2.
La specifica per ciascun TLV DSO determina quali TLV sono richiesti in una risposta a un messaggio di richiesta DSO che utilizza quel TLV. Se viene ricevuta una risposta DSO per un'operazione in cui la specifica richiede che la risposta contenga un particolare TLV o TLV, e i TLV richiesti non sono presenti, allora questo è un errore fatale e il destinatario del messaggio di risposta difettoso DEVE interrompere forzatamente la connessione immediatamente. Allo stesso modo, se sono presenti più del numero specificato di istanze di un dato TLV, questo è un errore fatale e il destinatario del messaggio di risposta difettoso DEVE interrompere forzatamente la connessione immediatamente.
5.4.3. Messaggi DSO Unidirezionali (DSO Unidirectional Messages)
Si prevede che la maggior parte delle operazioni DSO sarà specificata per utilizzare messaggi di richiesta DSO, che generano risposte DSO corrispondenti. In alcuni casi d'uso specializzati ad alto traffico, può essere appropriato specificare messaggi DSO unidirezionali. I messaggi DSO unidirezionali possono essere più efficienti sulla rete perché non generano un flusso di messaggi di risposta corrispondenti. L'uso di messaggi DSO unidirezionali può anche semplificare il software in alcuni casi eliminando la necessità per un iniziatore di mantenere lo stato mentre attende di ricevere risposte di cui non si preoccupa. Quando la specifica per un particolare TLV utilizzato come TLV Primario (cioè primo) in un messaggio di richiesta DSO in uscita (cioè QR=0) afferma che un messaggio deve essere unidirezionale, il campo MESSAGE ID DEVE essere impostato a zero e il ricevitore NON DEVE generare alcun messaggio di risposta corrispondente a quel messaggio DSO unidirezionale.
Il punto precedente, secondo cui il ricevitore NON DEVE generare risposte ai messaggi DSO unidirezionali, si applica anche in caso di errori.
Quando viene ricevuto un messaggio DSO in cui sia il bit QR che il campo MESSAGE ID sono zero, il ricevitore NON DEVE generare alcuna risposta. Ad esempio, se il DSO-TYPE nel TLV Primario non è riconosciuto, allora un errore DSOTYPENI NON DEVE essere restituito; invece, il ricevitore DEVE interrompere forzatamente la connessione immediatamente.
I messaggi DSO unidirezionali NON DEVONO essere utilizzati "speculativamente" nei casi in cui il mittente non sa se il ricevitore supporta il TLV Primario nel messaggio perché non c'è modo di ricevere alcuna risposta per indicare successo o fallimento. I messaggi DSO unidirezionali sono appropriati solo nei casi in cui il mittente sa già che il ricevitore supporta e desidera ricevere questi messaggi.
Ad esempio, dopo che un client si è abbonato alle Notifiche Push [Push], le successive notifiche di eventi vengono quindi inviate come messaggi DSO unidirezionali. Ciò è appropriato perché il client ha avviato il flusso di messaggi in virtù della sua sottoscrizione Push Notification, indicando così il suo supporto delle Notifiche Push e il suo desiderio di ricevere quelle notifiche.
Allo stesso modo, dopo che un client Discovery Relay si è abbonato per ricevere traffico mDNS (multicast DNS) [RFC6762] in entrata da un Discovery Relay, il flusso successivo di pacchetti ricevuti viene quindi inviato utilizzando messaggi DSO unidirezionali. Ciò è appropriato perché il client ha avviato il flusso di messaggi in virtù della sua sottoscrizione link Discovery Relay, indicando così il suo supporto di Discovery Relay e il suo desiderio di ricevere pacchetti mDNS in entrata su quella Sessione DSO [Relay].
5.4.4. Sintassi TLV (TLV Syntax)
Tutti i TLV, sia utilizzati come "Primario", "Aggiuntivo", "Primario di Risposta" o "Aggiuntivo di Risposta", utilizzano la stessa sintassi di codifica.
Una specifica che definisce un nuovo TLV deve specificare se il DSO-TYPE può essere utilizzato come TLV Primario e se il DSO-TYPE può essere utilizzato come TLV Aggiuntivo. Alcuni DSO-TYPE sono a doppio scopo e possono essere utilizzati come TLV Primari in alcuni messaggi e in altri messaggi come TLV Aggiuntivi. La specifica per un DSO-TYPE deve anche indicare se, quando utilizzato come TLV Primario (cioè primo) in un messaggio DSO (cioè QR=0), quel messaggio DSO è unidirezionale, o è un messaggio di richiesta DSO che richiede una risposta.
Se un messaggio di richiesta DSO richiede una risposta, la specifica deve anche indicare quali TLV, se presenti, devono essere inclusi nella risposta e quante istanze di ciascuno dei TLV sono consentite. Il TLV Primario può o non può essere contenuto nella risposta a seconda di ciò che è specificato per quel TLV. Se sono consentite più istanze del TLV Primario, la specifica dovrebbe descrivere chiaramente come dovrebbero essere elaborate.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-TYPE |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSO-LENGTH |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| |
/ DSO-DATA /
/ /
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
DSO-TYPE: Un intero senza segno a 16 bit, in ordine di byte di rete (big endian), che fornisce il DSO-TYPE del TLV DSO corrente secondo il registro IANA "DSO Type Codes".
DSO-LENGTH: Un intero senza segno a 16 bit, in ordine di byte di rete (big endian), che fornisce la dimensione in byte del DSO-DATA.
DSO-DATA: Formato specifico del codice di tipo. Il meccanismo DSO generico tratta il DSO-DATA come un "blob" opaco senza tentare di interpretarlo. L'interpretazione del significato del DSO-DATA per un particolare DSO-TYPE è responsabilità del software che implementa quel DSO-TYPE.
5.4.5. TLV Non Riconosciuti (Unrecognized TLVs)
Se viene ricevuto un messaggio di richiesta DSO contenente un TLV Primario non riconosciuto, con un MESSAGE ID non zero (indicando che è attesa una risposta), allora il ricevitore DEVE inviare una risposta di errore con un MESSAGE ID corrispondente e RCODE DSOTYPENI. La risposta di errore NON DEVE contenere una copia del TLV Primario non riconosciuto.
Se viene ricevuto un messaggio DSO unidirezionale contenente sia un TLV Primario non riconosciuto che un MESSAGE ID zero (indicando che non è attesa alcuna risposta), allora questo è un errore fatale e il destinatario DEVE interrompere forzatamente la connessione immediatamente.
Se viene ricevuto un messaggio di richiesta DSO o un messaggio DSO unidirezionale in cui il TLV Primario è riconosciuto, contenente uno o più TLV Aggiuntivi non riconosciuti, i TLV Aggiuntivi non riconosciuti DEVONO essere ignorati silenziosamente e il resto del messaggio viene interpretato e gestito come se le parti non riconosciute non fossero presenti.
Allo stesso modo, se viene ricevuto un messaggio di risposta DSO contenente uno o più TLV non riconosciuti, i TLV non riconosciuti DEVONO essere ignorati silenziosamente e il resto del messaggio viene interpretato e gestito come se le parti non riconosciute non fossero presenti.
5.4.6. EDNS(0) e TSIG
Poiché il campo ARCOUNT DEVE essere zero, un messaggio DSO non può contenere un'opzione EDNS(0) valida nella sezione record aggiuntivi. Se è desiderata una funzionalità fornita dalle opzioni EDNS(0) attuali o future per i messaggi DSO, devono essere definiti uno o più nuovi TLV DSO per trasportare le informazioni necessarie.
Ad esempio, l'opzione EDNS(0) Padding [RFC7830] utilizzata per scopi di sicurezza non è consentita in un messaggio DSO, quindi se è desiderato il padding del messaggio per i messaggi DSO, allora DEVE essere utilizzato il TLV DSO Encryption Padding descritto nella Sezione 7.3.
Un messaggio DSO non può contenere un record TSIG perché un record TSIG è incluso nella sezione aggiuntiva del messaggio, il che significherebbe che ARCOUNT sarebbe maggiore di zero. I messaggi DSO sono tenuti ad avere un ARCOUNT di zero. Pertanto, se l'uso di firme con messaggi DSO diventa necessario in futuro, dovrebbe essere definito un nuovo TLV DSO per svolgere questa funzione.
Si noti tuttavia che, mentre i messaggi DSO non possono includere record EDNS(0) o TSIG, una sessione DSO viene tipicamente utilizzata per trasportare un'intera serie di messaggi DNS di diversi tipi, inclusi messaggi DSO e altri tipi di messaggi DNS come Query [RFC1034] [RFC1035] e Update [RFC2136]. Questi messaggi possono trasportare record EDNS(0) e TSIG.
Sebbene i messaggi possano contenere altre opzioni EDNS(0) come appropriato, questa specifica vieta esplicitamente l'uso dell'opzione EDNS(0) edns-tcp-keepalive [RFC7828] in tutti i messaggi inviati su una Sessione DSO (perché è resa obsoleta dalla funzionalità fornita dall'operazione DSO Keepalive). Se un messaggio inviato su una Sessione DSO contiene un'opzione EDNS(0) edns-tcp-keepalive, questo è un errore fatale e il destinatario del messaggio difettoso DEVE interrompere forzatamente la connessione immediatamente.
5.5. Gestione dei Messaggi (Message Handling)
Come descritto nella Sezione 5.4.1, se un messaggio DSO in uscita con il bit QR nell'intestazione DNS impostato a zero è una richiesta DSO o un messaggio DSO unidirezionale è determinato dalla specifica del TLV Primario, che a sua volta determina se il campo MESSAGE ID in quel messaggio in uscita sarà zero o non zero.
Ogni messaggio DSO con il bit QR nell'intestazione DNS impostato a zero e un campo MESSAGE ID non zero è un messaggio di richiesta DSO e DEVE suscitare una risposta corrispondente, con il bit QR nell'intestazione DNS impostato a uno e il campo MESSAGE ID impostato sul valore fornito nel corrispondente messaggio di richiesta DSO.
I messaggi di richiesta DSO validi inviati dal client con un campo MESSAGE ID non zero suscitano una risposta dal server, e i messaggi di richiesta DSO validi inviati dal server con un campo MESSAGE ID non zero suscitano una risposta dal client.
Ogni messaggio DSO con sia il bit QR nell'intestazione DNS che il campo MESSAGE ID impostati a zero è un messaggio DSO unidirezionale e NON DEVE suscitare una risposta.
5.5.1. Gestione del Riconoscimento Ritardato (Delayed Acknowledgement Management)
In generale, la maggior parte delle buone implementazioni TCP impiega un timer di riconoscimento ritardato per fornire un uso più efficiente della rete e prestazioni migliori.
Con uno scambio bidirezionale su TCP, come con un messaggio di richiesta DSO, l'implementazione TCP del sistema operativo attende che il software client del livello applicazione generi il corrispondente messaggio di risposta DSO. L'implementazione TCP può quindi inviare un singolo pacchetto combinato contenente il riconoscimento TCP, l'aggiornamento della finestra TCP e il messaggio di risposta DSO generato dall'applicazione. Questo è più efficiente dell'invio di tre pacchetti separati, come si verificherebbe se il pacchetto TCP contenente la richiesta DSO fosse riconosciuto immediatamente.
Con un messaggio DSO unidirezionale o un messaggio di risposta DSO, non c'è alcun corrispondente messaggio di risposta DSO generato dall'applicazione e, di conseguenza, nessun suggerimento al protocollo di trasporto su quando dovrebbe inviare il suo riconoscimento e aggiornamento della finestra.
Alcune API di rete forniscono un meccanismo che consente al software client del livello applicazione di segnalare al protocollo di trasporto che non arriverà alcuna risposta (in effetti può essere considerato come una "scrittura vuota" di lunghezza zero). Dove disponibile nell'API di rete utilizzata, il destinatario di un messaggio DSO unidirezionale o di un messaggio di risposta DSO, dopo aver analizzato e interpretato il messaggio, DOVREBBE quindi utilizzare questo meccanismo fornito dall'API di rete per segnalare che non arriverà alcuna risposta per questo messaggio. L'implementazione TCP può quindi procedere a inviare il suo riconoscimento e aggiornamento della finestra senza ulteriore ritardo. Vedere Sezione 9.5 per ulteriore discussione sul perché questo è importante.
5.5.2. Spazi dei Nomi MESSAGE ID (MESSAGE ID Namespaces)
Gli spazi dei nomi dei MESSAGE ID a 16 bit sono indipendenti in ciascuna direzione. Ciò significa che non è un errore per il client e il server inviare messaggi di richiesta DSO allo stesso tempo l'uno dell'altro, utilizzando lo stesso MESSAGE ID, in direzioni diverse. Questa semplificazione è necessaria affinché il protocollo sia implementabile. Sarebbe impraticabile richiedere che il client e il server si coordinino tra loro riguardo all'allocazione di nuovi MESSAGE ID univoci. Non è nemmeno necessario richiedere che il client e il server si coordinino tra loro riguardo all'allocazione di nuovi MESSAGE ID univoci. Il valore del MESSAGE ID a 16 bit combinato con l'identità dell'iniziatore (client o server) è sufficiente per identificare inequivocabilmente l'operazione in questione. Questo può essere considerato come uno spazio di identificatori di messaggi a 17 bit che utilizza identificatori di messaggi 0x00001-0x0FFFF per i messaggi di richiesta DSO dal client al server e 0x10001-0x1FFFF per i messaggi di richiesta DSO dal server al client. I 16 bit meno significativi sono memorizzati esplicitamente nel campo MESSAGE ID del messaggio DSO e il bit più significativo è implicito dalla direzione del messaggio.
Come descritto nella Sezione 5.4.1, un iniziatore NON DEVE riutilizzare un MESSAGE ID che ha già in uso per un messaggio di richiesta DSO in sospeso (a meno che non sia specificato diversamente dalla specifica pertinente per il DSO-TYPE in questione). Come minimo, ciò significa che un MESSAGE ID non può essere riutilizzato in una particolare direzione su una particolare Sessione DSO mentre l'iniziatore sta aspettando una risposta a un precedente messaggio di richiesta DSO che utilizza quel MESSAGE ID su quella Sessione DSO (a meno che non sia specificato diversamente dalla specifica pertinente per il DSO-TYPE in questione), e per un'operazione di lunga durata, il MESSAGE ID per l'operazione non può essere riutilizzato mentre quell'operazione rimane attiva.
Se un client o un server riceve una risposta (QR=1) in cui il MESSAGE ID è zero, o è qualsiasi altro valore che non corrisponde al MESSAGE ID di nessuna delle sue operazioni in sospeso, questo è un errore fatale e il destinatario DEVE interrompere forzatamente la connessione immediatamente.
Se un risponditore riceve un messaggio di richiesta DSO (QR=0) in cui il MESSAGE ID non è zero, il risponditore tiene traccia dei MESSAGE ID delle richieste, e il MESSAGE ID corrisponde al MESSAGE ID di un messaggio di richiesta DSO che ha ricevuto per il quale non è stata ancora inviata una risposta, DEVE interrompere forzatamente la connessione immediatamente. Questo comportamento è richiesto per prevenire un ipotetico attacco che sfrutta un comportamento indefinito in questo caso. Tuttavia, se il risponditore non tiene traccia dei MESSAGE ID in questo modo, non esiste tale rischio. Pertanto, il monitoraggio dei MESSAGE ID solo per implementare questo controllo di sanità non è richiesto.
5.5.3. Risposte di Errore (Error Responses)
Quando un messaggio di richiesta DSO non ha successo per qualche motivo, il risponditore restituisce un codice di errore all'iniziatore.
Nel caso di un server che restituisce un codice di errore a un client in risposta a un messaggio di richiesta DSO non riuscito, il server PUÒ scegliere di terminare la Sessione DSO o PUÒ scegliere di consentire alla Sessione DSO di rimanere aperta. Per condizioni di errore che influenzano solo la singola operazione in questione, il server DOVREBBE restituire una risposta di errore al client e lasciare la Sessione DSO aperta per ulteriori operazioni.
Per condizioni di errore che probabilmente renderanno tutte le operazioni non riuscite nel prossimo futuro, il server DOVREBBE restituire una risposta di errore al client e quindi terminare la Sessione DSO inviando un messaggio Retry Delay come descritto nella Sezione 6.6.1.
Dopo aver ricevuto una risposta di errore dal server, un client NON DOVREBBE chiudere automaticamente la Sessione DSO. Un errore relativo a una particolare operazione su una Sessione DSO non implica necessariamente che tutte le altre operazioni su quella Sessione DSO siano anch'esse fallite o che le operazioni future falliranno. Il client dovrebbe presumere che il server prenderà la propria decisione se terminare o meno la Sessione DSO in base alla determinazione del server se la condizione di errore riguarda questa particolare operazione o eventuali operazioni successive. Se il server non termina la Sessione DSO inviando al client un messaggio Retry Delay (Sezione 6.6.1), allora il client DOVREBBE continuare a utilizzare quella Sessione DSO per operazioni successive.
Quando viene ricevuto un tipo di messaggio DSO unidirezionale (il campo MESSAGE ID è zero), il ricevitore dovrebbe già aspettarsi questo tipo di messaggio DSO. La Sezione 5.4.5 descrive la gestione dei tipi di messaggi DSO sconosciuti. Quando viene ricevuto un messaggio DSO unidirezionale di un tipo imprevisto, il ricevitore DOVREBBE interrompere forzatamente la connessione. Se la connessione dovrebbe essere interrotta forzatamente per altri errori interni nell'elaborazione del messaggio DSO unidirezionale dipende dall'implementazione secondo la gravità dell'errore.
5.6. Cancellazione Operazione Iniziata dal Risponditore (Responder-Initiated Operation Cancellation)
Questo documento, la specifica di base per le Operazioni DNS con Stato, non definisce di per sé alcuna operazione di lunga durata, ma definisce un framework per supportare operazioni di lunga durata come sottoscrizioni Push Notification [Push] e sottoscrizioni interfaccia Discovery Relay [Relay].
Le operazioni di lunga durata, se riuscite, rimarranno attive finché l'iniziatore non termina l'operazione.
Tuttavia, è possibile che un'operazione di lunga durata possa essere valida al momento in cui è stata avviata, ma poi un successivo cambiamento di circostanze può rendere quell'operazione invalida. Ad esempio, un'operazione client di lunga durata può riguardare un nome per il quale il server è autorevole, ma poi la configurazione del server viene modificata in modo tale che non sia più autorevole per quel nome.
In tali casi, invece di terminare l'intera sessione, può essere desiderabile per il risponditore essere in grado di cancellare selettivamente solo quelle operazioni che sono diventate invalide.
Il risponditore esegue questa cancellazione selettiva inviando un nuovo messaggio di risposta DSO con il campo MESSAGE ID contenente il MESSAGE ID dell'operazione di lunga durata che deve essere terminata (che aveva precedentemente riconosciuto con un RCODE NOERROR) e il campo RCODE del nuovo messaggio di risposta DSO che fornisce il motivo della cancellazione.
Dopo che un messaggio di risposta DSO con RCODE non zero è stato inviato, quell'operazione è stata terminata dal punto di vista del risponditore, e il risponditore non invia più messaggi relativi a quell'operazione.
Dopo che un messaggio di risposta DSO con RCODE non zero è stato ricevuto dall'iniziatore, quell'operazione è stata terminata dal punto di vista dell'iniziatore, e il MESSAGE ID dell'operazione cancellata è ora libero per il riutilizzo.