Aller au contenu principal

5. Détails du Protocole (Protocol Details)

Le flux global des Opérations DNS avec État (DNS Stateful Operations) passe par une série de phases :

Établissement de la Connexion (Connection Establishment) : Un client établit une connexion avec un serveur (Section 4.2).

Connecté mais sans Session (Connected but Sessionless) : Une connexion existe, mais une Session DSO n'a pas été établie. Les messages DNS peuvent être envoyés du client au serveur, et les réponses DNS peuvent être envoyées du serveur au client. Dans cet état, un client qui souhaite utiliser DSO peut tenter d'établir une Session DSO (Section 5.1). La gestion standard du timeout d'inactivité DNS-over-TCP est en vigueur [RFC7766] (voir Section 7.1.2 de ce document).

Établissement de Session DSO en Cours (DSO Session Establishment in Progress) : Un client a envoyé une requête DSO au cours des 30 dernières secondes, mais n'a pas encore reçu de réponse DSO pour cette requête. Dans cette phase, le client peut envoyer davantage de requêtes DSO et davantage de requêtes DNS, mais NE DOIT PAS envoyer de messages DSO unidirectionnels (Section 5.1).

Timeout d'Établissement de Session DSO : Un client a envoyé une requête DSO, et après 30 secondes n'a toujours reçu aucune réponse DSO pour cette requête. Cela signifie que le serveur est maintenant dans un état indéterminé. Le client abandonne de force la connexion. Le client PEUT se reconnecter sans utiliser DSO, si approprié.

Échec d'Établissement de Session DSO (DSO Session Establishment Failed) : Un client a envoyé une requête DSO et a reçu une réponse DSO correspondante avec un RCODE non nul. Cela signifie que la tentative d'établir la Session DSO n'a pas réussi. À ce stade, le client est autorisé à continuer à fonctionner sans Session DSO (Connecté mais sans Session) mais n'envoie plus de messages DSO supplémentaires (Section 5.1).

Session DSO Établie (DSO Session Established) : Un client a envoyé une requête DSO et a reçu une réponse DSO correspondante avec RCODE défini sur NOERROR (0). Une Session DSO a maintenant été établie avec succès. Le client et le serveur peuvent tous deux envoyer des messages DSO et des messages DNS ; les deux peuvent envoyer des réponses en réponse aux messages qu'ils reçoivent (Section 5.2). Le minuteur d'inactivité (Section 6.4) est actif ; le minuteur de maintien en vie (keepalive) (Section 6.5) est actif. La gestion standard du timeout d'inactivité DNS-over-TCP n'est plus en vigueur [RFC7766] (voir Section 7.1.2 de ce document).

Arrêt du Serveur (Server Shutdown) : Le serveur a décidé de terminer gracieusement la session et a envoyé au client un message Retry Delay (Section 6.6.1). Il peut encore y avoir des messages non traités du client ; le serveur les ignorera. Le serveur n'enverra plus de messages au client (Section 6.6.1.1).

Arrêt du Client (Client Shutdown) : Le client a décidé de se déconnecter, soit parce qu'il n'a plus besoin de service, la connexion est inactive (Section 6.4.1), ou parce que le serveur lui a envoyé un message Retry Delay (Section 6.6.1). Le client ferme la connexion gracieusement (Section 5.3).

Reconnexion (Reconnect) : Le client s'est déconnecté suite à un arrêt du serveur. Le client attend soit que le Retry Delay spécifié par le serveur expire (Section 6.6.3), soit contacte une instance de serveur différente. Si le client n'a plus besoin de service, il ne se reconnecte pas.

Abandon Forcé (Forcibly Abort) : Le client ou le serveur a détecté une erreur de protocole, et toute communication ultérieure aurait un comportement indéfini. Le client ou le serveur abandonne de force la connexion (Section 5.3).

Attente de Reconnexion après Abandon (Abort Reconnect Wait) : Le client a abandonné de force la connexion mais a toujours besoin de service. Ou, le serveur a abandonné de force la connexion, mais le client a toujours besoin de service. Le client se connecte soit à une instance de service différente (Section 9.1), soit attend pour se reconnecter (Section 6.6.3.1).

5.1. Établissement de Session DSO (DSO Session Establishment)​

Pour qu'une session soit établie entre un client et un serveur, le client doit d'abord établir une connexion au serveur en utilisant un transport applicable (voir Section 4.2).

Dans certains environnements, il peut être connu à l'avance par des moyens externes que le client et le serveur prennent tous deux en charge DSO, et dans ces cas, le client ou le serveur peut initier des messages DSO à tout moment. Dans ce cas, la session est établie dès que la connexion est établie ; cela est appelé établissement de Session DSO implicite.

Cependant, dans le cas typique, un serveur ne saura pas à l'avance si un client prend en charge DSO, donc en général, à moins qu'il ne soit connu à l'avance par d'autres moyens qu'un client prend en charge DSO, un serveur NE DOIT PAS initier de messages de requête DSO ou de messages DSO unidirectionnels jusqu'à ce qu'une Session DSO ait été mutuellement établie par au moins un échange requête/réponse DSO réussi initié par le client, comme décrit ci-dessous. Cela est appelé établissement de Session DSO explicite.

Jusqu'à ce qu'une Session DSO ait été implicitement ou explicitement établie, un client NE DOIT PAS initier de messages DSO unidirectionnels.

Une Session DSO est établie sur une connexion par le client envoyant un message de requête DSO, tel qu'un message de requête DSO Keepalive (Section 7.1), et recevant une réponse avec un MESSAGE ID correspondant, et RCODE défini sur NOERROR (0), indiquant que la requête DSO a réussi.

Certains messages DSO sont autorisés comme données précoces (early data) (Section 11.1). D'autres ne le sont pas. Les messages unidirectionnels ne sont jamais autorisés comme données précoces, sauf si une Session DSO implicite existe.

Si un serveur reçoit un message DSO dans des données précoces dont le TLV Primaire n'est pas autorisé à apparaître dans des données précoces, le serveur DOIT abandonner de force la connexion. Si un client reçoit un message DSO dans des données précoces, et qu'il n'existe pas de Session DSO implicite, le client DOIT abandonner de force la connexion. Cela ne peut être appliqué que sur les connexions TLS ; par conséquent, les serveurs NE DOIVENT PAS activer TCP Fast Open (TFO) lors de l'écoute d'une connexion qui ne nécessite pas TLS.

5.1.1. Échec d'Établissement de Session DSO​

Si le RCODE de réponse est défini sur NOTIMP (4), ou en pratique sur toute valeur autre que NOERROR (0) ou DSOTYPENI (défini ci-dessous), alors le client DOIT supposer que le serveur n'implémente pas DSO du tout. Dans ce cas, le client est autorisé à continuer d'envoyer des messages DNS sur cette connexion mais NE DOIT PAS émettre d'autres messages DSO sur cette connexion.

Si le RCODE dans la réponse est défini sur DSOTYPENI ("DSO-TYPE Not Implemented" ; RCODE 11), cela indique que le serveur prend en charge DSO mais n'implémente pas le DSO-TYPE du TLV Primaire dans ce message de requête DSO. Un serveur implémentant DSO NE DOIT PAS retourner DSOTYPENI pour un message de requête DSO Keepalive car le TLV Keepalive est obligatoire à implémenter. Mais à l'avenir, si un client tente d'établir une Session DSO en utilisant un message de requête DSO nécessitant une réponse utilisant un DSO-TYPE nouvellement défini que le serveur ne comprend pas, cela résulterait en une réponse DSOTYPENI. Si le serveur retourne DSOTYPENI, alors une Session DSO n'est pas considérée comme établie. Le client est cependant autorisé à continuer d'envoyer des messages DNS sur la connexion, y compris d'autres messages DSO tels que le DSO Keepalive, ce qui peut résulter en une réponse NOERROR réussie, produisant l'établissement d'une Session DSO.

Lorsqu'un message DSO est reçu par un serveur DNS existant qui ne reconnaît pas l'OPCODE DSO, deux autres résultats possibles existent : le serveur peut ne pas envoyer de réponse au message DSO, ou le serveur peut interrompre la connexion.

Si le serveur n'envoie pas de réponse au message DSO, le client DEVRAIT attendre 30 secondes, après quoi le serveur sera supposé ne pas prendre en charge DSO. Si le serveur ne répond pas dans les 30 secondes, on peut supposer qu'il ne va pas répondre ; cela le laisse dans un état non spécifié : il n'y a pas de spécification exigeant qu'une réponse soit envoyée à un message inconnu, mais il n'y a pas non plus de spécification indiquant dans quel état se trouve le serveur si aucune réponse n'est envoyée. Par conséquent, le client DOIT abandonner de force la connexion au serveur. Le client PEUT se reconnecter, mais sans utiliser DSO, si approprié (Section 6.6.3.1). En se déconnectant et en se reconnectant, le client s'assure que le serveur est dans un état connu avant d'envoyer toute requête ultérieure.

Si le serveur interrompt la connexion, le client DEVRAIT marquer cette instance de service comme ne prenant pas en charge DSO, et ne pas tenter de connexion DSO pendant une certaine période (au moins une heure) après la tentative échouée. Le client PEUT se reconnecter mais sans utiliser DSO, si approprié (Section 6.6.3.2).

5.1.2. Succès d'Établissement de Session DSO​

Lorsque le serveur reçoit un message de requête DSO d'un client et transmet une réponse NOERROR réussie à cette requête, le serveur considère la Session DSO comme établie.

Lorsque le client reçoit la réponse NOERROR du serveur à son message de requête DSO, le client considère la Session DSO comme établie.

Une fois qu'une Session DSO a été établie, chaque extrémité peut unilatéralement envoyer des messages DSO appropriés à tout moment, et par conséquent, le client ou le serveur peut être l'initiateur d'un message.

5.2. Opérations après Établissement de Session DSO (Operations after DSO Session Establishment)​

Une fois qu'une Session DSO a été établie, les clients et serveurs doivent se comporter comme décrit dans cette spécification en ce qui concerne les timeouts d'inactivité et la terminaison de session, et non comme précédemment prescrit dans la spécification antérieure pour DNS-over-TCP [RFC7766].

Parce qu'un serveur qui prend en charge les Opérations DNS avec État DOIT retourner un RCODE de "NOERROR" lorsqu'il reçoit un message de requête DSO avec TLV Keepalive, le TLV Keepalive est un candidat idéal pour une utilisation lors de l'établissement d'une Session DSO. Toute autre option qui ne peut réussir que lorsqu'elle est envoyée à un serveur du type souhaité est également un bon candidat pour une utilisation lors de l'établissement d'une Session DSO. Pour les clients qui implémentent uniquement les DSO-TYPEs définis dans cette spécification de base, l'envoi d'un TLV Keepalive est le seul message de requête DSO dont ils disposent pour initier une Session DSO. Même pour les clients qui implémentent d'autres DSO-TYPEs futurs, pour des raisons de simplicité, ils PEUVENT choisir de toujours envoyer un message de requête DSO Keepalive initial comme moyen d'initier une Session DSO. Une définition future d'un nouveau DSO-TYPE nécessitant une réponse donne aux implémenteurs l'option d'utiliser ce nouveau DSO-TYPE s'ils le souhaitent, mais ne change pas le fait que l'envoi d'un TLV Keepalive reste un moyen valide d'initier une Session DSO.

5.3. Terminaison de Session DSO (DSO Session Termination)​

Une Session DSO est terminée lorsque la connexion sous-jacente est fermée. Les Sessions DSO sont "fermées gracieusement" suite à la fermeture par le serveur d'une Session DSO parce qu'il est surchargé, suite à la fermeture par le client de la Session DSO parce qu'il a terminé, ou suite à la fermeture par le client de la Session DSO parce qu'elle est inactive. Les Sessions DSO sont "abandonnées de force" lorsque le client ou le serveur ferme la connexion en raison d'une erreur de protocole.

  • Lorsque cette spécification dit "fermer gracieusement", cela signifie envoyer un TLS close_notify (si TLS est utilisé) suivi d'un TCP FIN, ou l'équivalent pour d'autres protocoles. Lorsque cette spécification exige qu'une connexion soit fermée gracieusement, l'exigence d'initier cette fermeture gracieuse est placée sur le client afin de placer la charge de l'état TIME-WAIT de TCP sur le client plutôt que sur le serveur.

  • Lorsque cette spécification dit "abandonner de force", cela signifie envoyer un TCP RST ou l'équivalent pour d'autres protocoles. Dans l'API BSD Sockets, cela est réalisé en définissant l'option SO_LINGER à zéro avant de fermer le socket.

5.3.1. Gestion des Erreurs de Protocole (Handling Protocol Errors)​

Dans l'implémentation de protocoles, il existe généralement deux types d'erreurs avec lesquels les développeurs de logiciels doivent composer. Le premier concerne les situations qui surviennent en raison de facteurs environnementaux, tels qu'une perte temporaire de connectivité. Bien qu'indésirables, ces situations n'indiquent pas un défaut dans le logiciel et sont des situations dont le logiciel devrait généralement pouvoir se remettre.

Le second concerne les situations qui ne devraient jamais se produire lors de la communication avec une implémentation DSO conforme. Si elles se produisent, elles indiquent un défaut grave dans l'implémentation du protocole au-delà de ce qu'il est raisonnable d'attendre qu'un logiciel puisse surmonter. Ce document décrit cette dernière forme de condition d'erreur comme une "erreur fatale" et spécifie qu'une implémentation rencontrant une condition d'erreur fatale "DOIT abandonner de force la connexion immédiatement".

5.4. Format de Message (Message Format)​

Un message DSO commence par l'en-tête de message DNS standard de douze octets [RFC1035] avec le champ OPCODE défini sur l'OPCODE DSO (6). Cependant, contrairement aux messages DNS standard, la section question, la section réponse, la section d'enregistrements d'autorité et la section d'enregistrements additionnels ne sont pas présentes. Les champs de comptage correspondants (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) DOIVENT être définis à zéro lors de la transmission.

Si un message DSO est reçu où l'un des champs de comptage n'est pas zéro, alors un FORMERR DOIT être retourné.

                                             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. Champs d'En-tête DNS dans les Messages DSO (DNS Header Fields in DSO Messages)​

Dans un message DSO unidirectionnel, le champ MESSAGE ID DOIT être défini à zéro. Dans un message de requête DSO, le champ MESSAGE ID DOIT être défini sur une valeur non nulle unique que l'initiateur n'utilise actuellement pas pour toute autre opération active sur cette connexion. Aux fins présentes, un MESSAGE ID est en cours d'utilisation dans cette Session DSO si l'initiateur l'a utilisé dans un message de requête DSO pour lequel il attend toujours une réponse, ou si le client l'a utilisé pour configurer une opération de longue durée qui n'a pas encore été annulée. Par exemple, une opération de longue durée pourrait être un abonnement Push Notification [Push] ou un abonnement d'interface Discovery Relay [Relay].

Qu'un message soit un message de requête DSO ou un message DSO unidirectionnel est déterminé uniquement par la spécification du TLV Primaire. Un accusé de réception ne peut pas être demandé en incluant un MESSAGE ID non nul dans un message qui est requis selon son TLV Primaire d'être unidirectionnel. De même, un accusé de réception ne peut pas être empêché en envoyant un MESSAGE ID de zéro dans un message qui est requis d'être un message de requête DSO selon son TLV Primaire. Un répondeur qui reçoit l'un ou l'autre de ces messages mal formés DOIT le traiter comme une erreur fatale et abandonner de force la connexion immédiatement.

Dans un message de requête DSO ou un message DSO unidirectionnel, le bit Query/Response (QR) de l'en-tête DNS DOIT être zéro (QR=0). Si le bit QR n'est pas zéro, le message n'est pas un message de requête DSO ou un message DSO unidirectionnel.

Dans un message de réponse DSO, le bit QR de l'en-tête DNS DOIT être un (QR=1). Si le bit QR n'est pas un, le message n'est pas un message de réponse DSO.

Dans un message de réponse DSO (QR=1), le champ MESSAGE ID NE DOIT PAS être zéro, et DOIT contenir une copie de la valeur du champ MESSAGE ID (non nul) dans le message de requête DSO auquel il répond. Si un message de réponse DSO (QR=1) est reçu où le MESSAGE ID est zéro, c'est une erreur fatale et le destinataire DOIT abandonner de force la connexion immédiatement.

Le champ OPCODE de l'en-tête DNS contient la valeur OPCODE DSO (6).

Les bits Z sont actuellement inutilisés dans les messages DSO ; dans les messages de requête DSO et les réponses DSO, les bits Z DOIVENT être définis à zéro (0) lors de la transmission et DOIVENT être ignorés lors de la réception.

Dans un message de requête DSO (QR=0), le RCODE est défini selon la définition de la requête. Par exemple, dans un message Retry Delay (Section 6.6.1), le RCODE indique la raison de la terminaison. Cependant, dans la plupart des messages de requête DSO (QR=0), sauf indication contraire claire, le RCODE est défini à zéro lors de la transmission, et ignoré silencieusement lors de la réception.

La valeur RCODE dans un message de réponse (QR=1) peut être l'une des valeurs suivantes :

CodeMnémoniqueDescription
0NOERROROpération traitée avec succès
1FORMERRErreur de format
2SERVFAILLe serveur n'a pas pu traiter le message de requête DSO en raison d'un problème avec le serveur
4NOTIMPDSO non pris en charge
5REFUSEDOpération refusée pour des raisons de politique
11DSOTYPENILe DSO-Type du TLV Primaire n'est pas implémenté

L'utilisation des RCODEs ci-dessus est susceptible d'être courante dans DSO mais n'empêche pas la définition et l'utilisation d'autres codes dans de futurs documents qui utilisent DSO.

Si un document définissant un nouveau DSO-TYPE utilise des codes de réponse non définis ici, alors ce document DOIT spécifier l'interprétation spécifique de ces valeurs RCODE dans le contexte de ce nouveau TLV DSO.

Le champ RCODE est suivi des quatre champs de comptage à valeur nulle, suivis des Données DSO.

5.4.2. Données DSO (DSO Data)​

L'en-tête de message DNS standard de douze octets avec ses champs de comptage à valeur nulle est suivi par les Données DSO, exprimées en syntaxe TLV, comme décrit dans la Section 5.4.4.

Un message de requête DSO ou un message DSO unidirectionnel DOIT contenir au moins un TLV. Le premier TLV dans un message de requête DSO ou un message DSO unidirectionnel est appelé le "TLV Primaire" et détermine la nature de l'opération effectuée, y compris s'il s'agit d'une requête DSO ou d'une opération DSO unidirectionnelle. Dans certains cas, il peut être approprié d'inclure d'autres TLVs dans un message de requête DSO ou un message DSO unidirectionnel, tel que le TLV DSO Encryption Padding (Section 7.3). Les TLVs additionnels suivent le TLV Primaire. Les TLVs additionnels ne sont pas limités à ce qui est défini dans ce document. De nouveaux TLVs Additionnels peuvent être définis à l'avenir. Leurs définitions décriront quand leur utilisation est appropriée.

Un TLV Primaire non reconnu entraîne une réponse d'erreur DSOTYPENI. Les TLVs Additionnels non reconnus sont ignorés silencieusement, comme décrit dans les Sections 5.4.5 et 8.2.

Un message de réponse DSO peut ne contenir aucun TLV, ou peut contenir un ou plusieurs TLVs, appropriés aux informations communiquées.

Tous les TLVs ayant le même DSO-TYPE que le TLV Primaire du message de requête DSO correspondant sont des TLV(s) Primaire(s) de Réponse et DOIVENT apparaître en premier dans un message de réponse DSO. Un message de réponse DSO peut contenir plusieurs TLVs Primaires de Réponse, ou un seul TLV Primaire de Réponse, ou dans certains cas, aucun TLV Primaire de Réponse. Un TLV Primaire de Réponse n'est pas requis ; pour la plupart des opérations DSO, le champ MESSAGE ID dans l'en-tête du message DNS est suffisant pour identifier le message de requête DSO auquel un message de réponse particulier se rapporte.

Tous les autres TLVs dans un message de réponse DSO sont des TLVs Additionnels de Réponse, tels que le TLV DSO Encryption Padding (Section 7.3). Les TLVs Additionnels de Réponse suivent le(s) TLV(s) Primaire(s) de Réponse, s'ils sont présents. Les TLVs Additionnels de Réponse ne sont pas limités à ce qui est défini dans ce document. De nouveaux TLVs Additionnels de Réponse peuvent être définis à l'avenir. Leurs définitions décriront quand leur utilisation est appropriée. Les TLVs Additionnels de Réponse non reconnus sont ignorés silencieusement, comme décrit dans les Sections 5.4.5 et 8.2.

La spécification pour chaque TLV DSO détermine quels TLVs sont requis dans une réponse à un message de requête DSO utilisant ce TLV. Si une réponse DSO est reçue pour une opération où la spécification exige que la réponse porte un TLV particulier ou des TLVs, et que le(s) TLV(s) requis ne sont pas présents, alors c'est une erreur fatale et le destinataire du message de réponse défectueux DOIT abandonner de force la connexion immédiatement. De même, si plus que le nombre spécifié d'instances d'un TLV donné sont présentes, c'est une erreur fatale et le destinataire du message de réponse défectueux DOIT abandonner de force la connexion immédiatement.

5.4.3. Messages DSO Unidirectionnels (DSO Unidirectional Messages)​

Il est prévu que la plupart des opérations DSO seront spécifiées pour utiliser des messages de requête DSO, qui génèrent des réponses DSO correspondantes. Dans certains cas d'utilisation spécialisés à fort trafic, il peut être approprié de spécifier des messages DSO unidirectionnels. Les messages DSO unidirectionnels peuvent être plus efficaces sur le réseau car ils ne génèrent pas un flux de messages de réponse correspondants. L'utilisation de messages DSO unidirectionnels peut également simplifier le logiciel dans certains cas en supprimant le besoin pour un initiateur de maintenir l'état pendant qu'il attend de recevoir des réponses dont il ne se soucie pas. Lorsque la spécification pour un TLV particulier utilisé comme TLV Primaire (c'est-à-dire en premier) dans un message de requête DSO sortant (c'est-à-dire QR=0) indique qu'un message doit être unidirectionnel, le champ MESSAGE ID DOIT être défini à zéro et le récepteur NE DOIT PAS générer de message de réponse correspondant à ce message DSO unidirectionnel.

Le point précédent, selon lequel le récepteur NE DOIT PAS générer de réponses aux messages DSO unidirectionnels, s'applique même en cas d'erreurs.

Lorsqu'un message DSO est reçu où à la fois le bit QR et le champ MESSAGE ID sont zéro, le récepteur NE DOIT PAS générer de réponse. Par exemple, si le DSO-TYPE dans le TLV Primaire n'est pas reconnu, alors une erreur DSOTYPENI NE DOIT PAS être retournée ; au lieu de cela, le récepteur DOIT abandonner de force la connexion immédiatement.

Les messages DSO unidirectionnels NE DOIVENT PAS être utilisés "spéculativement" dans les cas où l'expéditeur ne sait pas si le récepteur prend en charge le TLV Primaire dans le message car il n'y a aucun moyen de recevoir une réponse indiquant le succès ou l'échec. Les messages DSO unidirectionnels ne sont appropriés que dans les cas où l'expéditeur sait déjà que le récepteur prend en charge et souhaite recevoir ces messages.

Par exemple, après qu'un client s'est abonné aux Notifications Push [Push], les notifications d'événements ultérieures sont ensuite envoyées comme messages DSO unidirectionnels. Cela est approprié car le client a initié le flux de messages en vertu de son abonnement Push Notification, indiquant ainsi sa prise en charge des Notifications Push et son désir de recevoir ces notifications.

De même, après qu'un client Discovery Relay s'est abonné pour recevoir le trafic mDNS (multicast DNS) [RFC6762] entrant d'un Discovery Relay, le flux ultérieur de paquets reçus est ensuite envoyé en utilisant des messages DSO unidirectionnels. Cela est approprié car le client a initié le flux de messages en vertu de son abonnement de lien Discovery Relay, indiquant ainsi sa prise en charge de Discovery Relay et son désir de recevoir des paquets mDNS entrants sur cette Session DSO [Relay].

5.4.4. Syntaxe TLV (TLV Syntax)​

Tous les TLVs, qu'ils soient utilisés comme "Primaire", "Additionnel", "Primaire de Réponse" ou "Additionnel de Réponse", utilisent la même syntaxe d'encodage.

Une spécification qui définit un nouveau TLV doit spécifier si le DSO-TYPE peut être utilisé comme TLV Primaire, et si le DSO-TYPE peut être utilisé comme TLV Additionnel. Certains DSO-TYPEs sont à double usage et peuvent être utilisés comme TLVs Primaires dans certains messages, et dans d'autres messages comme TLVs Additionnels. La spécification pour un DSO-TYPE doit également indiquer si, lorsqu'il est utilisé comme TLV Primaire (c'est-à-dire premier) dans un message DSO (c'est-à-dire QR=0), ce message DSO est unidirectionnel, ou est un message de requête DSO qui nécessite une réponse.

Si un message de requête DSO nécessite une réponse, la spécification doit également indiquer quels TLVs, le cas échéant, doivent être inclus dans la réponse et combien d'instances de chacun des TLVs sont autorisées. Le TLV Primaire peut ou non être contenu dans la réponse selon ce qui est spécifié pour ce TLV. Si plusieurs instances du TLV Primaire sont autorisées, la spécification devrait clairement décrire comment elles devraient être traitées.

                                             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 entier non signé de 16 bits, dans l'ordre des octets réseau (big endian), donnant le DSO-TYPE du TLV DSO actuel selon le registre IANA "DSO Type Codes".

DSO-LENGTH : Un entier non signé de 16 bits, dans l'ordre des octets réseau (big endian), donnant la taille en octets du DSO-DATA.

DSO-DATA : Format spécifique au code de type. La machinerie DSO générique traite le DSO-DATA comme un "blob" opaque sans tenter de l'interpréter. L'interprétation de la signification du DSO-DATA pour un DSO-TYPE particulier est la responsabilité du logiciel qui implémente ce DSO-TYPE.

5.4.5. TLVs Non Reconnus (Unrecognized TLVs)​

Si un message de requête DSO est reçu contenant un TLV Primaire non reconnu, avec un MESSAGE ID non nul (indiquant qu'une réponse est attendue), alors le récepteur DOIT envoyer une réponse d'erreur avec un MESSAGE ID correspondant, et RCODE DSOTYPENI. La réponse d'erreur NE DOIT PAS contenir une copie du TLV Primaire non reconnu.

Si un message DSO unidirectionnel est reçu contenant à la fois un TLV Primaire non reconnu et un MESSAGE ID nul (indiquant qu'aucune réponse n'est attendue), alors c'est une erreur fatale et le destinataire DOIT abandonner de force la connexion immédiatement.

Si un message de requête DSO ou un message DSO unidirectionnel est reçu où le TLV Primaire est reconnu, contenant un ou plusieurs TLVs Additionnels non reconnus, les TLVs Additionnels non reconnus DOIVENT être ignorés silencieusement, et le reste du message est interprété et traité comme si les parties non reconnues n'étaient pas présentes.

De même, si un message de réponse DSO est reçu contenant un ou plusieurs TLVs non reconnus, les TLVs non reconnus DOIVENT être ignorés silencieusement et le reste du message est interprété et traité comme si les parties non reconnues n'étaient pas présentes.

5.4.6. EDNS(0) et TSIG​

Puisque le champ ARCOUNT DOIT être zéro, un message DSO ne peut pas contenir d'option EDNS(0) valide dans la section d'enregistrements additionnels. Si une fonctionnalité fournie par des options EDNS(0) actuelles ou futures est souhaitée pour les messages DSO, un ou plusieurs nouveaux TLVs DSO doivent être définis pour transporter les informations nécessaires.

Par exemple, l'option EDNS(0) Padding [RFC7830] utilisée à des fins de sécurité n'est pas autorisée dans un message DSO, donc si un remplissage de message est souhaité pour les messages DSO, alors le TLV DSO Encryption Padding décrit dans la Section 7.3 DOIT être utilisé.

Un message DSO ne peut pas contenir d'enregistrement TSIG car un enregistrement TSIG est inclus dans la section additionnelle du message, ce qui signifierait que ARCOUNT serait supérieur à zéro. Les messages DSO sont tenus d'avoir un ARCOUNT de zéro. Par conséquent, si l'utilisation de signatures avec des messages DSO devient nécessaire à l'avenir, un nouveau TLV DSO devrait être défini pour effectuer cette fonction.

Notez cependant que, bien que les messages DSO ne puissent pas inclure d'enregistrements EDNS(0) ou TSIG, une session DSO est généralement utilisée pour transporter toute une série de messages DNS de différents types, y compris des messages DSO et d'autres types de messages DNS tels que Query [RFC1034] [RFC1035] et Update [RFC2136]. Ces messages peuvent porter des enregistrements EDNS(0) et TSIG.

Bien que les messages puissent contenir d'autres options EDNS(0) selon ce qui est approprié, cette spécification interdit explicitement l'utilisation de l'option EDNS(0) edns-tcp-keepalive [RFC7828] dans tous les messages envoyés sur une Session DSO (car elle est rendue obsolète par la fonctionnalité fournie par l'opération DSO Keepalive). Si un message envoyé sur une Session DSO contient une option EDNS(0) edns-tcp-keepalive, c'est une erreur fatale et le destinataire du message défectueux DOIT abandonner de force la connexion immédiatement.

5.5. Gestion des Messages (Message Handling)​

Comme décrit dans la Section 5.4.1, qu'un message DSO sortant avec le bit QR dans l'en-tête DNS défini à zéro soit une requête DSO ou un message DSO unidirectionnel est déterminé par la spécification du TLV Primaire, qui à son tour détermine si le champ MESSAGE ID dans ce message sortant sera zéro ou non nul.

Chaque message DSO avec le bit QR dans l'en-tête DNS défini à zéro et un champ MESSAGE ID non nul est un message de requête DSO, et DOIT susciter une réponse correspondante, avec le bit QR dans l'en-tête DNS défini à un et le champ MESSAGE ID défini sur la valeur donnée dans le message de requête DSO correspondant.

Les messages de requête DSO valides envoyés par le client avec un champ MESSAGE ID non nul suscitent une réponse du serveur, et les messages de requête DSO valides envoyés par le serveur avec un champ MESSAGE ID non nul suscitent une réponse du client.

Chaque message DSO avec à la fois le bit QR dans l'en-tête DNS et le champ MESSAGE ID définis à zéro est un message DSO unidirectionnel et NE DOIT PAS susciter de réponse.

5.5.1. Gestion des Accusés de Réception Retardés (Delayed Acknowledgement Management)​

Généralement, la plupart des bonnes implémentations TCP emploient un minuteur d'accusé de réception retardé pour fournir une utilisation plus efficace du réseau et de meilleures performances.

Avec un échange bidirectionnel sur TCP, comme avec un message de requête DSO, l'implémentation TCP du système d'exploitation attend que le logiciel client de la couche application génère le message de réponse DSO correspondant. L'implémentation TCP peut alors envoyer un seul paquet combiné contenant l'accusé de réception TCP, la mise à jour de fenêtre TCP et le message de réponse DSO généré par l'application. Ceci est plus efficace que d'envoyer trois paquets séparés, comme cela se produirait si le paquet TCP contenant la requête DSO était accusé de réception immédiatement.

Avec un message DSO unidirectionnel ou un message de réponse DSO, il n'y a pas de message de réponse DSO correspondant généré par l'application, et par conséquent, aucune indication au protocole de transport sur le moment où il devrait envoyer son accusé de réception et sa mise à jour de fenêtre.

Certaines APIs de réseau fournissent un mécanisme qui permet au logiciel client de la couche application de signaler au protocole de transport qu'aucune réponse ne sera forthcoming (en effet, cela peut être considéré comme une "écriture vide" de longueur zéro). Lorsque disponible dans l'API de réseau utilisée, le destinataire d'un message DSO unidirectionnel ou d'un message de réponse DSO, après avoir analysé et interprété le message, DEVRAIT alors utiliser ce mécanisme fourni par l'API de réseau pour signaler qu'aucune réponse pour ce message ne sera forthcoming. L'implémentation TCP peut alors envoyer son accusé de réception et sa mise à jour de fenêtre sans délai supplémentaire. Voir la Section 9.5 pour une discussion plus approfondie sur l'importance de cela.

5.5.2. Espaces de Noms MESSAGE ID (MESSAGE ID Namespaces)​

Les espaces de noms des MESSAGE IDs de 16 bits sont indépendants dans chaque direction. Cela signifie qu'il n'est pas une erreur pour le client et le serveur d'envoyer des messages de requête DSO en même temps l'un que l'autre, en utilisant le même MESSAGE ID, dans des directions différentes. Cette simplification est nécessaire pour que le protocole soit implémentable. Il serait infaisable d'exiger que le client et le serveur se coordonnent l'un avec l'autre concernant l'allocation de nouveaux MESSAGE IDs uniques. Il n'est pas non plus nécessaire d'exiger que le client et le serveur se coordonnent l'un avec l'autre concernant l'allocation de nouveaux MESSAGE IDs uniques. La valeur du MESSAGE ID de 16 bits combinée avec l'identité de l'initiateur (client ou serveur) est suffisante pour identifier de manière non ambiguë l'opération en question. Cela peut être considéré comme un espace d'identificateurs de messages de 17 bits utilisant des identificateurs de messages 0x00001-0x0FFFF pour les messages de requête DSO client-vers-serveur, et 0x10001-0x1FFFF pour les messages de requête DSO serveur-vers-client. Les 16 bits de poids faible sont stockés explicitement dans le champ MESSAGE ID du message DSO, et le bit de poids fort est implicite à partir de la direction du message.

Comme décrit dans la Section 5.4.1, un initiateur NE DOIT PAS réutiliser un MESSAGE ID qu'il utilise déjà pour un message de requête DSO en attente (sauf indication contraire de la spécification pertinente pour le DSO-TYPE en question). Au minimum, cela signifie qu'un MESSAGE ID ne peut pas être réutilisé dans une direction particulière sur une Session DSO particulière pendant que l'initiateur attend une réponse à un message de requête DSO précédent utilisant ce MESSAGE ID sur cette Session DSO (sauf indication contraire de la spécification pertinente pour le DSO-TYPE en question), et pour une opération de longue durée, le MESSAGE ID pour l'opération ne peut pas être réutilisé tant que cette opération reste active.

Si un client ou un serveur reçoit une réponse (QR=1) où le MESSAGE ID est zéro, ou est toute autre valeur qui ne correspond pas au MESSAGE ID de l'une de ses opérations en attente, c'est une erreur fatale et le destinataire DOIT abandonner de force la connexion immédiatement.

Si un répondeur reçoit un message de requête DSO (QR=0) où le MESSAGE ID n'est pas zéro, le répondeur suit les MESSAGE IDs de requête, et le MESSAGE ID correspond au MESSAGE ID d'un message de requête DSO qu'il a reçu pour lequel une réponse n'a pas encore été envoyée, il DOIT abandonner de force la connexion immédiatement. Ce comportement est requis pour prévenir une attaque hypothétique qui tire parti d'un comportement indéfini dans ce cas. Cependant, si le répondeur ne suit pas les MESSAGE IDs de cette manière, aucun tel risque n'existe. Par conséquent, le suivi des MESSAGE IDs juste pour implémenter cette vérification de cohérence n'est pas requis.

5.5.3. Réponses d'Erreur (Error Responses)​

Lorsqu'un message de requête DSO échoue pour une raison quelconque, le répondeur retourne un code d'erreur à l'initiateur.

Dans le cas d'un serveur retournant un code d'erreur à un client en réponse à un message de requête DSO infructueux, le serveur PEUT choisir de terminer la Session DSO ou PEUT choisir de permettre à la Session DSO de rester ouverte. Pour les conditions d'erreur qui n'affectent que la seule opération en question, le serveur DEVRAIT retourner une réponse d'erreur au client et laisser la Session DSO ouverte pour d'autres opérations.

Pour les conditions d'erreur qui sont susceptibles de rendre toutes les opérations infructueuses dans un avenir immédiat, le serveur DEVRAIT retourner une réponse d'erreur au client et ensuite terminer la Session DSO en envoyant un message Retry Delay comme décrit dans la Section 6.6.1.

Après avoir reçu une réponse d'erreur du serveur, un client NE DEVRAIT PAS fermer automatiquement la Session DSO. Une erreur relative à une opération particulière sur une Session DSO n'implique pas nécessairement que toutes les autres opérations sur cette Session DSO ont également échoué ou que les opérations futures échoueront. Le client devrait supposer que le serveur prendra sa propre décision quant à savoir s'il faut ou non terminer la Session DSO en fonction de la détermination du serveur de savoir si la condition d'erreur concerne cette opération particulière ou toute opération ultérieure. Si le serveur ne termine pas la Session DSO en envoyant au client un message Retry Delay (Section 6.6.1), alors le client DEVRAIT continuer à utiliser cette Session DSO pour les opérations ultérieures.

Lorsqu'un type de message DSO unidirectionnel est reçu (champ MESSAGE ID est zéro), le récepteur devrait déjà s'attendre à ce type de message DSO. La Section 5.4.5 décrit la gestion des types de messages DSO inconnus. Lorsqu'un message DSO unidirectionnel d'un type inattendu est reçu, le récepteur DEVRAIT abandonner de force la connexion. Le fait que la connexion doive être abandonnée de force pour d'autres erreurs internes traitant le message DSO unidirectionnel dépend de l'implémentation selon la gravité de l'erreur.

5.6. Annulation d'Opération Initiée par le Répondeur (Responder-Initiated Operation Cancellation)​

Ce document, la spécification de base pour les Opérations DNS avec État, ne définit lui-même aucune opération de longue durée, mais il définit un cadre pour prendre en charge les opérations de longue durée telles que les abonnements Push Notification [Push] et les abonnements d'interface Discovery Relay [Relay].

Les opérations de longue durée, si elles réussissent, resteront actives jusqu'à ce que l'initiateur termine l'opération.

Cependant, il est possible qu'une opération de longue durée soit valide au moment où elle a été initiée, mais qu'ensuite un changement ultérieur de circonstances rende cette opération invalide. Par exemple, une opération client de longue durée peut concerner un nom pour lequel le serveur est autoritaire, mais ensuite la configuration du serveur est modifiée de sorte qu'il n'est plus autoritaire pour ce nom.

Dans de tels cas, au lieu de terminer la session entière, il peut être souhaitable pour le répondeur de pouvoir annuler sélectivement uniquement les opérations qui sont devenues invalides.

Le répondeur effectue cette annulation sélective en envoyant un nouveau message de réponse DSO avec le champ MESSAGE ID contenant le MESSAGE ID de l'opération de longue durée qui doit être terminée (qu'il avait précédemment accusé réception avec un RCODE NOERROR) et le champ RCODE du nouveau message de réponse DSO donnant la raison de l'annulation.

Après qu'un message de réponse DSO avec un RCODE non nul a été envoyé, cette opération a été terminée du point de vue du répondeur, et le répondeur n'envoie plus de messages relatifs à cette opération.

Après qu'un message de réponse DSO avec un RCODE non nul a été reçu par l'initiateur, cette opération a été terminée du point de vue de l'initiateur, et le MESSAGE ID de l'opération annulée est maintenant libre pour réutilisation.

Dernière mise à jour le