9. Considérations Supplémentaires

9.1. Instances de Service

Nous utilisons le terme "instance de service" pour désigner un logiciel s'exécutant sur un hôte qui peut recevoir des connexions sur un ensemble de tuples { adresse IP, port }. Ce qui fait du logiciel une instance, c'est que quel que soit le tuple utilisé par le client pour s'y connecter, le client est connecté au même logiciel, s'exécutant sur le même nœud logique (voir Section 9.2), et recevra les mêmes réponses et les mêmes informations de clé.

Les instances de service sont identifiées du point de vue du client. Si le client est configuré avec des tuples { adresse IP, port }, il n'a aucun moyen de savoir si le service offert sur un tuple est le même serveur que celui qui écoute sur un tuple différent. Donc dans ce cas, le client traite chaque tuple différent comme s'il référençait une instance de service différente.

Dans certains cas, un client est configuré avec un nom d'hôte et un numéro de port. Le numéro de port peut être donné explicitement, avec le nom d'hôte. Le numéro de port peut être omis, et supposé avoir une valeur par défaut. Le nom d'hôte et un numéro de port peuvent être appris du réseau, comme dans le cas des enregistrements DNS SRV. Dans ces cas, le tuple { nom d'hôte, port } identifie de manière unique l'instance de service, sous réserve de la comparaison habituelle des noms DNS insensible à la casse [RFC1034].

Il est possible que deux noms d'hôte pointent vers certaines adresses IP communes ; c'est une anomalie de configuration que le client n'est pas obligé de détecter. L'effet de ceci pourrait être qu'après avoir reçu l'ordre de se déconnecter, le client pourrait se reconnecter au même serveur car il est représenté comme une instance de service différente.

Les implémentations NE DEVRAIENT PAS résoudre les noms d'hôte puis effectuer le processus de correspondance des adresses IP afin d'évaluer si deux entités doivent être déterminées comme étant la "même instance de service".

9.2. Considérations sur l'Anycast

Lorsqu'un service anycast est configuré sur une adresse IP et un port particuliers, il doit être le cas que bien qu'il y ait plus d'un serveur physique répondant sur cette adresse IP, chaque serveur peut être traité comme équivalent. Ce que nous entendons par "équivalent" ici est que les deux serveurs peuvent fournir le même service et, le cas échéant, les mêmes informations d'authentification, telles que des certificats PKI, lors de l'établissement des connexions.

Si un changement dans la topologie du réseau fait que des paquets d'une connexion TCP particulière sont envoyés à une instance de serveur anycast qui ne connaît pas la connexion, le nouveau serveur terminera automatiquement la connexion avec une réinitialisation TCP (reset), puisqu'il n'aura aucun enregistrement de la connexion, et alors le client peut se reconnecter ou arrêter d'utiliser la connexion selon le cas.

Si, après le rétablissement de la connexion, l'hypothèse du client selon laquelle il est connecté à la même instance est violée d'une manière ou d'une autre, cela serait considéré comme un comportement incorrect dans ce contexte. Il est cependant hors de la portée possible de cette spécification de faire des recommandations spécifiques à cet égard ; cela relèverait de documents ultérieurs décrivant des utilisations spécifiques des Opérations DNS avec État.

9.3. Partage de Connexion

Comme spécifié précédemment pour DNS-over-TCP [RFC7766] :

Pour atténuer le risque de surcharge involontaire du serveur, les clients DNS DOIVENT prendre soin de minimiser le nombre de connexions TCP simultanées établies vers un serveur individuel. Il est RECOMMANDÉ que pour toute interaction client/serveur donnée, il NE DEVRAIT PAS y avoir plus d'une connexion pour les requêtes régulières, une pour les transferts de zone, et une pour chaque protocole utilisé au-dessus de TCP (par exemple, si le résolveur utilisait TLS). Cependant, il est noté que certaines configurations primaire/secondaire avec de nombreuses zones occupées pourraient avoir besoin d'utiliser plus d'une connexion TCP pour les transferts de zone pour des raisons opérationnelles (par exemple, pour prendre en charge les transferts simultanés de plusieurs zones).

Un seul serveur peut prendre en charge plusieurs services, y compris les mises à jour DNS [RFC2136], les notifications push DNS [Push], et d'autres services, pour une ou plusieurs zones DNS. Lorsqu'un client découvre que le serveur cible pour plusieurs opérations différentes est la même instance de service (voir Section 9.1), le client DEVRAIT utiliser une seule session DSO partagée pour toutes ces opérations.

Cette exigence a deux avantages. Premièrement, elle réduit la charge de connexion inutile sur le serveur DNS. Deuxièmement, elle évite le temps de démarrage de la connexion qui serait passé à établir chaque nouvelle connexion supplémentaire au même serveur DNS.

Cependant, les implémenteurs et les opérateurs de serveurs doivent être conscients que le partage de connexion peut ne pas être possible dans tous les cas. Un seul périphérique hôte peut héberger plusieurs instances logicielles clientes indépendantes qui ne se coordonnent pas entre elles. De même, plusieurs périphériques clients indépendants derrière la même passerelle NAT apparaîtront aussi typiquement au serveur DNS comme des ports source différents sur la même adresse IP client. En raison de ces contraintes, un serveur DNS DOIT être prêt à accepter plusieurs connexions provenant de différents ports source sur la même adresse IP client.

9.4. Considérations Opérationnelles pour les Intermédiaires (Middleboxes)

Là où un intermédiaire de couche application (par exemple, un proxy DNS, un redirecteur ou un multiplexeur de session) est sur le chemin, il faut prendre soin d'éviter une configuration dans laquelle le trafic DSO est mal géré. Le moyen le plus simple d'éviter de tels problèmes est d'éviter d'utiliser des intermédiaires. Lorsque cela n'est pas possible, les intermédiaires doivent être évalués pour s'assurer qu'ils se comportent correctement.

Un comportement correct pour les intermédiaires consiste en l'un des éléments suivants :

• L'intermédiaire ne transmet pas les messages DSO et répond aux messages DSO avec un code de réponse autre que NOERROR ou DSOTYPENI.

• L'intermédiaire agit comme un serveur DSO et suit cette spécification pour établir des connexions.

• Il existe une correspondance 1:1 entre les connexions entrantes et sortantes de telle sorte que lorsqu'une connexion est établie vers l'intermédiaire, il est garanti qu'exactement une connexion correspondante sera établie de l'intermédiaire vers un résolveur DNS, et tous les messages entrants seront transmis sans modification ni réorganisation. Un exemple de ceci serait un redirecteur NAT ou un optimiseur de connexion TCP (par exemple, pour une connexion à latence élevée telle qu'une liaison satellite géosynchrone).

Les intermédiaires qui ne répondent pas à l'un des critères ci-dessus sont très susceptibles d'échouer de manière inattendue et difficile à diagnostiquer. Par exemple, un équilibreur de charge DNS pourrait désassembler les messages DNS du flux TCP entrant et transmettre chaque message du flux à un serveur DNS différent. Si un tel équilibreur de charge est utilisé, et que les serveurs DNS vers lesquels il pointe implémentent DSO et sont configurés pour activer DSO, l'établissement de la session DSO réussira, mais aucune session cohérente n'existera entre le client et le serveur. Si un tel équilibreur de charge pointe vers un serveur DNS qui n'implémente pas DSO ou est configuré pour ne pas autoriser DSO, aucun problème de ce type n'existera, mais une telle configuration risque une défaillance inattendue si un nouveau logiciel serveur est installé qui implémente DSO.

Il est bien sûr possible d'implémenter un intermédiaire qui prend correctement en charge DSO. Il est même possible d'en implémenter un qui implémente DSO avec des opérations de longue durée. Cela peut être fait soit en maintenant une correspondance 1:1 entre les connexions entrantes et sortantes, comme mentionné ci-dessus, soit en terminant les sessions entrantes au niveau de l'intermédiaire mais en maintenant l'état dans l'intermédiaire concernant toutes les opérations de longue durée demandées. Spécifier cela en détail dépasse la portée de ce document.

9.5. Considérations sur l'Acquittement Différé TCP

La plupart des implémentations modernes du protocole de contrôle de transmission (TCP) incluent une fonctionnalité appelée "Acquittement Différé" (Delayed Acknowledgement) [RFC1122].

Sans cette fonctionnalité, TCP peut être très gaspilleur sur le réseau. Pour illustrer, considérons un exemple simple comme la connexion à distance utilisant une implémentation TCP très simple qui manque d'acquittements différés. Lorsque l'utilisateur tape une touche, un paquet de données est envoyé. Lorsque le paquet de données arrive au serveur, l'implémentation TCP simple envoie un acquittement immédiat. Quelques millisecondes plus tard, le processus serveur lit l'octet de données de frappe, et par conséquent l'implémentation TCP simple envoie une mise à jour de fenêtre immédiate. Quelques millisecondes plus tard, le processus serveur génère l'écho du caractère et envoie ce paquet de données immédiatement aussi. L'implémentation TCP simple envoie alors ce paquet de données immédiatement aussi. Dans ce cas, cette implémentation TCP simple envoie une rafale de trois paquets presque instantanément (ack, mise à jour de fenêtre, données).

Il serait clairement plus efficace si l'implémentation TCP combinait les trois paquets séparés en un seul, et c'est ce que permet la fonctionnalité d'acquittement différé.

Avec l'acquittement différé, l'implémentation TCP attend après avoir reçu un paquet de données, typiquement pendant 200 ms, puis envoie son ack si (a) plus de paquets de données arrivent, (b) le processus de réception génère des données de réponse, ou (c) 200 ms s'écoulent sans que l'un ou l'autre de ce qui précède ne se produise.

Avec l'acquittement différé, la connexion à distance devient beaucoup plus efficace, générant juste un paquet au lieu de trois pour chaque écho de caractère.

La logique de l'acquittement différé est que le délai de 200 ms ne peut faire aucun mal significatif. Si quelque chose à l'autre extrémité attendait quelque chose, alors le processus de réception devrait générer la réponse que la chose à l'autre extrémité attend, et TCP enverra alors immédiatement cette réponse (combinée avec l'ack et la mise à jour de fenêtre). Et si le processus de réception ne génère en fait aucune réponse pour ce message particulier, alors par définition la chose à l'autre extrémité ne peut rien attendre. Par conséquent, le délai de 200 ms est inoffensif.

Cette hypothèse peut être vraie à moins que l'expéditeur n'utilise l'algorithme de Nagle, une fonctionnalité d'efficacité similaire, créée pour protéger le réseau contre les logiciels clients mal écrits qui effectuent de nombreuses petites écritures rapides successivement. L'algorithme de Nagle permet de fusionner ces petites écritures en paquets plus grands et moins gaspilleurs.

Malheureusement, l'algorithme de Nagle et l'acquittement différé, deux fonctionnalités d'efficacité précieuses, peuvent interagir mal l'une avec l'autre lorsqu'elles sont utilisées ensemble [NagleDA].

Les messages de demande DSO suscitent des réponses ; les messages unidirectionnels DSO et les messages de réponse DSO ne le font pas.

Pour les messages de demande DSO, qui suscitent des réponses, l'algorithme de Nagle et l'acquittement différé fonctionnent comme prévu.

Pour les messages DSO qui ne suscitent pas de réponses, le mécanisme d'acquittement différé fait que l'ack est retardé de 200 ms. Le délai de 200 ms sur l'ack peut à son tour amener l'algorithme de Nagle à empêcher l'expéditeur d'envoyer plus de données pendant 200 ms jusqu'à ce que l'ack attendu arrive. Sur une dorsale Gigabit Ethernet (GigE) d'entreprise avec des temps d'aller-retour inférieurs à la milliseconde, un délai de 200 ms est énorme en comparaison.

Lorsque ce problème est soulevé, il y a deux solutions qui sont souvent proposées, aucune d'elles n'étant idéale :

1. Désactiver l'acquittement différé. Pour les messages DSO qui ne suscitent aucune réponse, la suppression de l'acquittement différé évite le délai inutile de 200 ms et renvoie un ack immédiat qui indique à l'algorithme de Nagle qu'il doit immédiatement accorder à l'expéditeur la permission d'envoyer son prochain paquet. Malheureusement, pour les messages DSO qui suscitent une réponse, la suppression de l'acquittement différé supprime les gains d'efficacité de la combinaison des acks avec les données, et le répondeur enverra désormais deux ou trois paquets au lieu d'un.

2. Désactiver l'algorithme de Nagle. Lorsque les acks sont retardés par l'algorithme d'acquittement différé, la suppression de l'algorithme de Nagle empêche l'expéditeur d'être bloqué pour envoyer son prochain petit paquet immédiatement. Malheureusement, sur un réseau avec un temps d'aller-retour plus élevé, la suppression de l'algorithme de Nagle supprime les gains d'efficacité de la combinaison de plusieurs petits paquets en moins de paquets plus grands, dans le but de limiter le nombre de petits paquets en vol à un moment donné.

Le problème ici est qu'avec les messages DSO qui ne suscitent aucune réponse, l'implémentation TCP est bloquée en attente, ne sachant pas si une réponse est sur le point d'être générée ou si l'implémentation TCP doit aller de l'avant et envoyer un ack et une mise à jour de fenêtre.

La solution réside dans les API réseau qui permettent au récepteur d'informer l'implémentation TCP qu'un message reçu a été lu, traité, et qu'aucune réponse pour ce message ne sera générée. TCP peut alors arrêter d'attendre une réponse qui ne viendra jamais, et immédiatement aller de l'avant et envoyer un ack et une mise à jour de fenêtre.

Pour les implémentations de DSO, la désactivation de l'acquittement différé N'EST PAS RECOMMANDÉE en raison du mal que cela peut faire au réseau.

Pour les implémentations de DSO, la désactivation de l'algorithme de Nagle N'EST PAS RECOMMANDÉE en raison du mal que cela peut faire au réseau.

Au moment où ce document est préparé pour publication, il est connu qu'au moins une implémentation TCP offre la capacité pour le destinataire d'un message TCP de signaler qu'il ne va pas envoyer de réponse, et donc le mécanisme d'acquittement différé peut arrêter d'attendre. Les implémentations sur les systèmes d'exploitation où cette fonctionnalité est disponible DEVRAIENT l'utiliser.