6.2.2. SUBSCRIBE Response (Risposta SUBSCRIBE)
6.2.2. SUBSCRIBE Response (Risposta SUBSCRIBE)
Una risposta SUBSCRIBE inizia con l'intestazione DSO standard da 12 byte [RFC8490]. Il bit QR nell'intestazione è impostato per indicare che si tratta di una risposta. L'intestazione PUÒ essere seguita da uno o più TLV aggiuntivi opzionali come un TLV aggiuntivo Retry Delay. Una risposta SUBSCRIBE è illustrata nella figura 2.
Il campo MESSAGE ID DEVE ripetere il valore fornito nel campo MESSAGE ID della richiesta SUBSCRIBE. Questo è il modo in cui il client sa a quale richiesta si sta rispondendo.
Gli altri campi dell'intestazione DEVONO essere impostati come descritto nella specifica DSO [RFC8490]. Il campo DNS OPCODE contiene il valore OPCODE per DNS Stateful Operations (6). I quattro campi di conteggio devono essere zero e le quattro sezioni corrispondenti devono essere vuote (cioè assenti).
Un messaggio di risposta SUBSCRIBE NON DEVE includere un TLV SUBSCRIBE. Se un client riceve un messaggio di risposta SUBSCRIBE contenente un TLV SUBSCRIBE, il messaggio di risposta viene elaborato ma il TLV SUBSCRIBE DEVE essere ignorato silenziosamente.
Nella risposta SUBSCRIBE, l'RCODE indica se la sottoscrizione è stata accettata o meno. Gli RCODE supportati sono i seguenti:
| Mnemonico | Valore | Descrizione |
|---|---|---|
| NOERROR | 0 | SUBSCRIBE riuscito. |
| FORMERR | 1 | Il server non è riuscito a elaborare la richiesta a causa di una richiesta malformata. |
| SERVFAIL | 2 | Il server non è riuscito a elaborare la richiesta a causa di un problema con il server. |
| NOTIMP | 4 | Il server non implementa DSO. |
| REFUSED | 5 | Il server rifiuta di elaborare la richiesta per motivi di policy o sicurezza. |
| NOTAUTH | 9 | Il server non è autoritativo per il nome richiesto. |
| DSOTYPENI | 11 | Operazione SUBSCRIBE non supportata. |
Tabella 1: Codici di risposta SUBSCRIBE
Questo documento specifica solo questi valori RCODE per le risposte SUBSCRIBE. I server che inviano risposte SUBSCRIBE DOVREBBERO utilizzare uno di questi valori. Si noti che NXDOMAIN non è un RCODE valido in risposta a una richiesta SUBSCRIBE. Tuttavia, circostanze future possono creare situazioni in cui altri valori RCODE sono appropriati nelle risposte SUBSCRIBE, quindi i client DEVONO essere preparati ad accettare e gestire risposte SUBSCRIBE con qualsiasi altro valore di errore RCODE diverso da zero.
Se il server invia un RCODE diverso da zero nella risposta SUBSCRIBE, ciò significa:
a. il client è (almeno parzialmente) mal configurato, o b. le risorse del server sono esaurite, o c. c'è qualche altro guasto sconosciuto sul server.
In ogni caso, il client non dovrebbe riprovare immediatamente la sottoscrizione a questo server. Se sono stati restituiti più record SRV come descritto nella sezione 6.1, paragrafo 9, punto 7, un server successivo PUÒ essere provato immediatamente.
Se il client ha altre sottoscrizioni riuscite a questo server, queste sottoscrizioni rimangono anche se ulteriori sottoscrizioni possono essere rifiutate. Né il client né il server sono tenuti a chiudere la connessione, anche se entrambe le estremità possono scegliere di farlo.
Se il server invia un RCODE diverso da zero, allora DOVREBBE aggiungere un TLV aggiuntivo Retry Delay [RFC8490] alla risposta specificando un ritardo prima che il client tenti nuovamente questa operazione. I valori raccomandati per il ritardo per diversi valori RCODE sono forniti di seguito. Questi valori raccomandati si applicano sia ai valori predefiniti che un server dovrebbe inserire nel TLV aggiuntivo Retry Delay sia ai valori predefiniti che un client dovrebbe assumere se il server non fornisce alcun TLV aggiuntivo Retry Delay.
Per RCODE = 1 (FORMERR), il ritardo può essere qualsiasi valore selezionato dall'implementatore. Un valore di cinque minuti è RACCOMANDATO per ridurre il rischio di carico elevato da client difettosi.
Per RCODE = 2 (SERVFAIL), il ritardo dovrebbe essere scelto in base al livello di sovraccarico del server e alla durata prevista di tale sovraccarico. Per impostazione predefinita, un valore di un minuto è RACCOMANDATO. Se si verifica un guasto del server più grave, il ritardo può essere più lungo in conformità con il problema specifico riscontrato.
Per RCODE = 4 (NOTIMP), che si verifica su un server che non implementa DNS Stateful Operations [RFC8490], è improbabile che il server inizi a supportare DSO nei prossimi minuti, quindi il ritardo di ripetizione DOVREBBE essere di un'ora. Si noti che in tal caso, un server che non implementa DSO è improbabile che inserisca un TLV aggiuntivo Retry Delay nella sua risposta, quindi questo valore raccomandato in particolare si applica a ciò che un client dovrebbe assumere per impostazione predefinita.
Per RCODE = 5 (REFUSED), che si verifica su un server che implementa DNS Push Notifications ma è attualmente configurato per non consentire DNS Push Notifications, il ritardo di ripetizione può essere qualsiasi valore selezionato dall'implementatore e/o configurato dall'operatore.
Se il server interrogato è elencato in un record SRV "_dns-push-tls._tcp.<zone>" per la zona, allora questa è una configurazione errata, poiché questo server viene pubblicizzato come supporto di DNS Push Notifications per questa zona, ma il server stesso non è attualmente configurato per eseguire tale compito. Poiché è possibile che la configurazione errata venga riparata in qualsiasi momento, il ritardo di ripetizione non dovrebbe essere impostato troppo alto. Per impostazione predefinita, un valore di 5 minuti è RACCOMANDATO.
Per RCODE = 9 (NOTAUTH), che si verifica su un server che implementa DNS Push Notifications ma non è configurato per essere autoritativo per il nome richiesto, il ritardo di ripetizione può essere qualsiasi valore selezionato dall'implementatore e/o configurato dall'operatore.
Se il server interrogato è elencato in un record SRV "_dns-push-tls._tcp.<zone>" per la zona, allora questa è una configurazione errata, poiché questo server viene pubblicizzato come supporto di DNS Push Notifications per questa zona, ma il server stesso non è attualmente configurato per eseguire tale compito. Poiché è possibile che la configurazione errata venga riparata in qualsiasi momento, il ritardo di ripetizione non dovrebbe essere impostato troppo alto. Per impostazione predefinita, un valore di 5 minuti è RACCOMANDATO.
Per RCODE = 11 (DSOTYPENI), che si verifica su un server che implementa DSO ma non implementa DNS Push Notifications, è improbabile che il server inizi a supportare DNS Push Notifications nei prossimi minuti, quindi il ritardo di ripetizione DOVREBBE essere di un'ora.
Per altri valori RCODE, il ritardo di ripetizione dovrebbe essere impostato dal server in modo appropriato per quella condizione di errore. Per impostazione predefinita, un valore di 5 minuti è RACCOMANDATO.
Per RCODE = 9 (NOTAUTH), il ritardo temporale si applica alle richieste per altri nomi che rientrano nella stessa zona. Le richieste per nomi che rientrano in altre zone non sono soggette al ritardo. Per tutti gli altri RCODE, il ritardo temporale si applica a tutte le richieste successive a questo server.
Dopo aver inviato una risposta di errore, il server PUÒ consentire alla sessione di rimanere aperta, o PUÒ seguirla con un'operazione DSO Retry Delay (utilizzando il TLV primario Retry Delay) che istruisce il client a chiudere la sessione come descritto nella specifica DSO [RFC8490]. I client DEVONO gestire correttamente entrambi i casi. Si noti che l'operazione DSO Retry Delay (utilizzando il TLV primario Retry Delay) è diversa dal TLV aggiuntivo Retry Delay menzionato sopra.