Aller au contenu principal

7. TLV de base pour les opérations DNS avec état

Cette section décrit les trois TLV de base pour les opérations DNS avec état : Keepalive, Retry Delay et Encryption Padding.

7.1. TLV Keepalive​

Le TLV Keepalive (DSO-TYPE=1) remplit deux fonctions. Principalement, il établit les valeurs des délais d'expiration de session. Incidemment, il réinitialise également le minuteur de maintien en vie (keepalive) pour la session DSO, ce qui signifie qu'il peut être utilisé comme une sorte de message "no-op" dans le but de maintenir une session en vie. Le client demandera les valeurs de délai d'expiration de session souhaitées et le serveur accusera réception avec les valeurs de réponse qu'il exige du client.

Les messages DSO avec le TLV Keepalive comme TLV principal peuvent apparaître dans les données précoces (early data).

Le DSO-DATA pour le TLV Keepalive est le suivant :

                        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 : Le délai d'inactivité pour la session DSO actuelle, spécifié comme un entier non signé de 32 bits, dans l'ordre des octets du réseau (big endian) en unités de millisecondes. C'est le délai auquel le client DOIT commencer à fermer une session DSO inactive. Le délai d'inactivité peut être n'importe quelle valeur choisie par le serveur. Si le client ne ferme pas gracieusement une session DSO inactive, alors après cinq secondes ou deux fois cet intervalle, selon la valeur la plus élevée, le serveur interrompra de force la connexion.

  • KEEPALIVE INTERVAL : L'intervalle de maintien en vie pour la session DSO actuelle, spécifié comme un entier non signé de 32 bits, dans l'ordre des octets du réseau (big endian) en unités de millisecondes. C'est l'intervalle auquel un client DOIT générer du trafic de maintien en vie DSO pour maintenir l'état de la connexion. L'intervalle de maintien en vie NE DOIT PAS être inférieur à dix secondes. Si le client ne génère pas le trafic de maintien en vie DSO mandaté, alors après deux fois cet intervalle, le serveur interrompra de force la connexion. Puisque l'intervalle de maintien en vie minimum autorisé est de dix secondes, le temps minimum auquel un serveur déconnectera de force un client pour avoir omis de générer le trafic de maintien en vie DSO mandaté est de vingt secondes.

La transmission ou la réception de messages DSO Keepalive (c'est-à-dire les messages où le TLV Keepalive est le premier TLV) réinitialise uniquement le minuteur de maintien en vie, et non le minuteur d'inactivité. La raison en est que les messages DSO Keepalive périodiques sont envoyés dans le seul but de maintenir une session DSO en vie lorsque cette session DSO a une activité non liée à la maintenance actuelle ou récente qui justifie le maintien de cette session DSO en vie. L'envoi de trafic de maintien en vie DSO lui-même n'est pas considéré comme une activité client ; il est considéré comme une activité de maintenance effectuée au service d'autres activités client. Si le trafic de maintien en vie DSO lui-même devait réinitialiser le minuteur d'inactivité, cela créerait un livelock circulaire où le trafic de maintien en vie serait envoyé indéfiniment pour maintenir une session DSO en vie. Dans ce scénario, la seule activité sur cette session DSO serait le trafic de maintien en vie maintenant la session DSO en vie afin que d'autres trafics de maintien en vie puissent être envoyés. Pour qu'une session DSO soit considérée comme active, elle doit transporter quelque chose de plus que du simple trafic de maintien en vie. C'est pourquoi le simple envoi ou la réception d'un message DSO Keepalive ne réinitialise pas le minuteur d'inactivité.

Lorsqu'il est envoyé par un client, le message de demande DSO Keepalive DOIT être envoyé comme un message de demande DSO avec un MESSAGE ID non nul. Si un serveur reçoit un message DSO Keepalive avec un MESSAGE ID nul, alors c'est une erreur fatale et le serveur DOIT interrompre de force la connexion immédiatement. Le message de demande DSO Keepalive réinitialise le minuteur de maintien en vie d'une session DSO et, en même temps, communique au serveur les valeurs de délai d'expiration de session demandées par le client. Dans une réponse du serveur à un message de demande DSO Keepalive initié par le client, les délais d'expiration de session contiennent les valeurs choisies par le serveur à partir de ce point dans la session DSO, que le client DOIT respecter. Ceci est calqué sur le protocole DHCP, où le client demande une certaine durée de bail en utilisant l'option DHCP 51 [RFC2132], mais le serveur est l'autorité ultime pour décider quelle durée de bail est réellement accordée.

Lorsqu'un client envoie son deuxième message de demande DSO Keepalive et les suivants au serveur, le client DEVRAIT continuer à demander ses valeurs préférées à chaque fois. Cela permet une flexibilité de sorte que si les conditions changent pendant la durée de vie d'une session DSO, le serveur peut adapter ses réponses pour mieux répondre aux besoins du client.

Une fois qu'une session DSO est en cours (section 5.1), un message DSO Keepalive PEUT être initié par un serveur. Lorsqu'il est envoyé par un serveur, le message DSO Keepalive DOIT être envoyé comme un message unidirectionnel DSO avec le MESSAGE ID mis à zéro. Le client NE DOIT PAS générer de réponse à un message DSO Keepalive initié par le serveur. Si un client reçoit un message de demande DSO Keepalive avec un MESSAGE ID non nul, alors c'est une erreur fatale et le client DOIT interrompre de force la connexion immédiatement. Le message unidirectionnel DSO Keepalive du serveur réinitialise le minuteur de maintien en vie d'une session DSO et, en même temps, informe unilatéralement le client des nouvelles valeurs de délai d'expiration de session à utiliser à partir de ce point dans cette session DSO. Aucune réponse DSO du client à cette déclaration unilatérale n'est requise ou autorisée.

Dans les messages de réponse DSO Keepalive, exactement une instance du TLV Keepalive DOIT être présente et est utilisée uniquement comme un TLV principal de réponse envoyé en réponse à un message de demande DSO Keepalive du client. Un TLV Keepalive NE DOIT PAS être ajouté à d'autres réponses en tant que TLV supplémentaire de réponse. Si le serveur souhaite mettre à jour les valeurs de délai d'expiration de session d'un client autrement qu'en réponse à un message de demande DSO Keepalive du client, alors il le fait en envoyant un message unidirectionnel DSO Keepalive de son propre chef, comme décrit ci-dessus.

Il n'est pas requis que le TLV Keepalive soit utilisé dans chaque session DSO. Bien que de nombreuses opérations DSO seront utilisées conjointement avec un état de session de longue durée, toutes les opérations DSO ne nécessitent pas un état de session de longue durée, et dans certains cas, la valeur par défaut de 15 secondes pour le délai d'inactivité et l'intervalle de maintien en vie peut être parfaitement appropriée. Cependant, notez que pour les clients qui implémentent uniquement les DSO-TYPE définis dans ce document, un message de demande DSO Keepalive est le seul moyen pour un client d'initier une session DSO.

7.1.1. Gestion par le client des valeurs de délai d'expiration de session reçues​

Lorsqu'un client reçoit une réponse à son message de demande DSO Keepalive initié par le client, ou reçoit un message unidirectionnel DSO Keepalive initié par le serveur, le client a alors reçu des valeurs de délai d'expiration de session dictées par le serveur. Les deux valeurs de délai contenues dans le TLV Keepalive du serveur peuvent chacune être supérieures, inférieures ou identiques aux valeurs de délai d'expiration de session respectives que le client avait précédemment pour cette session DSO.

Dans le cas du minuteur de maintien en vie, la gestion de la valeur reçue est simple. L'acte de recevoir le message contenant le TLV DSO Keepalive lui-même réinitialise le minuteur de maintien en vie et met à jour l'intervalle de maintien en vie pour la session DSO. Le nouvel intervalle de maintien en vie indique le temps maximum qui peut s'écouler avant qu'un autre message ne doive être envoyé ou reçu sur cette session DSO, si la session DSO doit rester en vie.

Dans le cas du délai d'inactivité, la gestion de la valeur reçue est un peu plus subtile, bien que la signification du délai d'inactivité reste telle que spécifiée ; il indique toujours le temps maximum autorisé sans activité utile sur une session DSO. L'acte de recevoir le message contenant le TLV Keepalive ne réinitialise pas lui-même le minuteur d'inactivité. Le temps écoulé depuis la dernière activité utile sur cette session DSO n'est pas affecté par l'échange de messages DSO Keepalive. La nouvelle valeur de délai d'inactivité dans le TLV Keepalive dans le message reçu met à jour le délai associé au minuteur d'inactivité en cours d'exécution ; cela devient le nouveau temps maximum autorisé sans activité sur une session DSO.

  • Si la valeur actuelle du minuteur d'inactivité est inférieure au nouveau délai d'inactivité, alors la session DSO peut rester ouverte pour le moment. Lorsque la valeur du minuteur d'inactivité atteint le nouveau délai d'inactivité, le client DOIT alors commencer à fermer la session DSO comme décrit ci-dessus.

  • Si la valeur actuelle du minuteur d'inactivité est égale au nouveau délai d'inactivité, alors cette session DSO a été inactive pendant exactement aussi longtemps que le serveur le permettra, et maintenant le client DOIT commencer immédiatement à fermer cette session DSO.

  • Si la valeur actuelle du minuteur d'inactivité est déjà supérieure au nouveau délai d'inactivité, alors cette session DSO a déjà été inactive plus longtemps que le serveur ne le permet, et le client DOIT commencer immédiatement à fermer cette session DSO.

  • Si la valeur actuelle du minuteur d'inactivité est déjà plus de deux fois le nouveau délai d'inactivité, alors le client est immédiatement considéré comme délinquant (cette session DSO est immédiatement éligible pour être interrompue de force par le serveur) et le client DOIT commencer immédiatement à fermer cette session DSO. Cependant, si un serveur réduit brusquement le délai d'inactivité de cette manière, alors, pour donner au client le temps de fermer la connexion gracieusement avant que le serveur ne recoure à son interruption forcée, le serveur DEVRAIT donner au client une période de grâce supplémentaire de cinq secondes ou un quart du nouveau délai d'inactivité, selon la valeur la plus élevée.

7.1.2. Relation avec l'option EDNS(0) edns-tcp-keepalive​

La valeur du délai d'inactivité dans le TLV Keepalive (DSO-TYPE=1) a une intention similaire à l'option EDNS(0) edns-tcp-keepalive [RFC7828]. Une paire client/serveur qui prend en charge DSO NE DOIT PAS utiliser l'option EDNS(0) edns-tcp-keepalive dans un message après qu'une session DSO a été établie. Un client qui a envoyé un message DSO pour établir une session NE DOIT PAS envoyer une option EDNS(0) edns-tcp-keepalive à partir de ce point. Une fois qu'une session DSO a été établie, si le client ou le serveur reçoit un message DNS sur la session DSO qui contient une option EDNS(0) edns-tcp-keepalive, c'est une erreur fatale et le destinataire de l'option EDNS(0) edns-tcp-keepalive DOIT interrompre de force la connexion immédiatement.

7.2. TLV Retry Delay​

Le TLV Retry Delay (DSO-TYPE=2) peut être utilisé comme un TLV principal (unidirectionnel) dans un message serveur-vers-client, ou comme un TLV supplémentaire de réponse dans l'une ou l'autre direction. Les messages DSO avec un TLV Relay Delay comme TLV principal ne sont pas autorisés dans les données précoces.

Le DSO-DATA pour le TLV Retry Delay est le suivant :

                        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 : Une valeur de temps, spécifiée comme un entier non signé de 32 bits dans l'ordre des octets du réseau (big endian), en unités de millisecondes, dans laquelle l'initiateur NE DOIT PAS réessayer cette opération ou réessayer de se connecter à ce serveur. Les recommandations pour la valeur RETRY DELAY sont données dans la section 6.6.1.

7.2.1. TLV Retry Delay utilisé comme un TLV principal​

Lorsqu'il est utilisé comme le TLV principal dans un message unidirectionnel DSO, le TLV Retry Delay est envoyé du serveur au client. Il est utilisé par un serveur pour instruire un client de fermer la session DSO et la connexion sous-jacente, et de ne pas se reconnecter pendant l'intervalle de temps indiqué.

Dans ce cas, il s'applique à la session DSO dans son ensemble, et le client DOIT commencer à fermer la session DSO comme décrit dans la section 6.6.1. Le RCODE dans l'en-tête du message DEVRAIT indiquer la raison principale de la terminaison :

  • NOERROR indique un arrêt ou un redémarrage de routine.

  • FORMERR indique qu'une demande DSO du client était trop mal formée pour que la session continue.

  • SERVFAIL indique que le serveur est surchargé en raison de l'épuisement des ressources et a besoin de délester la charge.

  • REFUSED indique que le serveur a été reconfiguré, et à ce moment, il est maintenant incapable d'effectuer une ou plusieurs des opérations client de longue durée qui étaient précédemment effectuées sur cette session DSO.

  • NOTAUTH indique que le serveur a été reconfiguré et à ce moment, il est maintenant incapable d'effectuer une ou plusieurs des opérations client de longue durée qui étaient précédemment effectuées sur cette session DSO parce qu'il n'a pas autorité sur les noms en question (par exemple, un serveur de notifications DNS Push pourrait être reconfiguré de telle sorte qu'il n'accepte plus les demandes de notifications DNS Push pour un ou plusieurs des noms actuellement abonnés).

Ce document spécifie uniquement ces valeurs RCODE pour le message DSO Retry Delay. Les serveurs envoyant des messages DSO Retry Delay DEVRAIENT utiliser l'une de ces valeurs. Cependant, des circonstances futures peuvent créer des situations où d'autres valeurs RCODE sont appropriées dans les messages DSO Retry Delay, donc les clients DOIVENT être préparés à accepter des messages DSO Retry Delay avec n'importe quelle valeur RCODE.

Dans certains cas, lorsqu'un serveur envoie un message unidirectionnel DSO Retry Delay à un client, il peut y avoir plus d'une raison pour laquelle le serveur souhaite terminer la session. Il est possible que la configuration ait été modifiée de telle sorte que certaines opérations client de longue durée ne puissent plus être poursuivies en raison de la politique (REFUSED), et d'autres opérations client de longue durée ne puissent plus être effectuées parce que le serveur ne fait plus autorité pour ces noms (NOTAUTH). Dans de tels cas, le serveur PEUT utiliser l'une des valeurs RCODE applicables, ou RCODE=NOERROR (arrêt ou redémarrage de routine).

Notez que la sélection de la valeur RCODE dans un message DSO Retry Delay n'est pas critique puisque la valeur RCODE est généralement utilisée uniquement à des fins d'information telles que l'écriture dans un fichier journal pour une analyse humaine future concernant la nature de la déconnexion. Généralement, les clients ne modifient pas leur comportement en fonction de la valeur RCODE. Le RETRY DELAY dans le message indique au client combien de temps il doit attendre avant de tenter une nouvelle connexion à cette instance de service.

Pour les clients qui modifient d'une manière ou d'une autre leur comportement en fonction de la valeur RCODE, ils devraient traiter les valeurs RCODE inconnues de la même manière que RCODE=NOERROR (arrêt ou redémarrage de routine).

Un message DSO Retry Delay (message DSO où le TLV principal est Retry Delay) du serveur au client est un message unidirectionnel DSO ; le MESSAGE ID DOIT être mis à zéro dans le message sortant et le client NE DOIT PAS envoyer de réponse.

Un client NE DOIT PAS envoyer un message DSO Retry Delay à un serveur. Si un serveur reçoit un message DSO où le TLV principal est le TLV Retry Delay, c'est une erreur fatale et le serveur DOIT interrompre de force la connexion immédiatement.

7.2.2. TLV Retry Delay utilisé comme un TLV supplémentaire de réponse​

Dans le cas d'un message de demande DSO qui entraîne une valeur RCODE non nulle, le répondeur PEUT ajouter un TLV Retry Delay à la réponse, indiquant l'intervalle de temps pendant lequel l'initiateur NE DEVRAIT PAS tenter cette opération à nouveau.

L'intervalle de temps indiqué pendant lequel l'initiateur NE DEVRAIT PAS réessayer s'applique uniquement à l'opération échouée, et non à la session DSO dans son ensemble.

Soit un client, soit un serveur, selon celui qui agit dans le rôle de répondeur pour un message de demande DSO particulier, PEUT ajouter un TLV Retry Delay à une réponse d'erreur qu'il envoie.

7.3. TLV Encryption Padding​

Le TLV Encryption Padding (DSO-TYPE=3) ne peut être utilisé que comme un TLV supplémentaire ou un TLV supplémentaire de réponse. Il n'est applicable que lorsque la couche de transport DSO utilise le chiffrement tel que TLS.

Le DSO-DATA pour le TLV Padding est facultatif et est un champ de longueur variable contenant des valeurs non spécifiées. Un DSO-LENGTH de 0 fournit essentiellement 4 octets de remplissage (le montant minimum).

                                             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              /
   /                                                               /
   +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

Comme spécifié pour l'option EDNS(0) Padding [RFC7830], les octets PADDING DEVRAIENT être mis à 0x00. D'autres valeurs PEUVENT être utilisées, par exemple, dans les cas où il y a une préoccupation que le message rempli pourrait être soumis à une compression avant le chiffrement. Les octets PADDING de toute valeur DOIVENT être acceptés dans les messages reçus.

Le TLV Encryption Padding peut être inclus dans un message de demande DSO, une réponse, ou les deux. Comme spécifié pour l'option EDNS(0) Padding [RFC7830], si un message de demande DSO est reçu avec un TLV Encryption Padding, alors la réponse DSO DOIT également inclure un TLV Encryption Padding.

La longueur du remplissage n'est intentionnellement pas spécifiée dans ce document et est fonction des meilleures pratiques actuelles concernant le type et la longueur des données dans les TLV précédents [RFC8467].

Dernière mise à jour le