1. Introduction

Ce document spécifie un mécanisme pour gérer les connexions DNS avec état. Le DNS fonctionne le plus souvent sur un transport UDP, mais il peut également fonctionner sur des transports en continu ; la RFC DNS originale spécifie DNS-over-TCP [RFC1035], et un profil pour DNS-over-TLS [RFC7858] a été spécifié. Ces transports peuvent offrir des sessions persistantes de longue durée et, par conséquent, lors de leur utilisation pour transporter des messages DNS, il est avantageux de disposer d'un mécanisme permettant d'établir des paramètres associés à ces sessions, tels que les délais d'attente. Dans de telles situations, il est également avantageux de prendre en charge les messages initiés par le serveur (tels que les notifications push DNS [Push]).

Le mécanisme d'extension existant pour le DNS (EDNS(0)) [RFC6891] est explicitement défini pour n'avoir qu'une sémantique "par message". Bien qu'EDNS(0) ait été utilisé pour signaler au moins un paramètre lié à la session (option edns-tcp-keepalive EDNS(0) [RFC7828]), le résultat est moins qu'optimal en raison des restrictions imposées par la sémantique EDNS(0) et du manque de signalisation initiée par le serveur. Par exemple, un serveur ne peut pas demander arbitrairement un client de fermer une connexion car le serveur ne peut envoyer des options EDNS(0) que dans les réponses aux requêtes contenant des options EDNS(0).

Ce document définit un nouvel OPCODE DNS pour les opérations DNS avec état (DSO) avec une valeur de 6. Les messages DSO sont utilisés pour communiquer des opérations au sein de sessions persistantes avec état, exprimées à l'aide de la syntaxe Type Longueur Valeur (TLV). Ce document définit un ensemble initial de trois TLV utilisés pour gérer les délais d'attente de session, la terminaison et le remplissage de chiffrement.

Les trois TLV définis ici sont obligatoires pour toutes les implémentations de DSO. D'autres TLV peuvent être définis dans des spécifications supplémentaires.

Les messages DSO peuvent ou non faire l'objet d'un accusé de réception. Le fait qu'un message DSO doive faire l'objet d'un accusé de réception (un message de requête DSO) ou non (un message unidirectionnel DSO) est spécifié dans la définition de ce type de message DSO particulier. L'ID MESSAGE est différent de zéro pour les messages de requête DSO et nul pour les messages unidirectionnels DSO. Les messages sont envoyés en pipeline et les réponses peuvent apparaître dans le désordre lorsque plusieurs requêtes sont traitées simultanément.

Le format des messages DSO (section 5.4) diffère quelque peu du format de message DNS traditionnel utilisé pour les requêtes et réponses standard. L'en-tête standard de douze octets est utilisé, mais les quatre champs de comptage (QDCOUNT, ANCOUNT, NSCOUNT, ARCOUNT) sont mis à zéro et, par conséquent, leurs sections correspondantes ne sont pas présentes.

Les données réelles relatives aux opérations DNS avec état (exprimées en syntaxe TLV) sont ajoutées à la fin de l'en-tête du message DNS. Tout comme dans le DNS-over-TCP traditionnel [RFC1035] [RFC7766], le protocole de flux transportant des messages DSO (qui ne sont qu'un autre type de message DNS) les encadre en plaçant une longueur de message de 16 bits au début. La longueur du message DSO est donc déterminée à partir de cette longueur plutôt qu'à partir de l'un des comptages d'en-tête DNS.

Lorsqu'il est affiché à l'aide d'outils d'analyse de paquets qui n'ont pas été mis à jour pour reconnaître le format DSO, cela entraînera l'affichage des données DSO comme des données supplémentaires inconnues après la fin du message DNS.

Ce nouveau format présente des avantages distincts par rapport à un format basé sur les RR car il est plus explicite et plus compact. Chaque définition TLV est spécifique à son cas d'utilisation et, par conséquent, ne contient aucun champ redondant ou surchargé. Il est important de noter qu'il évite complètement de confondre les opérations DNS avec état de quelque manière que ce soit avec les opérations DNS normales ou avec les fonctionnalités existantes basées sur EDNS(0). Un objectif de cette approche est d'éviter les problèmes opérationnels qui ont affecté EDNS(0), en particulier concernant le comportement des intermédiaires (voir les sections traitant d'EDNS(0) et les problèmes causés par les pare-feu et les équilibreurs de charge, dans les travaux récents décrivant les causes des échecs DNS [Fail]).

Avec EDNS(0), plusieurs options peuvent être regroupées dans un seul pseudo-RR OPT, et il n'existe aucun mécanisme généralisé permettant à un client de savoir si un serveur a traité ou autrement agi sur chaque option individuelle au sein du pseudo-RR OPT combiné. Les spécifications de chaque option individuelle doivent définir comment chaque option différente doit faire l'objet d'un accusé de réception, si nécessaire.

Contrairement à EDNS(0), avec DSO, il n'y a aucune motivation impérieuse à regrouper plusieurs opérations dans un seul message pour des raisons d'efficacité, car DSO fonctionne toujours en utilisant un protocole de transport orienté connexion. Chaque opération DSO est communiquée dans son propre message DNS séparé, et le protocole de transport peut se charger de regrouper plusieurs messages DNS dans un seul paquet IP si nécessaire. Par exemple, TCP peut regrouper plusieurs petits messages DNS dans un seul segment TCP. Cette simplification permet une sémantique plus claire. Chaque message de requête DSO communique une seule opération principale, et le RCODE dans le message de réponse correspondant indique le succès ou l'échec de cette opération.