Passa al contenuto principale

7. TLV di Base per le Operazioni DNS con Stato (Base TLVs for DNS Stateful Operations)

Questa sezione descrive i tre TLV di base per le Operazioni DNS con Stato: Keepalive, Retry Delay ed Encryption Padding.

7.1. Keepalive TLV​

Il Keepalive TLV (DSO-TYPE=1) svolge due funzioni. Principalmente, stabilisce i valori per i Session Timeout. Incidentalmente, reimposta anche il timer keepalive per la Sessione DSO, il che significa che può essere utilizzato come una sorta di messaggio "no-op" allo scopo di mantenere attiva una sessione. Il client richiederà i valori Session Timeout desiderati e il server riconoscerà con i valori di risposta che richiede al client di utilizzare.

I messaggi DSO con il Keepalive TLV come TLV Primario possono apparire nei dati anticipati (early data).

Il DSO-DATA per il Keepalive TLV è il seguente:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 INACTIVITY TIMEOUT (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 KEEPALIVE INTERVAL (32 bits)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  • INACTIVITY TIMEOUT: Il timeout di inattività per la Sessione DSO corrente, specificato come un intero senza segno a 32 bit, in ordine di byte di rete (big endian) in unità di millisecondi. Questo è il timeout al quale il client DEVE iniziare a chiudere una Sessione DSO inattiva. Il timeout di inattività può essere qualsiasi valore scelto dal server. Se il client non chiude con garbo una Sessione DSO inattiva, dopo cinque secondi o il doppio di questo intervallo, qualunque sia maggiore, il server interromperà forzatamente la connessione.

  • KEEPALIVE INTERVAL: L'intervallo keepalive per la Sessione DSO corrente, specificato come un intero senza segno a 32 bit, in ordine di byte di rete (big endian) in unità di millisecondi. Questo è l'intervallo al quale un client DEVE generare traffico DSO keepalive per mantenere lo stato di connessione. L'intervallo keepalive NON DEVE essere inferiore a dieci secondi. Se il client non genera il traffico DSO keepalive prescritto, dopo il doppio di questo intervallo il server interromperà forzatamente la connessione. Poiché l'intervallo keepalive minimo consentito è di dieci secondi, il tempo minimo al quale un server disconnetterà forzatamente un client per non aver generato il traffico DSO keepalive prescritto è di venti secondi.

La trasmissione o la ricezione di messaggi DSO Keepalive (cioè messaggi in cui il Keepalive TLV è il primo TLV) reimposta solo il timer keepalive, non il timer di inattività. La ragione di ciò è che i messaggi DSO Keepalive periodici vengono inviati al solo scopo di mantenere attiva una Sessione DSO quando quella Sessione DSO ha attività corrente o recente non di manutenzione che giustifica il mantenimento attiva di quella Sessione DSO. L'invio del traffico DSO keepalive stesso non è considerato un'attività del client; è considerato un'attività di manutenzione che viene eseguita al servizio di altre attività del client. Se il traffico DSO keepalive stesso dovesse reimpostare il timer di inattività, ciò creerebbe un livelock circolare in cui il traffico keepalive verrebbe inviato indefinitamente per mantenere attiva una Sessione DSO. In questo scenario, l'unica attività su quella Sessione DSO sarebbe il traffico keepalive che mantiene attiva la Sessione DSO in modo che ulteriore traffico keepalive possa essere inviato. Affinché una Sessione DSO sia considerata attiva, deve trasportare qualcosa di più del semplice traffico keepalive. Questo è il motivo per cui il semplice invio o la ricezione di un messaggio DSO Keepalive non reimposta il timer di inattività.

Quando inviato da un client, il messaggio di richiesta DSO Keepalive DEVE essere inviato come messaggio di richiesta DSO con un MESSAGE ID non zero. Se un server riceve un messaggio DSO Keepalive con un MESSAGE ID zero, allora questo è un errore fatale e il server DEVE interrompere forzatamente la connessione immediatamente. Il messaggio di richiesta DSO Keepalive reimposta il timer keepalive di una Sessione DSO e, allo stesso tempo, comunica al server i valori Session Timeout richiesti dal client. In una risposta del server a un messaggio di richiesta DSO Keepalive iniziato dal client, i Session Timeout contengono i valori scelti dal server da questo punto in avanti nella Sessione DSO, che il client DEVE rispettare. Questo è modellato sul protocollo DHCP, dove il client richiede una certa durata del lease utilizzando l'opzione DHCP 51 [RFC2132], ma il server è l'autorità finale per decidere quale durata del lease viene effettivamente concessa.

Quando un client invia il secondo e i successivi messaggi di richiesta DSO Keepalive al server, il client DOVREBBE continuare a richiedere i suoi valori preferiti ogni volta. Ciò consente flessibilità in modo che se le condizioni cambiano durante la vita di una Sessione DSO, il server possa adattare le sue risposte per soddisfare meglio le esigenze del client.

Una volta che una Sessione DSO è in corso (Sezione 5.1), un messaggio DSO Keepalive PUÒ essere iniziato da un server. Quando inviato da un server, il messaggio DSO Keepalive DEVE essere inviato come messaggio DSO unidirezionale con il MESSAGE ID impostato a zero. Il client NON DEVE generare una risposta a un messaggio DSO Keepalive iniziato dal server. Se un client riceve un messaggio di richiesta DSO Keepalive con un MESSAGE ID non zero, allora questo è un errore fatale e il client DEVE interrompere forzatamente la connessione immediatamente. Il messaggio DSO Keepalive unidirezionale dal server reimposta il timer keepalive di una Sessione DSO e, allo stesso tempo, informa unilateralmente il client dei nuovi valori Session Timeout da utilizzare da questo punto in avanti in questa Sessione DSO. Nessuna risposta DSO del client a questa dichiarazione unilaterale è richiesta o consentita.

Nei messaggi di risposta DSO Keepalive, esattamente un'istanza del Keepalive TLV DEVE essere presente ed è utilizzata solo come TLV Primario di Risposta inviato come risposta a un messaggio di richiesta DSO Keepalive dal client. Un Keepalive TLV NON DEVE essere aggiunto ad altre risposte come TLV Aggiuntivo di Risposta. Se il server desidera aggiornare i valori Session Timeout di un client diversamente da una risposta a un messaggio di richiesta DSO Keepalive dal client, lo fa inviando un proprio messaggio DSO Keepalive unidirezionale, come descritto sopra.

Non è richiesto che il Keepalive TLV sia utilizzato in ogni Sessione DSO. Mentre molte operazioni DSO saranno utilizzate in congiunzione con uno stato di sessione di lunga durata, non tutte le operazioni DSO richiedono uno stato di sessione di lunga durata, e in alcuni casi il valore predefinito di 15 secondi sia per il timeout di inattività che per l'intervallo keepalive può essere perfettamente appropriato. Tuttavia, si noti che per i client che implementano solo i DSO-TYPE definiti in questo documento, un messaggio di richiesta DSO Keepalive è l'unico modo per un client di avviare una Sessione DSO.

7.1.1. Gestione da Parte del Client dei Valori Session Timeout Ricevuti​

Quando un client riceve una risposta al suo messaggio di richiesta DSO Keepalive iniziato dal client, o riceve un messaggio DSO Keepalive unidirezionale iniziato dal server, il client ha quindi ricevuto valori Session Timeout dettati dal server. I due valori di timeout contenuti nel Keepalive TLV dal server possono ciascuno essere superiori, inferiori o uguali ai rispettivi valori Session Timeout che il client aveva precedentemente per questa Sessione DSO.

Nel caso del timer keepalive, la gestione del valore ricevuto è semplice. L'atto di ricevere il messaggio contenente il DSO Keepalive TLV stesso reimposta il timer keepalive e aggiorna l'intervallo keepalive per la Sessione DSO. Il nuovo intervallo keepalive indica il tempo massimo che può trascorrere prima che un altro messaggio debba essere inviato o ricevuto su questa Sessione DSO, se la Sessione DSO deve rimanere attiva.

Nel caso del timeout di inattività, la gestione del valore ricevuto è un po' più sottile, sebbene il significato del timeout di inattività rimanga come specificato; indica ancora il tempo massimo consentito senza attività utile su una Sessione DSO. L'atto di ricevere il messaggio contenente il Keepalive TLV non reimposta di per sé il timer di inattività. Il tempo trascorso dall'ultima attività utile su questa Sessione DSO non è influenzato dallo scambio di messaggi DSO Keepalive. Il nuovo valore di timeout di inattività nel Keepalive TLV nel messaggio ricevuto aggiorna tuttavia il timeout associato al timer di inattività in esecuzione; questo diventa il nuovo tempo massimo consentito senza attività su una Sessione DSO.

  • Se il valore corrente del timer di inattività è inferiore al nuovo timeout di inattività, allora la Sessione DSO può rimanere aperta per ora. Quando il valore del timer di inattività raggiunge il nuovo timeout di inattività, il client DEVE quindi iniziare a chiudere la Sessione DSO come descritto sopra.

  • Se il valore corrente del timer di inattività è uguale al nuovo timeout di inattività, allora questa Sessione DSO è stata inattiva esattamente per quanto tempo il server lo consentirà, e ora il client DEVE immediatamente iniziare a chiudere questa Sessione DSO.

  • Se il valore corrente del timer di inattività è già maggiore del nuovo timeout di inattività, allora questa Sessione DSO è già stata inattiva più a lungo di quanto il server consenta, e il client DEVE immediatamente iniziare a chiudere questa Sessione DSO.

  • Se il valore corrente del timer di inattività è già più del doppio del nuovo timeout di inattività, allora il client è immediatamente considerato inadempiente (questa Sessione DSO è immediatamente idonea a essere terminata forzatamente dal server) e il client DEVE immediatamente iniziare a chiudere questa Sessione DSO. Tuttavia, se un server riduce bruscamente il timeout di inattività in questo modo, allora, per dare al client il tempo di chiudere la connessione con garbo prima che il server ricorra a interromperla forzatamente, il server DOVREBBE dare al client un periodo di grazia aggiuntivo di cinque secondi o un quarto del nuovo timeout di inattività, qualunque sia maggiore.

7.1.2. Relazione con l'Opzione EDNS(0) edns-tcp-keepalive​

Il valore del timeout di inattività nel Keepalive TLV (DSO-TYPE=1) ha un intento simile all'Opzione EDNS(0) edns-tcp-keepalive [RFC7828]. Una coppia client/server che supporta DSO NON DEVE utilizzare l'Opzione EDNS(0) edns-tcp-keepalive all'interno di alcun messaggio dopo che una Sessione DSO è stata stabilita. Un client che ha inviato un messaggio DSO per stabilire una sessione NON DEVE inviare un'Opzione EDNS(0) edns-tcp-keepalive da questo punto in poi. Una volta stabilita una Sessione DSO, se il client o il server riceve un messaggio DNS sulla Sessione DSO che contiene un'Opzione EDNS(0) edns-tcp-keepalive, questo è un errore fatale e il ricevitore dell'Opzione EDNS(0) edns-tcp-keepalive DEVE interrompere forzatamente la connessione immediatamente.

7.2. Retry Delay TLV​

Il Retry Delay TLV (DSO-TYPE=2) può essere utilizzato come TLV Primario (unidirezionale) in un messaggio da server a client, o come TLV Aggiuntivo di Risposta in entrambe le direzioni. I messaggi DSO con un Relay Delay TLV come loro TLV Primario non sono consentiti nei dati anticipati.

Il DSO-DATA per il Retry Delay TLV è il seguente:

                        1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     RETRY DELAY (32 bits)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  • RETRY DELAY: Un valore temporale, specificato come un intero senza segno a 32 bit in ordine di byte di rete (big endian), in unità di millisecondi, entro il quale l'iniziatore NON DEVE riprovare questa operazione o riprovare a connettersi a questo server. Le raccomandazioni per il valore RETRY DELAY sono fornite nella Sezione 6.6.1.

7.2.1. Retry Delay TLV Utilizzato come TLV Primario​

Quando utilizzato come TLV Primario in un messaggio DSO unidirezionale, il Retry Delay TLV viene inviato dal server al client. È utilizzato da un server per istruire un client a chiudere la Sessione DSO e la connessione sottostante, e a non riconnettersi per l'intervallo di tempo indicato.

In questo caso, si applica alla Sessione DSO nel suo insieme, e il client DEVE iniziare a chiudere la Sessione DSO come descritto nella Sezione 6.6.1. Il RCODE nell'intestazione del messaggio DOVREBBE indicare la ragione principale per la terminazione:

  • NOERROR indica uno spegnimento o riavvio di routine.

  • FORMERR indica che una richiesta DSO del client era troppo malformata perché la sessione potesse continuare.

  • SERVFAIL indica che il server è sovraccarico a causa dell'esaurimento delle risorse e deve ridurre il carico.

  • REFUSED indica che il server è stato riconfigurato e in questo momento non è più in grado di eseguire una o più delle operazioni client di lunga durata che venivano precedentemente eseguite su questa Sessione DSO.

  • NOTAUTH indica che il server è stato riconfigurato e in questo momento non è più in grado di eseguire una o più delle operazioni client di lunga durata che venivano precedentemente eseguite su questa Sessione DSO perché non ha autorità sui nomi in questione (ad esempio, un server DNS Push Notification potrebbe essere riconfigurato in modo tale da non accettare più richieste DNS Push Notification per uno o più dei nomi attualmente sottoscritti).

Questo documento specifica solo questi valori RCODE per il messaggio DSO Retry Delay. I server che inviano messaggi DSO Retry Delay DOVREBBERO utilizzare uno di questi valori. Tuttavia, circostanze future possono creare situazioni in cui altri valori RCODE sono appropriati nei messaggi DSO Retry Delay, quindi i client DEVONO essere preparati ad accettare messaggi DSO Retry Delay con qualsiasi valore RCODE.

In alcuni casi, quando un server invia un messaggio DSO Retry Delay unidirezionale a un client, potrebbe esserci più di una ragione per cui il server desidera terminare la sessione. Possibilmente, la configurazione potrebbe essere stata modificata in modo tale che alcune operazioni client di lunga durata non possano più essere continuate a causa della politica (REFUSED), e altre operazioni client di lunga durata non possano più essere eseguite a causa del server che non è più autorevole per quei nomi (NOTAUTH). In tali casi, il server PUÒ utilizzare uno qualsiasi dei valori RCODE applicabili, o RCODE=NOERROR (spegnimento o riavvio di routine).

Si noti che la selezione del valore RCODE in un messaggio DSO Retry Delay non è critica poiché il valore RCODE è generalmente utilizzato solo per scopi informativi come la scrittura in un file di log per l'analisi umana futura riguardo alla natura della disconnessione. In generale, i client non modificano il loro comportamento a seconda del valore RCODE. Il RETRY DELAY nel messaggio indica al client quanto tempo dovrebbe attendere prima di tentare una nuova connessione a questa istanza di servizio.

Per i client che in qualche modo modificano il loro comportamento a seconda del valore RCODE, dovrebbero trattare valori RCODE sconosciuti allo stesso modo di RCODE=NOERROR (spegnimento o riavvio di routine).

Un messaggio DSO Retry Delay (messaggio DSO in cui il TLV Primario è Retry Delay) dal server al client è un messaggio DSO unidirezionale; il MESSAGE ID DEVE essere impostato a zero nel messaggio in uscita e il client NON DEVE inviare una risposta.

Un client NON DEVE inviare un messaggio DSO Retry Delay a un server. Se un server riceve un messaggio DSO in cui il TLV Primario è il Retry Delay TLV, questo è un errore fatale e il server DEVE interrompere forzatamente la connessione immediatamente.

7.2.2. Retry Delay TLV Utilizzato come TLV Aggiuntivo di Risposta​

Nel caso di un messaggio di richiesta DSO che risulta in un valore RCODE non zero, il risponditore PUÒ aggiungere un Retry Delay TLV alla risposta, indicando l'intervallo di tempo durante il quale l'iniziatore NON DOVREBBE tentare nuovamente questa operazione.

L'intervallo di tempo indicato durante il quale l'iniziatore NON DOVREBBE riprovare si applica solo all'operazione fallita, non alla Sessione DSO nel suo insieme.

Sia un client che un server, qualunque sia quello che agisce nel ruolo del risponditore per un particolare messaggio di richiesta DSO, PUÒ aggiungere un Retry Delay TLV a una risposta di errore che invia.

7.3. Encryption Padding TLV​

L'Encryption Padding TLV (DSO-TYPE=3) può essere utilizzato solo come TLV Aggiuntivo o TLV Aggiuntivo di Risposta. È applicabile solo quando il livello di trasporto DSO utilizza la crittografia come TLS.

Il DSO-DATA per il Padding TLV è opzionale ed è un campo di lunghezza variabile contenente valori non specificati. Un DSO-LENGTH di 0 fornisce essenzialmente 4 byte di padding (la quantità minima).

                                             1   1   1   1   1   1
     0   1   2   3   4   5   6   7   8   9   0   1   2   3   4   5
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
   |                                                               |
   /              PADDING -- VARIABLE NUMBER OF BYTES              /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Come specificato per l'Opzione EDNS(0) Padding [RFC7830], i byte PADDING DOVREBBERO essere impostati a 0x00. Altri valori POSSONO essere utilizzati, ad esempio, in casi in cui vi sia una preoccupazione che il messaggio imbottito possa essere soggetto a compressione prima della crittografia. I byte PADDING di qualsiasi valore DEVONO essere accettati nei messaggi ricevuti.

L'Encryption Padding TLV può essere incluso in un messaggio di richiesta DSO, risposta o entrambi. Come specificato per l'Opzione EDNS(0) Padding [RFC7830], se viene ricevuto un messaggio di richiesta DSO con un Encryption Padding TLV, allora la risposta DSO DEVE includere anche un Encryption Padding TLV.

La lunghezza del padding non è intenzionalmente specificata in questo documento ed è una funzione delle migliori pratiche correnti rispetto al tipo e alla lunghezza dei dati nei TLV precedenti [RFC8467].

Ultimo aggiornamento il