6.2.2. SUBSCRIBE Response (Réponse SUBSCRIBE)
6.2.2. SUBSCRIBE Response (Réponse SUBSCRIBE)
Une réponse SUBSCRIBE commence par l'en-tête DSO standard de 12 octets [RFC8490]. Le bit QR dans l'en-tête est défini pour indiquer qu'il s'agit d'une réponse. L'en-tête PEUT être suivi d'un ou plusieurs TLV supplémentaires optionnels tels qu'un TLV supplémentaire Retry Delay. Une réponse SUBSCRIBE est illustrée dans la figure 2.
Le champ MESSAGE ID DOIT faire écho à la valeur donnée dans le champ MESSAGE ID de la demande SUBSCRIBE. C'est ainsi que le client sait à quelle demande il est répondu.
Les autres champs d'en-tête DOIVENT être définis comme décrit dans la spécification DSO [RFC8490]. Le champ DNS OPCODE contient la valeur OPCODE pour DNS Stateful Operations (6). Les quatre champs de comptage doivent être zéro, et les quatre sections correspondantes doivent être vides (c'est-à-dire absentes).
Un message de réponse SUBSCRIBE NE DOIT PAS inclure un TLV SUBSCRIBE. Si un client reçoit un message de réponse SUBSCRIBE contenant un TLV SUBSCRIBE, alors le message de réponse est traité mais le TLV SUBSCRIBE DOIT être ignoré silencieusement.
Dans la réponse SUBSCRIBE, le RCODE indique si l'abonnement a été accepté ou non. Les RCODE pris en charge sont les suivants:
| Mnémonique | Valeur | Description |
|---|---|---|
| NOERROR | 0 | SUBSCRIBE réussi. |
| FORMERR | 1 | Le serveur n'a pas réussi à traiter la demande en raison d'une demande mal formée. |
| SERVFAIL | 2 | Le serveur n'a pas réussi à traiter la demande en raison d'un problème avec le serveur. |
| NOTIMP | 4 | Le serveur n'implémente pas DSO. |
| REFUSED | 5 | Le serveur refuse de traiter la demande pour des raisons de politique ou de sécurité. |
| NOTAUTH | 9 | Le serveur n'est pas autoritaire pour le nom demandé. |
| DSOTYPENI | 11 | Opération SUBSCRIBE non prise en charge. |
Tableau 1: Codes de réponse SUBSCRIBE
Ce document spécifie uniquement ces valeurs RCODE pour les réponses SUBSCRIBE. Les serveurs envoyant des réponses SUBSCRIBE DEVRAIENT utiliser l'une de ces valeurs. Notez que NXDOMAIN n'est pas un RCODE valide en réponse à une demande SUBSCRIBE. Cependant, des circonstances futures peuvent créer des situations où d'autres valeurs RCODE sont appropriées dans les réponses SUBSCRIBE, donc les clients DOIVENT être préparés à accepter et gérer les réponses SUBSCRIBE avec toute autre valeur d'erreur RCODE non nulle.
Si le serveur envoie un RCODE non nul dans la réponse SUBSCRIBE, cela signifie:
a. le client est (au moins partiellement) mal configuré, ou b. les ressources du serveur sont épuisées, ou c. il y a un autre échec inconnu sur le serveur.
Dans tous les cas, le client ne devrait pas réessayer l'abonnement à ce serveur immédiatement. Si plusieurs enregistrements SRV ont été renvoyés comme décrit dans la section 6.1, paragraphe 9, point 7, un serveur ultérieur PEUT être essayé immédiatement.
Si le client a d'autres abonnements réussis à ce serveur, ces abonnements restent même si des abonnements supplémentaires peuvent être refusés. Ni le client ni le serveur n'est tenu de fermer la connexion, bien que l'une ou l'autre extrémité puisse choisir de le faire.
Si le serveur envoie un RCODE non nul, il DEVRAIT alors ajouter un TLV supplémentaire Retry Delay [RFC8490] à la réponse spécifiant un délai avant que le client ne tente à nouveau cette opération. Les valeurs recommandées pour le délai pour différentes valeurs RCODE sont données ci-dessous. Ces valeurs recommandées s'appliquent à la fois aux valeurs par défaut qu'un serveur devrait placer dans le TLV supplémentaire Retry Delay et aux valeurs par défaut qu'un client devrait supposer si le serveur ne fournit pas de TLV supplémentaire Retry Delay.
Pour RCODE = 1 (FORMERR), le délai peut être n'importe quelle valeur sélectionnée par l'implémenteur. Une valeur de cinq minutes est RECOMMANDÉE pour réduire le risque de charge élevée provenant de clients défectueux.
Pour RCODE = 2 (SERVFAIL), le délai doit être choisi en fonction du niveau de surcharge du serveur et de la durée anticipée de cette surcharge. Par défaut, une valeur d'une minute est RECOMMANDÉE. Si une défaillance de serveur plus grave se produit, le délai peut être plus long conformément au problème spécifique rencontré.
Pour RCODE = 4 (NOTIMP), qui se produit sur un serveur qui n'implémente pas DNS Stateful Operations [RFC8490], il est peu probable que le serveur commence à prendre en charge DSO dans les prochaines minutes, donc le délai de nouvelle tentative DEVRAIT être d'une heure. Notez que dans un tel cas, un serveur qui n'implémente pas DSO est peu susceptible de placer un TLV supplémentaire Retry Delay dans sa réponse, donc cette valeur recommandée en particulier s'applique à ce qu'un client devrait supposer par défaut.
Pour RCODE = 5 (REFUSED), qui se produit sur un serveur qui implémente DNS Push Notifications mais est actuellement configuré pour interdire DNS Push Notifications, le délai de nouvelle tentative peut être n'importe quelle valeur sélectionnée par l'implémenteur et/ou configurée par l'opérateur.
Si le serveur interrogé est répertorié dans un enregistrement SRV "_dns-push-tls._tcp.<zone>" pour la zone, alors il s'agit d'une mauvaise configuration, puisque ce serveur est annoncé comme prenant en charge DNS Push Notifications pour cette zone, mais le serveur lui-même n'est pas actuellement configuré pour effectuer cette tâche. Puisqu'il est possible que la mauvaise configuration soit réparée à tout moment, le délai de nouvelle tentative ne doit pas être défini trop haut. Par défaut, une valeur de 5 minutes est RECOMMANDÉE.
Pour RCODE = 9 (NOTAUTH), qui se produit sur un serveur qui implémente DNS Push Notifications mais n'est pas configuré pour être autoritaire pour le nom demandé, le délai de nouvelle tentative peut être n'importe quelle valeur sélectionnée par l'implémenteur et/ou configurée par l'opérateur.
Si le serveur interrogé est répertorié dans un enregistrement SRV "_dns-push-tls._tcp.<zone>" pour la zone, alors il s'agit d'une mauvaise configuration, puisque ce serveur est annoncé comme prenant en charge DNS Push Notifications pour cette zone, mais le serveur lui-même n'est pas actuellement configuré pour effectuer cette tâche. Puisqu'il est possible que la mauvaise configuration soit réparée à tout moment, le délai de nouvelle tentative ne doit pas être défini trop haut. Par défaut, une valeur de 5 minutes est RECOMMANDÉE.
Pour RCODE = 11 (DSOTYPENI), qui se produit sur un serveur qui implémente DSO mais n'implémente pas DNS Push Notifications, il est peu probable que le serveur commence à prendre en charge DNS Push Notifications dans les prochaines minutes, donc le délai de nouvelle tentative DEVRAIT être d'une heure.
Pour d'autres valeurs RCODE, le délai de nouvelle tentative doit être défini par le serveur de manière appropriée pour cette condition d'erreur. Par défaut, une valeur de 5 minutes est RECOMMANDÉE.
Pour RCODE = 9 (NOTAUTH), le délai s'applique aux demandes pour d'autres noms tombant dans la même zone. Les demandes pour des noms tombant dans d'autres zones ne sont pas soumises au délai. Pour tous les autres RCODE, le délai s'applique à toutes les demandes ultérieures à ce serveur.
Après avoir envoyé une réponse d'erreur, le serveur PEUT permettre à la session de rester ouverte, ou PEUT la suivre d'une opération DSO Retry Delay (utilisant le TLV primaire Retry Delay) demandant au client de fermer la session comme décrit dans la spécification DSO [RFC8490]. Les clients DOIVENT gérer correctement les deux cas. Notez que l'opération DSO Retry Delay (utilisant le TLV primaire Retry Delay) est différente du TLV supplémentaire Retry Delay mentionné ci-dessus.